Fiji support for RFC-3

[jni]

It would be good if Fiji could read at least some RFC-3 conformant datasets, and/or produce informative error messages when that was not possible.

[jni]

@bogovicj @ctrueden I don't actually know the state of "arbitrary dimensions" in Fiji. Can a 6D (e.g. 3D+t FLIM) dataset be displayed in plain ol' Fiji? In BDV?

See clbarnes/ome-zarr-rfc3-data#1 (comment) for some 4D and 6D sample data.

[bogovicj]

Can a 6D (e.g. 3D+t FLIM) dataset be displayed in plain ol' Fiji? In BDV?

Not really, certainly not in a standard way.

For Fiji, a custom viewer would be needed, which isn't hard to build, just work.

BDV should have better built-in support for additional dimensions, but it's not there now. A use case like this would be a good motivator!

[jni]

What would happen if one attempted to open a 6D dataset, e.g. from Leica? ex:

https://ftp.ebi.ac.uk/biostudies/fire/S-BIAD/967/S-BIAD1967/Files/lifetime_separation/study_component_embryos/TMR31_3.lif (5.83GB) or https://ftp.ebi.ac.uk/biostudies/fire/S-BIAD/967/S-BIAD1967/Files/lifetime_separation/study_component_hermaphrodites/AZ212.lif (1.17GB)?

The RFC specifies that partial implementations are OK:

This proposal is agnostic as to what to do in those situations, and indeed the appropriate action depends on the tool, but some suggestions include:

• fail with an informative error message. (i.e. partial implementations are OK, especially if well-documented.)
• prompt the user about which axes to treat as spatial.
• arbitrarily choose which axes to treat as spatial.
• choose how to treat each axis based on heuristics such as size and position.

and:

[This RFC] also takes the position that partial implementations are OK: a software package designed to view xyz volumetric, light microscopy data should feel free to error when presented with axes foo, bar, and baz with type “arbitrary”.

And I'm wondering whether a stopgap such as those suggested above would be "easy" to add in either case. (Or, more precisely, whether it would be >1 order of magnitude easier than a "true" implementation, and therefore worth doing as a stopgap.)

[bogovicj]

What would probably happen, and maybe one of the few reasonable choices would be for any extra dimension to be swallowed into one of the other dimensions, say "channels".

this would mean that a

  X    Y   Z  C  T  A  B
128  128  64  8  8  8  8 

would appear like this:

  X    Y   Z    C  T 
128  128  64  512  8 

with the interpretation of the channel dimension messed up This would be quite easy to implement actually.

Better, but slightly more work be a user prompt for slices of the extra dimensions.
One of these would be a reasonable stopgap.

A custom display that shows all the extra dimensions would count as full support right? That's a substantial but not crazy amount of work. The main downside would be that nothing that uses the older "ImageJ1" data model could work with it. The newer "ImageJ2" data model does and could support nD, fortunately.

[jni]

I'd say any of these count! For the first suggestion (merging all the axes), you'd want to at least print a message to the console, right? But after that I would consider it an MVP.