Warning: Can't synchronize with repository "(default)" (/home/git/ome.git does not appear to be a Git repository.). Look in the Trac log for more information.
Notice: In order to edit this ticket you need to be either: a Product Owner, The owner or the reporter of the ticket, or, in case of a Task not yet assigned, a team_member"

Task #9773 (closed)

Opened 11 years ago

Closed 11 years ago

Bug: Amira image corrupted when viewing using FS

Reported by: rleigh Owned by: mlinkert
Priority: critical Milestone: OMERO-4.4.7
Component: Bio-Formats Version: n.a.
Keywords: FS Cc:
Resources: n.a. Referenced By: n.a.
References: n.a. Remaining Time: n.a.
Sprint: n.a.

Description

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.

Attachments (6)

Screen shot 2012-10-22 at 11.19.23.png (32.8 KB) - added by rleigh 11 years ago.
Insight
Screen shot 2012-10-22 at 11.20.56.png (18.2 KB) - added by rleigh 11 years ago.
showinf
Screen shot 2012-10-24 at 10.17.39.png (91.6 KB) - added by rleigh 11 years ago.
Screen shot 2012-10-24 at 10.19.03.png (92.8 KB) - added by rleigh 11 years ago.
Screen shot 2012-10-24 at 10.26.09.png (65.3 KB) - added by rleigh 11 years ago.
Screen shot 2012-10-24 at 10.27.27.png (65.4 KB) - added by rleigh 11 years ago.

Download all attachments as: .zip

Change History (12)

Changed 11 years ago by rleigh

Insight

Changed 11 years ago by rleigh

showinf

comment:1 Changed 11 years ago by mlinkert

  • Resolution set to fixed
  • Status changed from new to closed

Changed 11 years ago by rleigh

Changed 11 years ago by rleigh

comment:2 Changed 11 years ago by rleigh

  • Resolution fixed deleted
  • Status changed from closed to reopened

comment:3 Changed 11 years ago by 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

Changed 11 years ago by rleigh

Changed 11 years ago by rleigh

comment:4 Changed 11 years ago by 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.

comment:5 Changed 11 years ago by rleigh

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

comment:6 Changed 11 years ago by mlinkert

  • Resolution set to fixed
  • Status changed from reopened to closed

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.

Note: See TracTickets for help on using tickets. You may also have a look at Agilo extensions to the ticket.

1.3.13-PRO © 2008-2011 Agilo Software all rights reserved (this page was served in: 0.64879 sec.)

We're Hiring!