octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Carnë Draug
Subject: [Octave-bug-tracker] [bug #40664] Inconsistent handling of N-dimensional RGB images
Date: Fri, 22 Nov 2013 13:18:46 +0000
User-agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20131030 Firefox/17.0 Iceweasel/17.0.10

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

My experience is that Matlabs's "support" for this type of images/matrices is
often an accident that arises due to the lack of proper input checking. For
some cases it works fine but sometimes it just returns garbage back. For
example, experiment with im2col and other block processing functions. Or im2bw
which should use rgb2gray before the conversion to bw when input is rgb (but
does not if it has 4 dimensions - my guess is because it must be using isrgb
internally which does not work for ND). So, Matlab does not support anything,
it simply forgets to do input check and sometimes it works. The problem with
this approach is that when it doesn't work, you won't know.

The read and write functions will read an image into a 4D matrix only, no
matter how many dimensions it has. I think it makes sense to keep this type of
functions consistent with the image IO functions. Some image processing
functions such as mathematical morphology or other filters make sense for
matrices of any dimension, they are just moving window filters, but this is
not the case.

Anyway, rgb2ind should be fixed to reverse ind2rgb so this bug is still valid.
I'll open another bug for the use of gm convert.

    _______________________________________________________

Reply to this item at:

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

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]