octave-maintainers
[Top][All Lists]
Advanced

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

RE: ind2rgb problem


From: adam aitkenhead
Subject: RE: ind2rgb problem
Date: Fri, 31 May 2013 15:58:10 +0000

Hi Carnë

> Actually that was a bug. There was a test there and should give an
> error if the input image had more than 2 dimensions, but it was
> reversed and was instead checking if it had *less* than 2. That's why
> it was working.

In version b1cd65881592, ind2x used to check that the number of dimensions were 
exactly 2.  Then in version aa81cfa5c359 that was then changed so that it would 
give an error if the number of dimensions was < 2, in effect allowing ND images 
(as long as N>= 2).  So that check was intentional rather than a bug.

> A 5x5x5 image is an invalid image. Isn't the third dimension reserved
> for colours channels? A 3D image is not read as a matrix with 3
> dimensions, it's read as a 4 dimension matrix, the space being on the
> 4th dimension. If the image is indexed, the third dimension will be a
> singleton. I do not have any multipage indexed image for testing (if
> you do, please send me one, I need it for testing purposes, specially
> multipage indexed image with different colormaps in each page), but
> imread should read those images as 4D matrices.

The 3D RGB images I've used have been XxYxZx3, where the final dimension 
contains the RGB colorspace.  Most of the code for that has been custom 
in-house stuff though, there may be a different standard elsewhere.  (If the 
3rd dimension is reserved for the RGB color space, then what happens in higher 
dimension images like 4D images, eg. a medical image including motion?)  I 
would have expected that the RGB colorspace would always be in the final 
dimension - which makes things quite straightforward when extending to N 
dimensions.

I don't have any examples of 3D images that I can pass on unfortunately - the 
cases I have are part of the processing for overlaying color regions on a 3D 
medical image for display on screen, and are generally not written to file.

As far as Matlab goes, R2010a can only handle 2D images using ind2rgb - I don't 
know about more recent versions.  So at least Matlab compatibility isn't a 
concern.  But even if the standard was that the RGB colorspace was stored in 
the 3rd dimension rather than the final dimension, we could at least still 
allow ind2x to handle images of 4D or more, rather than limiting ndims to 
either 2 or 4 (ie. 2D or 3D images).  Being able to handle 4D images will 
definitely be useful for medical images.

Adam                                      

reply via email to

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