Can convert pass the most important information from micromanager image plane metadata?

[talonchandler]

Background: Earlier version of the tiff-to-zarr convert command would write all of the micromanager image plane metadata to text files. Micromanager writes metadata for each plane, so the resulting files were too large to be practical and the latest versions no longer convert this metadata.

Proposal: I think we're now in a position to improve the conversion so that the most important information is correctly read and transferred. I think the most important pieces of image plane metadata are related to the "scale/units" of the data:

• PixelSizeUm and z-step_um can be written to the output array scale transformation metadata.
• Exposure times and time steps might not be suitable for the scale transformations (?), but I think they deserve to live in the converted zarrs
• others? IMO there's not need to transfer all of the device-state metadata, but @ieivanov or @edyoshikun might have preferences here?

[talonchandler]

@mattersoflight, @edyoshikun, and I just discussed this issue offline, and we agreed that scale information for the P, T, Z, Y, and X dimensions would be extremely valuable for iohub.

@ziw-liu, you brought up some technical issues that may make this difficult, and we're hoping to tighten the scope so that this isn't an enormous requirement. I would propose calling this issue "closed" if:

• the converter passes the P, T, Z, Y, and X scale information---no need for any other MM metadata
• for P, we transfer the stage positions from XPositionUm and YPositionUm
• for T, we transfer ElapsedTime-ms (or possibly something like a delta-T from the MDA?)
• for Z, we're already passing z-step_um, so I think it's complete.
• for Y and X, we transfer "PixelSizeUm".
• the passing works for datasets acquired with the most recent version of MM---no need to test against old MM versions.

I'm happy to tighten this issue even more if there are further difficulties I don't understand.

[ziw-liu]

• the passing works for datasets acquired with the most recent version of MM---no need to test against old MM versions.

In addition to MM version discrepancies, also notice that these fields are specific to OME-TIFF. For example NDTIFF files from pycro-manager does not have a standard OME metadata tag that stores these information. It will likely require different implementation for each of these fragmented state of TIFF files.

[JoOkuma]

I had collaborators ask for the time stamp of the acquisition of each volume.
Can a list of length T be saved somewhere in the metadata after conversion?
Is that information also available when acquired from MM?

[ziw-liu]

Can a list of length T be saved somewhere in the metadata after conversion?

It can be stored. The question is where do we store it, since that will be a custom field in the JSON if there's no existing standard.

Is that information also available when acquired from MM?

It requires some parsing, but yes you can get the camera timestamp and the file timestamp from MM datasets.

[ziw-liu]

• for P, we transfer the stage positions from XPositionUm and YPositionUm

Does this need to get encoded with a coordinate translation (as shown in #75 (comment)) or a dumped into a custom field?

[talonchandler]

I think encoding in a coordinate translation would be excellent.

[mattersoflight]

for P, we transfer the stage positions from XPositionUm and YPositionUm

Does this need to get encoded with a coordinate translation (as shown in #75 (comment)) or a dumped into a custom field?

This will be nice to have. One wrinkle is that we are using coordinate transformations to place FOVs in one well. Mapping (XPositionUm, YPositionUm) -> coordinate transformation requires parsing which FOV is at the center.

@ziw-liu if this turns out to be non-trivial, I suggest two PRs:

• save metadata to converted zarr store, and translate fields that can be directly mapped (the topic of this issue).
• more precise mapping of spatial and temporal coordinates (@JoOkuma and @talonchandler's input).

[ziw-liu]

Related discussion about specification: ome/ngff#199

Edit: if ome/ngff#138 gets accepted the timestamps (or generally coordinates) will be stored as separate non-image arrays. Adding this array right now shouldn't affect practical conformance (i.e. viewers functionality) either.