[Octave-bug-tracker] [bug #41851] ind2rgb tests

[Guillaume]

Follow-up Comment #5, bug #41851 (project octave):

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:

>> ind2rgb([-1 0 1 2 63 64 65 66],gray(64))
ans(:,:,1) =
         0         0         0    0.0159    0.9841    1.0000    1.0000   
1.0000
ans(:,:,2) =
         0         0         0    0.0159    0.9841    1.0000    1.0000   
1.0000
ans(:,:,3) =
         0         0         0    0.0159    0.9841    1.0000    1.0000   
1.0000


while Octave will complain of values -1 and 0, but is OK with values beyond
the size of the colormap:

octave> ind2rgb([1 2 63 64 65 66],gray(64))
ans =
ans(:,:,1) =
   0.00000   0.01587   0.98413   1.00000   1.00000   1.00000
ans(:,:,2) =
   0.00000   0.01587   0.98413   1.00000   1.00000   1.00000
ans(:,:,3) =
   0.00000   0.01587   0.98413   1.00000   1.00000   1.00000


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

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?41851>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/