search

ome / ngff

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

Thickness of 2D slice #103

Open tischi opened 2 years ago

tischi commented 2 years ago

For some microscope modalities one collects 2D images, but it can make sense to still assign them a physical thickness along axis perpendicular to the 2D plane, e.g the axial extend of the PSF in light microscopy or the section thickness in TEM.

Such a thickness is interesting for analysis but also for rendering, e.g. when stacking many slices and then looking at them from the side.

How could we represent this in OME-Zarr? Would we store the data as 3D with the 3rd dimension having a length of one in dataspace?

constantinpape commented 2 years ago

Would we store the data as 3D with the 3rd dimensions stuck having a length of one in dataspace?

Yes, I think this is the only good solution for this.

will-moore commented 2 years ago

I had a similar issue when I wanted to translate a 2D Z-slice midway into a Z-stack in napri: The OME-NGFF couldn't store a Z translate as it only had 2 axes.

tischi commented 2 years ago

@bogovicj what do you think (in terms of transformations spec) about the above discussion?

bogovicj commented 2 years ago

I agree with you all that this is useful, and how to do it.

Perhaps I'll include something like the following in the transformation spec:

"Transformations may be applied to points of lower dimension. If so, the points must be implicitly projected to the higher dimension by appending zeros to the coordinate vector [p1, p2] > [p1, p2, 0] ."

thewtex commented 2 years ago

In medical imaging (DICOM), there is a slice thickness stored for many 3D modalities, but this is different from the sampling distance in the third dimension (although they are usually related). When extracting a 2D slice from this 3D dataset, in many cases we would like the rendering to be the same as it was in 3D -- based on the sampling distance.

For OME metadata (#104) is there point spread function (PSF) support? Could this be used for this use case?