Ticket #18 (closed enhancement: fixed)
Opened 2007-03-16T13:43:11-05:00
Last modified 2007-03-29T16:48:15-05:00
Support for additional dimensions (wrapped into channel)
Reported by: | curtis | Owned by: | curtis |
---|---|---|---|
Priority: | major | Milestone: | |
Component: | bio-formats | Severity: | |
Keywords: | Cc: | ||
Blocked By: | Blocking: |
Description (last modified by curtis)
Bio-Formats strongly supports OME's 5D model (XYZCT), but LOCI collects data with additional dimensions such as spectral channels and lifetime bins. The "OME way" to handle this situation is to wrap these extra dimensions into C, since each is a special case of C.
To handle such cases in Bio-Formats, we want to provide additional API methods int[] getChannelDimLengths(String) and String[] getChannelDimTypes(String). The former would return the lengths of all subdimensions of C, in fastest-to-slowest rasterization order, and the latter gets the name of each subdimension. Common subdimensional types (i.e., spectra, lifetime and polarization) should have dedicated constants in FormatTools. Alternately, we could use an enumerated list of integer constants, but that solution prevents custom subdimension types. As for converting between subdimensional indices and rasterized C index, FormatTools already provides the positionToRaster, rasterToPosition and getRasterLength methods for easily converting back and forth (similar to getZCTCoords and getIndex).
The default implementation of getChannelDimLengths would return a single component equal to sizeC, and getChannelDimTypes would return a single component equal to "channel" (the generic channel type).
Support for subdimensions would allow SDTReader to properly describe all dimensions of its data, as well as enable FileStitcher to be a bit more verbose about its dimensional structure in certain cases as well (when there are several numerical blocks). It would also simplify VisBio, because we could remove much of VisBio's N-dimensional import logic.