Re: ind2rgb problem

[Carnë Draug]

On 31 May 2013 16:58, adam aitkenhead <address@hidden> wrote:
> 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.

I see now. I thought it was a mistake from me when I wrote ind2x().
You see, it would always pass that check since a matrix will always
have at least 2 dimensions (even vectors with a single column will
have 2 dimensions).

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

Are those XxYxZx3 images you get the output of imread()? Or are they
built by your own in-house code? Because you should not have them
being returned from any Octave function. We don't yet have a lot of
documentation about this tipe of images but from Matlab's
documentation[1]:

"Multi-frame arrays are either m-by-n-by-1-by-p, for grayscale,
binary, or indexed images, or m-by-n-by-3-by-p, for truecolor images,
where p is the number of frames."

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

Yes, those images do exist and I deal with them routinely, 5D images
for volume, wavelengths and time. Still, they all get concatenated on
the 4th dimension (this is also how Matlab behaves, not an Octave only
thing). Since they are all grayscale images, the images are MxNx1xP.
It's just not possible to reliably return a matrix with the dimensions
in the "correct" organization. Interpreting it and selecting the right
pages of the image to pass to functions is left to the user.

On a related note, I do have some ideas about a NDimage class which I
hope to implement later though.

Carnë

[1] http://www.mathworks.co.uk/help/images/working-with-image-sequences.html