Skip to content
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

Ensure Plane DeltaT values are stored into SCIFIO axes #17

Open
hinerm opened this issue Mar 17, 2014 · 3 comments
Open

Ensure Plane DeltaT values are stored into SCIFIO axes #17

hinerm opened this issue Mar 17, 2014 · 3 comments

Comments

@hinerm
Copy link
Member

hinerm commented Mar 17, 2014

Depends on imglib/imglib2#64

If there are Plane DeltaT values present in OME-XML, we should ensure the Axes of the parsed/translated metadata store them appropriately.

@stelfrich
Copy link

@ctrueden's comment ("non-linear SCIFIO axes to store the time stamps in a data-model-agnostic way") in fiji/fiji#74 got me interested in that topic.

I dug a little into the code and stumbled across the ImageMetadata API that supports only one axis per Image. Correct me if I am wrong but doesn't that assume that two Planes from different channels have been acquired at the same time since they can be only mapped to one time-Axis?

If that topic is off the table, feel free to ignore my comment 😄

@ctrueden
Copy link
Member

ctrueden commented Jun 5, 2016

Whoa, how has this PR been sitting for over two years? Because the upstream imglib2 PR has sat that long? Maybe we can resolve this in the upcoming data model hackathon, as part of our work on the RichImage.

@stelfrich You're right: the fact that every Plane in OME-XML can have a different DeltaT is more flexible than ImageJ2's axis-driven metadata model. The original "variable width time stamper" would not require the more flexible sort of metadata—just a non-linear time axis. But if we want to fully support what different file formats are already storing sometimes, I guess we need to make the metadata model more flexible. I fear the complexity but it seems like the correct thing to do.

@stelfrich
Copy link

Maybe we can resolve this in the upcoming data model hackathon, as part of our work on the RichImage.

That was @dietzc's idea as well.

I fear the complexity [...]

We just have to find a good balance between complexity and usability (as always). The use case that got me interested is actually pretty simple: label each slice of an image sequence with time stamps where the first time point shall be the DeltaT of that Image (speaking in OME-XML terms). While it might be "easy" to extend the metadata model to support that case (just using one enumerating axis per Image), the image sequence is put in the broader context of an experiment which is not as easy to determine/model..

Another use case that crossed my mind is a rather common setup in live cell fluorescence imaging: acquire a widefield image every 5 minutes and a fluorescence image every 20 minutes. The acquired image sequence is one Image with the two channels having different Axis. That would be the most obvious example to start thinking about a more complex metadata model..

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants