search

ome / ngff

Next-generation file format (NGFF) specifications for storing bioimaging data in the cloud.
https://ngff.openmicroscopy.org
Other
115 stars 38 forks source link

Progressive specification #32

Closed jni closed 3 years ago

jni commented 3 years ago

To elaborate on @joshmoore's summary of my comment here:

https://forum.image.sc/t/next-call-on-next-gen-bioimaging-data-tools-feb-23/48386/9

Minimal, or intermediate, specification: @DragaDoncila and @jni pointed out that some of the specifications are more general purpose and make the current well-suited for non-microscopy data. It is likely worth keeping the specification “approachable” for outsiders with the most general purpose specifications coming first to engage with as many communities as possible.

We should organise the spec progressively, so that you can, say, minimally claim to be an ome-ngff image with just a zarr array and a .zattrs containing {ome-ngff: v0.2} or whatever.

Next, if we want voxel spacing, you can optionally add {'dimensions': ['t', 'c', 'y', 'x']} (note lack of z 😉) and {'spacing': {'t': 5, 'y': 0.5, 'x': 0.5}}. (Happy to argue about whether spacing should be a dict or a list, I'm on the fence about it.) Optionally: {'units': {'t': 's', 'y': 'um', 'x': 'um'}}.

I think strict requirements should be as minimal as possible, and in terms of the ordering of elements within the spec, we should front load those according to how many communities it affects. So, things like "electron beam intensity" should be far down the list because it only affects people who image with electrons, while voxel spacing affects ~everybody.

One question I have is whether there is scope for this format to be more general than the M in OME implies. From @DragaDoncila's and my work, it seems many more communities could make use of this format, so it would be pretty nice if we can keep it generic enough so that they can use it, even if non-microscopy uses are lower in the list of priorities.

imagesc-bot commented 3 years ago

This issue has been mentioned on Image.sc Forum. There might be relevant details there:

https://forum.image.sc/t/next-call-on-next-gen-bioimaging-data-tools-feb-23/48386/9

constantinpape commented 3 years ago

I think this approach is relatively close to what we have settled on, with dimensions being implemented in v0.3 (though mandatory instead of optional). Both units and spacing (though more general in the sense of transformations from pixel to physical space) are on the agenda for v0.4 (We will talk about this more in the meeting tomorrow). So I am closing this issue for now, feel free to reopen if you think there is something here I overlooked.