metadata support time series

[bogovicj]

@igorpisarev (@axtimwalde )

I really like the idea of N5ExportMetadata and so started expanding it to include support for time series, see here.

One outstanding question is how to deal with datasets that are multi-channel but not time series, or time series but not multi-channel. Perhaps it makes sense to have a hierarchy when both are present i.e.

/c0/t0
/c0/t1
/c1/t0
/c1/t1

but not otherwise.

Ps. I'm bringing this up because the current version of the imageJ plugin for multiscale export to n5 uses this framework (ExportImagePlusToN5Plugin)

[axtimwalde]

I am not crazy about this. My preferred solution would be to not treat channels and time points as special dimensions but have them be part of the dimensional hierarchy---that would also solve the issue of what to do when there is one of them missing.

Reason: We store blocks as

0/0/0, not x0/y0/z0

For convenience, the block-size in these dimensions could be set to 1 but wouldn't have to be.

Thoughts?

On Mon, 2019-01-28 at 09:42 -0800, John Bogovic wrote:

@igorpisarev (@axtimwalde ) I really like the idea of N5ExportMetadata and so started expanding it to include support for time series, see here. One outstanding question is how to deal with datasets that are multi- channel but not time series, or time series but not multi-channel. Perhaps it makes sense to have a hierarchy when both are present i.e. /c0/t0 /c0/t1 /c1/t0 /c1/t1 but not otherwise. Ps. I'm bringing this up because the current version of the imageJ plugin for multiscale export to n5 uses this framework (ExportImagePlusToN5Plugin) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[igorpisarev]

I agree that it would make it easier to always store the timepoint groups, even if there is only one. This would follow the BDV HDF5 format more closely and would also simplify the conversion. But, it would be nice to keep it backwards-compatible and still support the old format where the timepoints may be omitted.

I do like the explicit group naming scheme and the proposed hierarchy /c0/t0/s0/, as in contrast to the data itself, each of these needs to be handled differently, and it makes it clear which is which. Also, the datasets (in N5 sense) here are always 3D, and the rest (channels, mipmaps, and now timepoints) are just groups and not extra dimensions.

There are also a few optional metadata fields such as pixel resolution and affine transformation. In the current design, they can be specified for an entire N5 container in its root attributes, or on per-channel basis in its group attributes. This is useful, for instance, when the channels need to be aligned with each other. I'm not sure if it may be needed to specify them on per-timepoint basis, but to make it generalized enough it can be supported as well.

[bogovicj]

For convenience, the block-size in these dimensions could be set to 1 but wouldn't have to be.

In discussing with Tobias last week, he said he liked keeping datasets 3d all the time. The big downside I see in grouping time is that it would mean having to load timepoints you're not currently looking at, but this proposal would address that issue.

My preferred solution would be to not treat channels and time points as special dimensions but have them be part of the dimensional hierarchy---that would also solve the issue of what to do when there is one of them missing.

Agree that it's alot nicer when dimensions are "missing," but then should we recommend that N5 datasets also label the dimensions for XYZCT in the metadata? especially if it's not indicated by which dataset it belongs to.

[bogovicj]

Closing this in favor or future NGFF support