[ImageJ-devel] ImageOpener always giving me three channels when these is only one.

[Gabriel Landini]

On Monday 13 December 2010 08:44:17 Lee Kamentsky wrote:
> Hi all,
> It would be nice, I suppose, to save the LUT in the spirit of not
> destroying information, but I agree that the primary objects of interest
> are the color indices. I have a feeling that people will save
> segmentation results this way, designating one color as background
> (typically zero = black) and then assigning colors from a color map to
> each value in the indexing range. One interesting possibility is to pick
> a handful of colors that are distant from each other and assign each to
> several possible index values (imagine 4 color theorem, but there are
> easy algorithms if you're allowed to use a few more - don't assign
> nearby or touching objects to the same color). The significant
> information in that case is the index, not the color.

I am happy (this happy:  :-)  ) to report that this already exists, it is the 
Glasbey LUT. He wrote a paper on this as well, and I produced a similar LUT 
that maximises the distances between colour for red-green colour blind 
individuals. (I have to upload this soon)

> Obviously, this scheme would fall apart if you had 256 or more objects
> in a 256-color indexed image;

Yes, it does, specially if you happen to have 4-connected segmented particles 
that touch (actually they do not touch) by their corners. They look like an 8 
connected particle.

Two ways of labelling: one is by changing the index MOD the number of colours, 
the other is to use all the indexes and let the LUT distribute the colours. 
Both have problems. The first one I already mentioned, and there are not 
unique particle indexes as they might be shared, but this is the one that 
looks least confusing: the next particle in the scan is of a different colour.

The other: one can index increasingly in a 32 bit image, but because the LUT 
is stretched to fit the data range, many consecutive particles look the same 
colour (but have a different index). I use that in one of the morphology 
plugins (I think it is called Binary_Label)

> This highlights one of the problems -
> the image opener doesn't have information on the use of the image, so it
> can't make the proper interpretation for the derived format and, in my
> opinion, it should not make any interpretation and instead try to
> preserve the information in the image file with as much fidelity as is
> possible and leave the interpretation to code downstream.

Well, as mentioned, one can add a tag for that purpose and let IJ handle it.

Regards

Gabriel