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

[Lee Kamentsky]

It might be useful to leave the choice to the user of whether the index 
is intended as a value, probably upon loading. The "categorical data" 
might be the object's index if the image is a segmentation and the LUT 
is a coloring for visualization.

Related to this, I was wondering how to save segmentation results and I 
*would* like to annotate the "image" with some data that would mark it 
as a segmentation. And, to complicate matters, some pixels might have 
more than one label and you'd like to map an LUT index, in some cases, 
to mean "this pixel is part of object A and object B"... and you'd like 
the LUT color to reflect that fact - an alpha-blending of the colors for 
A & B.

- Lee

On 1/10/2011 1:16 PM, Curtis Rueden wrote:
> Hi,
>
>     The problem is how to tell apart a greyscale with a viewing LUT
>     (underlying
>     numeric, indexing a palette) from one with an unordered palette
>     (indexed).
>     One way could be to implicitly record this at creation time (let's
>     say if
>     saved as GIF, or after applying some colour reduction) by adding a
>     flag
>     indicating so. But of course, all externally created images would
>     not have
>     this tag.
>
>
> I know this thread is a bit old now, but I wanted to make one comment 
> about differentiating between what Gabriel calls "underlying numeric, 
> indexing a palette" (i.e., color table for visualization) and 
> "unordered palette" (i.e., color table identifying actual measured 
> values).
>
> Bio-Formats can report, for a given indexed dataset, which of these it 
> believes the data to be, via a method called "isFalseColor()." If the 
> data isFalseColor(), then its color table is merely for visualization. 
> If !isFalseColor(), then the true data is represented in the table values.
>
> Right now, the false color flag is format-dependent. That is, we know 
> certain formats generally save the color table for visualization. As 
> of this writing, the following formats are reported as using false 
> color indexing:
>
> : curtis at rook 
> ~/code/LOCI/software/components/bio-formats/src/loci/formats/in
> grep falseColor *.java | grep true
> BioRadReader.java:    core[0].falseColor = true;
> LeicaHandler.java:        coreMeta.falseColor = true;
> LeicaReader.java:      core[i].falseColor = true;
> NativeND2Reader.java:        core[i].falseColor = true;
> OMEXMLReader.java:      core[i].falseColor = true;
> TCSReader.java:    core[0].falseColor = true;
> ZeissZVIReader.java:    core[0].falseColor = true;
>
> I agree with Gabriel that it would be nice if open standards (e.g., 
> OME-TIFF) supported indexed color, as well as a flag to differentiate, 
> rather than merely using a convention. But for proprietary formats, 
> this heuristic has worked fairly well so far.
>
> -Curtis
>
> On Mon, Dec 13, 2010 at 4:35 AM, Gabriel Landini <G.Landini at bham.ac.uk 
> <mailto:G.Landini at bham.ac.uk>> wrote:
>
>     On Monday 13 December 2010 10:52:34 Johannes Schindelin wrote:
>     > 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.
>
>     Sure.
>
>     > 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 agree here too, but most people will want to save greyscale
>     images with a
>     viewing palette while preserving the underlying data.
>
>     The problem is how to tell apart a greyscale with a viewing LUT
>     (underlying
>     numeric, indexing a palette) from one with an unordered palette
>     (indexed).
>     One way could be to implicitly record this at creation time (let's
>     say if
>     saved as GIF, or after applying some colour reduction) by adding a
>     flag
>     indicating so. But of course, all externally created images would
>     not have
>     this tag.
>
>     But going back to the original problem, if the palette -at file
>     creation time-
>     is the Grays.lut, then it should be saved without a palette. I
>     wonder if this
>     would solve the reported problem.
>
>     Cheers
>
>     Gabriel
>
>
>     _______________________________________________
>     ImageJ-devel mailing list
>     ImageJ-devel at imagejdev.org <mailto:ImageJ-devel at imagejdev.org>
>     http://imagejdev.org/mailman/listinfo/imagej-devel
>
>
>
> _______________________________________________
> ImageJ-devel mailing list
> ImageJ-devel at imagejdev.org
> http://imagejdev.org/mailman/listinfo/imagej-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20110110/b5ef27c8/attachment.html>