Okay, I went with your modification to the proposed changeset. It's checked in on the default branch (http://hg.savannah.gnu.org/hgweb/octave/rev/875f4510d6dc).

Rik, as an alternative, please take a look at the attached patch. It is an amend of yours.
It makes note of this bug number in the comments, prints a warning for the opposite case (colours above the cmap limit), and tests that warnings are issued for 0, off by one errors for integers and floats.
Also, it performs just a tiny little better (since we don't need isindex to check if all values are integers again) and avoids "x(x < 1) = 1" unless absolutely required which always creates a copy of the image.
(file #30934)

Thanks Rik, works fine for me with the warning below being displayed for values < 1.

Carne, I've attached a patch that makes Octave compatible with Matlab in this regard. I don't like it much either though. If someone tests the patch and verifies it I will check it in.
(file #30929)

Matlab behaviour is plain wrong since the value for that index does not exist. If instead of an image this was a matrix for some other purpose, would you think appropriate to give you the last element of the matrix if you tried to index outside the limit of the matrix? And colours in a colourmap are not necessarily sorted by intensity.
In addition, "fixing" this will make it much easier for users to make "off by one" mistakes.
Still, we may not have much of a choice to introduce this error for the sake of matlab compatibility. So I'm reopened the bug and ask for opinion of others devs. Let us at least print a big fat warning if users try to index out of the bounds of the colourmap.

Thanks once again.
I personally think that the MATLAB behaviour is appropriate here and could be implemented by having these lines in private/ind2x.m:

Hmm... I see what you mean. Looking into private/ind2x.m function, there is:
Maybe we should also give an error for this cases? Or issue a warning?

Thanks for your comments. I used the code with uint8() and double() because it is the exact one from the test cases.
Maybe I should use another example  in MATLAB you get this:
while Octave will complain of values 1 and 0, but is OK with values beyond the size of the colormap:
So values larger than the size of the colormap are all reassigned to that value (in Octave and MATLAB). And only MATLAB assigns an index of 1 to all values less than 1.
It seems to me like a reasonable behaviour (symmetrical handling of both extrema) and compatible to what happens when you display an image with a fixed CLim axis (out of range values are assigned the first or last colors from the colormap).

I second Rik's opinion.
Ignoring the case of the class explanation, you will notice that in your example, the indexed image has indices with a value of "zero" and "one" (the first and third row of the first column). From your example, it seems that Matlab assigns the same colour to both of them. How come two different indices give the same colour when there's no repeated colours in the colormap?
This is yet another case where Matlab returns rubbish due to improper input check. A matrix of class double is only an indexed image if all values are positive integers. Rather than returning a wrong answer, Octave gives an error. That sounds right to me so I'm marking this as invalid.
Another suggestion. Instead of using
I'll instead recommend to use the image package which has a set of functions meant to convert an image between different types. If they are indexed, you can do
which handles all the details for you.

I don't know what Matlab is doing, but I think Octave is correct in rejecting the variable img as not being an indexed image.
When the img is of type double, a 1 in the matrix points to the first row in the colormap. When the img is an integer type, such as uint8, then an offset of 1 is used such that a 0 in the matrix points to the first row in the colormap. See Matlab's own documentation for more information (http://www.mathworks.com/help/matlab/creating_plots/imagetypes.html).
In the posted code, the image is originally in uint8 format and thus has 0 values. Using double() to convert a uint8 image is not correct. You actually need to do

Sorry about that, I should have copied the exact code I used:
MATLAB returns:
while Octave dev returns:

I am a bit confused by the bug report. Your first sample are the results you get in Matlab or Octave? I do not get an error, and it works correctly (althout not the results you are displaying). Using Octave 3.8.1:
which should be the correct values.

The tests for ind2rgb return a different output in MATLAB for floating point inputs: (using variables from scripts/image/ind2rgb.m)
while Octave expects an error.
The other tests in "Test input validation" that do not return an error are:
