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
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.
This has been implemented in C++ and it is working.