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

[Curtis Rueden]

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>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
> http://imagejdev.org/mailman/listinfo/imagej-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20110110/d2905cfd/attachment.html>