[Octave-bug-tracker] [bug #40664] Inconsistent handling of N-dimensional RGB images

[Adam H Aitkenhead]

Follow-up Comment #4, bug #40664 (project octave):

Thanks for looking at this again Carne.

I still don't agree that these functions should be blocked for N>3 dimensions.
 Matlab supports ND images in greyscale.  Eg. in R2010a:


temp = rand(3,3,3,3,3,3);
[x,m] = gray2ind(temp);
size(x)
ans =
     3     3     3     3     3     3


Matlab happens not to support ND images in RGB.  I don't know why not, other
than it's a little more tricky to code and the demand for it is small.

More generally, functions don't need to be limited to work for the 2D/3D case
only - even for images.  After all, there is no difference between an image
and a matrix in Matlab or Octave.  It's only when you display it that it
becomes an image - during processing it's just a matrix of numbers.   There
are valid reasons why others may want to process 3+ dimension matrices through
rgb2ind or ind2rgb, and I don't think that functionality should be blocked. 
It doesn't have any impact at all on the handling of single 2D images or
stacks of 2D images.

As for there being no convention on which dimension the RGB channels should
belong to - I agree.  Originally I had defined the RGB channels as being in
the final dimension, as that seemed to be a sensible way of handling it.  The
change to ind2rgb then defined the RGB channel to be in the 3rd dimension -
not a problem as long as we remain consistent.  Since there is no standard
convention, either definition is fine as long as it is clearly documented -
the user can always use permute to arrange the dimensions accordingly.

    _______________________________________________________

Reply to this item at:

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

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