Support voxel size in other units than nm

[hotzenklotz]

Detailed Description

ATM, voxel size is defined in nm. While that is good default for high-resolution EM datasets, it is very impractical for MRI/CT dataset, light microscopy, and low-resolution, large FOV EM scans.

We should refactor the voxel size such that the actual unit does not matter as much as long as the ratio is correct, e.g., 150x150x300nm vs 150000x150000x300000nm (converted from um) == 15x15x30 .

Maybe the unit could be selected from a dropdown in the UI and wK does all the conversion internally.

This is also relevant for any work for correlative, multi-scale datasets. Related to #6085

Context

• Specific to long-running jobs (set jobsEnabled=true in application.conf)
• Specific to webKnossos.org (set isDemoInstance=true in application.conf)

[fm3]

We would also have to decide if the internal float32 nm representation is still good enough. If so, this is a frontend-only issue. If we need very large voxel sizes, say, multiple meters (e.g. for geodata?), we would have to change the internal representation too (possibly storing the unit) to not lose precision.

[philippotto]

If we need very large voxel sizes, say, multiple meters (e.g. for geodata?), we would have to change the internal representation too (possibly storing the unit) to not lose precision.

I think, storing the unit in addition to the scale would be a good approach. The migration would be easy (a missing unit would default to nm). Most of the front-end code wouldn't need to be touched (as often only the relations are important for code correctness). Only the parts where the actual unit is important to the user would need adaption. This is also in line with @hotzenklotz suggestion:

We should refactor the voxel size such that the actual unit does not matter as much as long as the ratio is correct

This would automatically fix/improve some things, such as:

• move speed would be in the appropriate order of magnitude
• clipping distances in the 3D viewport wouldn't have problems with large numbers for "large" physical distances (e.g., meters)

[will-moore]

Hi - this issue would include the ability to read units from e.g. OME-NGFF.
When I import an image with microns: e.g. https://uk1s3.embassy.ebi.ac.uk/idr/zarr/v0.4/idr0062A/6001240.zarr
the pixel size values are read correctly but the units are ignored:
Public view at https://webknossos.org/datasets/18c44a2271fb102d/omeroinfo/view?token=8QbWDRXlCP9aWxxQUHzayQ

[fm3]

read units from e.g. OME-NGFF.

Hmm, I feel like this should already work. Thanks for the report, we’ll have a look!

[fm3]

@will-moore It looks like the multiscales metadata at https://uk1s3.embassy.ebi.ac.uk/idr/zarr/v0.4/idr0062A/6001240.zarr/.zattrs uses the keyword units in the axis definitions. In https://ngff.openmicroscopy.org/latest/#axes-md only unit (singular) is mentioned, which is what webKnossos parses. Is units an established keyword as well? In this case, we can add support for that too.

[will-moore]

Whoa - Ooops! That looks like our mistake there...

Checking the ngff repo I see that the schema uses "units": https://github.com/ome/ngff/blob/0a087b8319b234a0682bc4853e390314f76f7540/0.4/schemas/image.schema#L127
whereas the example files use "unit"
https://github.com/ome/ngff/blob/main/0.4/examples/multiscales_strict/multiscales_example.json
and some of the test files use both! https://github.com/ome/ngff/blob/0a087b8319b234a0682bc4853e390314f76f7540/0.4/tests/strict_image_suite.json

I guess the issue here is that having "unit" when the schema states "units" is not actually invalid, as the schema allows unknown keys to be added.

Thanks for the pointer.
I'll create an issue on the ngff repo to address this...
cc @sbesson @joshmoore

[will-moore]

With the sample at https://uk1s3.embassy.ebi.ac.uk/idr/zarr/v0.4/idr0062A/6001240.zarr fixed units => unit and re-imported (at https://webknossos.org/datasets/308ffc5547d41748/6001240_unit.zarr/view?token=KPCLCYXHd50RR7aAULPknA) I can confirm that "unit": "micrometer" is read correctly:

Thanks!

[normanrz]

I think we should revive this.

[MichaelBuessemeyer]