[ImageJ-devel] ImageOpener always giving me three channels when these is only one.
G.Landini at bham.ac.uk
Mon Dec 13 08:04:23 CST 2010
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
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.
More information about the ImageJ-devel