You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have brought this up here previously, but it deserves its own discussion in the context of this extension proposal.
I think it is worth considering defining the data as a 5 dimensional array which can have the following dimensions: X, Y, C, Z, T
This is how it is done in the OME standard which is widely used in biological sciences. Here is a minimal example, where with the properties SizeX, SizeY, SizeZ, SizeC, SizeT and DimensionOrder the shape is explicitly defined, and does not rely on the schema specification/description enforcing a specific dimension order. https://docs.openmicroscopy.org/ome-model/6.3.1/specifications/minimum.html?highlight=dimensionorder
I think this is important for two reasons:
People do all sorts of microscopy recordings, from single channel linescans to multichannel volumetric imaging. There are two ways to capture this. The first is to define many different data types, as has been suggested here. If going in that direction, why stop at a time independent image? You would need a Linescan Datatype (XT), a single channel image datatype, a multi channel datatype, a single plane datatype and a multiplane data type and combinations/permutations of these. In other words, what is special about the time dimension to warrant a specific data type in the case there the dimension is a singleton dimension. The second is to define a 5D data type where one or multiple dimensions are allowed to be singleton dimensions as has been done in OME.
With regards to efficient data reading (especially relevant if data is accessed remotely which is more and more common) it will be variable what are the preferred dimensions and dimension orders to perform reading along. For some data, it might be more important to be able to read multiple channels in one read operation, in others multiple planes and yet in other multiple timepoints.
Ideally, it would also be possible to set the dimension order to keep the data stored in the manner which is most efficient for that specific data. As long as the dimension order is explicitly defined, it's straight forward for readers/viewers to permute the data to match the dimension order which is required for that specific instance.
The text was updated successfully, but these errors were encountered:
I have brought this up here previously, but it deserves its own discussion in the context of this extension proposal.
I think it is worth considering defining the data as a 5 dimensional array which can have the following dimensions: X, Y, C, Z, T
This is how it is done in the OME standard which is widely used in biological sciences. Here is a minimal example, where with the properties
SizeX
,SizeY
,SizeZ
,SizeC
,SizeT
andDimensionOrder
the shape is explicitly defined, and does not rely on the schema specification/description enforcing a specific dimension order.https://docs.openmicroscopy.org/ome-model/6.3.1/specifications/minimum.html?highlight=dimensionorder
I think this is important for two reasons:
People do all sorts of microscopy recordings, from single channel linescans to multichannel volumetric imaging. There are two ways to capture this. The first is to define many different data types, as has been suggested here. If going in that direction, why stop at a time independent image? You would need a Linescan Datatype (XT), a single channel image datatype, a multi channel datatype, a single plane datatype and a multiplane data type and combinations/permutations of these. In other words, what is special about the time dimension to warrant a specific data type in the case there the dimension is a singleton dimension. The second is to define a 5D data type where one or multiple dimensions are allowed to be singleton dimensions as has been done in OME.
With regards to efficient data reading (especially relevant if data is accessed remotely which is more and more common) it will be variable what are the preferred dimensions and dimension orders to perform reading along. For some data, it might be more important to be able to read multiple channels in one read operation, in others multiple planes and yet in other multiple timepoints.
Ideally, it would also be possible to set the dimension order to keep the data stored in the manner which is most efficient for that specific data. As long as the dimension order is explicitly defined, it's straight forward for readers/viewers to permute the data to match the dimension order which is required for that specific instance.
The text was updated successfully, but these errors were encountered: