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).

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

if (isfloat (x) && ! isindex (x))
  warning (["Octave:" caller ":invalid-idx-img"],
           [caller ": Indexed image contains colors outside of colormap."]);
endif

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.

Hmm... I see what you mean. Looking into private/ind2x.m function, there is:

  num_colors = rows (map);
  if (num_colors < maxidx)
    ## Pad with the last color in the map for Matlab compatibility
    pad = repmat (map(end,:), maxidx - num_colors, 1);
    map(end+1:maxidx, :) = pad;
  endif

Maybe we should also give an error for this cases? Or issue a warning?

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

img_double = double (img) + 1;

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

im2double (img, "indexed")

which handles all the details for you.

Sorry about that, I should have copied the exact code I used:

img = [2 4 5; 3 2 5; 1 2 4];
map = [0.0  0.0  0.0
       0.2  0.4  0.6
       0.4  0.4  0.5
       0.3  0.7  1.0
       0.1  0.5  0.8];
img = uint8 (img -1);
[rgb] = ind2rgb (double(img), map)

MATLAB returns:

rgb(:,:,1) =
         0    0.4000    0.3000
    0.2000         0    0.3000
         0         0    0.4000
rgb(:,:,2) =
         0    0.4000    0.7000
    0.4000         0    0.7000
         0         0    0.4000
rgb(:,:,3) =
         0    0.5000    1.0000
    0.6000         0    1.0000
         0         0    0.5000

while Octave dev returns:

error: ind2rgb: X must be an indexed image

The tests for ind2rgb return a different output in MATLAB for floating point inputs: (using variables from scripts/image/ind2rgb.m)

>> [rgb] = ind2rgb (double(img), map)
rgb(:,:,1) =
         0    0.4000    0.3000
    0.2000         0    0.3000
         0         0    0.4000
rgb(:,:,2) =
         0    0.4000    0.7000
    0.4000         0    0.7000
         0         0    0.4000
rgb(:,:,3) =
         0    0.5000    1.0000
    0.6000         0    1.0000
         0         0    0.5000

while Octave expects an error.
The other tests in "Test input validation" that do not return an error are:

>> ind2rgb (sparse (1), jet (64))
ans(:,:,1) =
     0
ans(:,:,2) =
     0
ans(:,:,3) =
    0.5625
>> ind2rgb (0, jet (64))
ans(:,:,1) =
     0
ans(:,:,2) =
     0
ans(:,:,3) =
    0.5625
>> ind2rgb (1, ones (2,2,2))
ans(:,:,1) =
     1
ans(:,:,2) =
     1
ans(:,:,3) =
     1
>> ind2rgb (1, ones (2,4))
ans(:,:,1) =
     1
ans(:,:,2) =
     1
ans(:,:,3) =
     1