-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Per-frame metadata in UAPI #155
Comments
One caveat is that these information is not always available. So they cannot be guaranteed as other #132 attributes are. |
The It will be useful if the UAPI specifies how to handle per-image metadata (e.g. image timestamp, state of microscope hardware at this image), per-FOV metadata (e.g. FOV XYZ coordinates, FOV label), and per-dataset metadata (e.g. data dimensions, microscope name, user, sample conditions, etc.) |
I really like the signature you're proposing @ziw-liu:
Building on this, maybe the per-frame metadata can be accessible via:
the per-FOV metadata via:
and the per-dataset metadata via:
|
In my opinion the camera timestamp is no different than other image metadata and should be simply contained in the |
I think this attribute should be an immutable type instead of a plain |
In #132 (comment) (@talonchandler) and #103 (comment) (@JoOkuma) the need for accessing each time stamp in a time lapse image is surfaced. However, implementing a clean API at the FOV level is not very straightforward, so we settled on a scalar (uniform delta) for FOVs.
In #151 a more general feature is requested by @ieivanov to access metadata specific to each frame.
IMO the XY frame is indeed a physically grounded entity (readout from the 2D camera sensor), and accessing metadata such as exact time stamp and hardware settings can be useful. It may reduce confusion if these is a shared API across file formats, but I think it adds too much complexity to let frames have their own type, so I'm imagining
BaseFOV
methods that will return these information given the coordinates. For example:And MMStack readers can have their own base class providing the specific hardware information.
The text was updated successfully, but these errors were encountered: