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

[Carnë Draug]

Update of bug #40664 (project octave):

                  Status:                    None => Fixed                  
             Open/Closed:                    Open => Closed                 

    _______________________________________________________

Follow-up Comment #7:

If it works in Matlab then we have to but if it doesn't we can think twice
about it. Just because we don't see a problem now doesn't mean we won't have
one in the future. Comes to my mind now, the fact that until recently, imread
was returning an RGB image with alpha channel as a MxNx4 matrix which I had to
remove now since that's for a CMYK image. Hopefully there isn't many people
using it.

I think this functions, to convert between a colorspace and a indexed image,
only makes sense before or after reading, writing or displaying an image (I
can't think of any operations that make sense in indexed images). Those
functions are also unable to deal with matrices with more than 4 dimensions so
the user will have to reshape it anyway after calling rgb2ind. The convention
on those types of functions is

* 2D matrix => grayscale image

* 2D matrix with colormap => indexed image

* 3D matrix => CMYK or RGB depending on size of dimension 3

* 4D matrix => multiple images of any of the above type, all concatenated in
the 4th dimension

Your bug report is about consistency (take a look at the title) but at the
same time you're asking to change this convention for just this 2 functions.
Such user may be happy now if we make this work with matrices of size > 4, but
will be much more frustrated if one day the behavior changes and because there
was never an error, he will not know that his code is giving incorrect
results.

For now, I have pushed a cset that at least makes rgb2ind reverse ind2rgb and
thus handling N-dimensional images (matrices with at least 4 dimensions)

http://hg.savannah.gnu.org/hgweb/octave/rev/b8cd17571a1d

    _______________________________________________________

Reply to this item at:

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

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