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

[Lee Kamentsky]

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.

Obviously, this scheme would fall apart if you had 256 or more objects 
in a 256-color indexed image; perhaps it's up to "segmentation" to 
interpret an image a segmentation result and reconstruct a labeling by 
identifying the unique colors in an image and assigning all pixels with 
the same color to the same object. 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.

--Lee

On 12/13/2010 4:52 AM, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 13 Dec 2010, Gabriel Landini wrote:
>
>> On Sunday 12 December 2010 22:33:55 Curtis Rueden wrote:
>>> FYI, ImageJ has a "feature" where if the LUT is totally grayscale,
>>> ImageJ ignores it and declares the file to be a regular 8-bit image,
>>> rather than "RGB color." Unfortunately, this makes it difficult to
>>> tell if the image has a "hidden" color table. Still, you could
>>> probably eliminate the LUT by resaving as TIFF again from ImageJ.
>> Just imagine you are working with an 8 bit image, then you want to see
>> some contrast enhanced and apply a false colour LUT and then go back to
>> the greyscale LUT. If I saved this image which is now greyscale with the
>> grey.lut, would this be re-opened as RGB? Maybe this is not such a good
>> idea.
>>
>> I do not know how IJ tests the LUT, but I guess it would be trivial:
>> loop through the 256 entries and see if they are r=g=b in the expected
>> sequential order. If so, then treat as 8bit greyscale image. Checking
>> the table would tell you if there are any hidden colours.
> IMHO an index-color image is _not_ of a numeric type. So to properly
> support index-color images, one would need to make a "CategoricalType"
> that still uses bytes or shorts, but that cannot add/multiply/whatever.
>
> OTOH if the LUT is just a view mode (as it should always be seen in
> scientific imaging), then the LUT is not part of the image and should not
> be saved in the first place. I often catch users insisting on the DAPI
> channel being colored blue, when they should know fully well (because I
> told them) that the DAPI channel is the result of a range of frequencies,
> not blue.
>
> In short: in most cases I hear people want index-color images, it turns
> out that they really want numeric images with lookup tables instead. Since
> we want to analyze the samples of which those images were taken, it is
> really, really important to keep the distinction in mind.
>
> Ciao,
> Johannes
>
>
> _______________________________________________
> ImageJ-devel mailing list
> ImageJ-devel at imagejdev.org
> http://imagejdev.org/mailman/listinfo/imagej-devel