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 #11862 (new)

Opened 10 years ago

Last modified 8 years ago

Bug: OME-TIFF support for reading and writing complex pixel types

Reported by: rleigh Owned by:
Priority: minor Milestone: GatherReqs
Component: Bio-Formats Version: 5.0.0-beta2-RC3
Keywords: metadata Cc: ian.dobbie@…
Resources: n.a. Referenced By: n.a.
References: 11860 Remaining Time: n.a.
Sprint: n.a.

Description

The OME data model includes support for complex and double-complex pixel formats. The OME-XML and OME-TIFF readers and writers do not currently support these types, however. For OME-TIFF it should be possible to support using TIFFTAG_SAMPLESPERPIXEL=2 for the corresponding pixel format (float/double/etc).

We may need to support types in addition to float and double if these are in use by other image formats, and these would also need adding to the OME data model.

Change History (5)

comment:1 Changed 8 years ago by jburel

  • Milestone changed from Unscheduled to OME-Files

comment:2 Changed 8 years ago by jburel

  • Milestone changed from OME-Files to Metadata

This has been implemented in C++ and it is working.

comment:3 Changed 8 years ago by jburel

  • Milestone changed from Metadata to GatherReqs

comment:4 Changed 8 years ago by mlinkert

  • Keywords metadata added
  • Owner mlinkert deleted

See comment on https://trac.openmicroscopy.org/ome/ticket/12599#comment:10. As in that ticket, clarifying what openBytes should return for a single complex or double-complex pixel would be a helpful step. Deltavision, I2I, and Zeiss CZI are a few other readers that can contain complex pixel data; Deltavision in particular may be easier to use for testing this as the number of things that need to be updated is smaller than for TIFF/OME-TIFF.

NB: https://trac.openmicroscopy.org/ome/ticket/11860 is the parent ticket for complex pixel type work, and https://trac.openmicroscopy.org/ome/ticket/11861 is the corresponding Deltavision ticket.

comment:5 Changed 8 years ago by rleigh

Since openBytes is a "raw" byte stream I think it should be as simple as "float,float" or "double,double" i.e. "real,imag" for each pixel. We have the complication of PlanarConfiguration?, though perhaps in this case we should be transparently handling that and have a uniform layout (since these aren't sub channels from the OME model POV).

For the C++ interface, we return complex<float> or complex<double> in the nD pixel buffer, so it's completely unambiguous. openBytes would handle both chunky and planar sample arrangements. However, we should probably specify the exact precedence of the complex samples and any sub channels, e.g. if you for some reason had 3 sub channels the samples would be ordered r1 i1 r2 i2 r3 i3 (as opposed to r1 r2 r2 i1 i2 i3). I think it would make sense for the complex numbers to be more strongly associated than the sub channels. However, PhotometricInterpretation? won't make sense here in the TIFF format. We might want to think about moving it into the model; particularly if we want to use it for HDF5 as well, where any TIFF features not in the model (e.g. LUTs) need modelling for the non-TIFF case.

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.63059 sec.)

We're Hiring!