Image index and format considerations

[nicost]

The current API specifies an image as part of a 6D image dataset (i.e., XY, Z, time, channel, position) that are indexed using integers. This is straight forward, but experience has shown that we need to be prepared for more complicated image datasets. For instance, it will be difficult to fit hyperspectral data in this scheme (other than by adding many, many channels), so do we want to be prepared and have the number of axes be extendable (as an example, see the Coords class in Java MMStudio: https://github.com/micro-manager/micro-manager/blob/main/mmstudio/src/main/java/org/micromanager/data/Coords.java)? Likewise, indexing by other objects than integers appears to desirable (at least the PycroManager implementation of "Coords" took that approach), so we may want to consider that option. It would also be nice to - at least optionally - bring position in the same Cartesian coordinates as the XY plane so that assembling large images from multiple images (stitching) becomes easy.

Another consideration is whether or not to allow for images of different sizes?

[tlambert03]

big +1 to this. The hard 5D/6D models are definitely out-moded these days. A more generic dimension model is a must in a new spec

[go2scope]

OK agreed, we need generalized dimensions, unlimited number of dimensions and variable image dimensions. We can provide an API that accomodates all of that, but the actual Storage Device should not be required to support all combinations. For some file formats that would be impossible or wouldn't make sense.

It seems that is inevitable that we have to transmit our dimensional requirements to the Storage Device before acquisition and give it a chance to throw an error at that point, rather than failing later in the middle of acquisition.