Bug: Amira image corrupted when viewing using FS

[rleigh]

See attached screenshots of showinf and Insight. After importing with insight, you just see a couple of lines of noise, rather than the structure seen with showinf.

Looks like a separate issue to #9712--it's not just mis-registration.

[rleigh]

Insight

[rleigh]

showinf

[mlinkert]

PR opened against develop: ​https://github.com/openmicroscopy/bioformats/pull/186

[rleigh]

Please see the attached two screenshots

Screen shot 2012-10-24 at 10.17.39.png

and

Screen shot 2012-10-24 at 10.19.03.png

The first shows that there's a visual artifact on plane 151 in Insight.
The second shows that there's a discrepancy in the z plane number for a given image plane.

I've also attached a further two screenshots of the webclient; here the visual artifact is again present, but slightly different, but the actual image is not visible at all.

Note that it looks like the actual index numbers in the palette (0, 1, 2) are being used directly as uint8 greyscale--I've had to adjust the range to (0,2). Should this be converted directly to RGB? Or should the clients be able to deal directly with indexed colour?

Regards,
Roger

[mlinkert]

I suspect that both the Z plane index difference and the artifact on plane 151 are different manifestations of the same bug; working on a fix now.

With respect to the indexed color issue, what OMERO shows is technically correct. Color lookup tables are completely ignored by OMERO, and instead the decision of whether or not to expand a lookup table into an RGB image is left to loci.formats.ChannelFiller? and the return value of isFalseColor() in IFormatReader (falseColor in CoreMetadata?). If isFalseColor() returns false, that means that the "real" image data is in the lookup table, and so ChannelFiller? will apply the lookup table by expanding the single channel into an RGB image. If isFalseColor() returns true, that means that the "real" image data is the indices into the table (as is the case with e.g. Leica .lei). ChannelFiller? then does not apply the lookup table, because doing so would throw away the indices.

What this means is that for each reader, we've made a judgement call as to whether or not the lookup tables for files in that format contain the real data or not. For Amira, in general, my opinion is that the indices are the real data. Admittedly, this doesn't appear to be the case for Hiv_spikes.am, but as far as I can tell there is no way to tell on a per-file basis whether or not the indices are the real data.

In discussing briefly with Chris, we may be able to allow the user to toggle the lookup tables client-side now that we are reading directly from the original file. Probably something worth discussing with a broader group when we're all together in a couple of weeks.

[rleigh]

Thanks. I've opened a separate ticket for the OMERO not using ChannelFiller? issue.

[mlinkert]

Off-by-one fixed on PR #186.

The issue with plane 151 turns out to not really be solvable - while it looks wrong, the values there are correct with respect to what is actually in the file. The corresponding lookup table values are all 0, though, so applying the lookup table makes plane 151 completely blank.