Hi,<br><br><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote">The problem is how to tell apart a greyscale with a viewing LUT (underlying<br>
numeric, indexing a palette) from one with an unordered palette (indexed).<br>
One way could be to implicitly record this at creation time (let's say if<br>
saved as GIF, or after applying some colour reduction) by adding a flag<br>
indicating so. But of course, all externally created images would not have<br>
this tag.<br></blockquote><br>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).<br>
<br>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.<br>
<br>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:<br>
<br><div style="margin-left: 40px;">: curtis@rook ~/code/LOCI/software/components/bio-formats/src/loci/formats/in<br>grep falseColor *.java | grep true<br>BioRadReader.java: core[0].falseColor = true;<br>LeicaHandler.java: coreMeta.falseColor = true;<br>
LeicaReader.java: core[i].falseColor = true;<br>NativeND2Reader.java: core[i].falseColor = true;<br>OMEXMLReader.java: core[i].falseColor = true;<br>TCSReader.java: core[0].falseColor = true;<br>ZeissZVIReader.java: core[0].falseColor = true;<br>
</div><br>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.<br>
<br>-Curtis<br><br><div class="gmail_quote">On Mon, Dec 13, 2010 at 4:35 AM, Gabriel Landini <span dir="ltr"><<a href="mailto:G.Landini@bham.ac.uk">G.Landini@bham.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">On Monday 13 December 2010 10:52:34 Johannes Schindelin wrote:<br>
> IMHO an index-color image is _not_ of a numeric type. So to properly<br>
> support index-color images, one would need to make a "CategoricalType"<br>
> that still uses bytes or shorts, but that cannot add/multiply/whatever.<br>
<br>
</div>Sure.<br>
<div class="im"><br>
> OTOH if the LUT is just a view mode (as it should always be seen in<br>
> scientific imaging), then the LUT is not part of the image and should not<br>
> be saved in the first place.<br>
<br>
</div>I agree here too, but most people will want to save greyscale images with a<br>
viewing palette while preserving the underlying data.<br>
<br>
The problem is how to tell apart a greyscale with a viewing LUT (underlying<br>
numeric, indexing a palette) from one with an unordered palette (indexed).<br>
One way could be to implicitly record this at creation time (let's say if<br>
saved as GIF, or after applying some colour reduction) by adding a flag<br>
indicating so. But of course, all externally created images would not have<br>
this tag.<br>
<br>
But going back to the original problem, if the palette -at file creation time-<br>
is the Grays.lut, then it should be saved without a palette. I wonder if this<br>
would solve the reported problem.<br>
<br>
Cheers<br>
<font color="#888888"><br>
Gabriel<br>
</font><div><div></div><div class="h5"><br>
<br>
_______________________________________________<br>
ImageJ-devel mailing list<br>
<a href="mailto:ImageJ-devel@imagejdev.org">ImageJ-devel@imagejdev.org</a><br>
<a href="http://imagejdev.org/mailman/listinfo/imagej-devel" target="_blank">http://imagejdev.org/mailman/listinfo/imagej-devel</a><br>
</div></div></blockquote></div><br>