write_image() API limitations

[will-moore]

Expanding on list at #407...

• write_image() only downsamples in 2D (x and y) 👎 Scaler not scaling all dimensions #262
• No control of downsample factor.
• Not easy to write pixel sizes. Scale starts at [1, 1, 1, 1, 1]. If you want to supply pixel sizes, the only way to do this is via coordinate_transformations but it's a real pain to know how long to make the list. See Coordinate transformations length #481. Also you have to fully specify axes.
• Axes created automatically: 'type' inferred by name. No units.

[FIrgolitsch]

I'm not sure if there was already a way planned for dealing with the 3D scaling, but when I was first attempting, I thought of using the type property in the axes metadata. I was thinking of scaling each axis with the type space. I never ended up implementing it. I ended up with a crude extension of the Scaler class, which just overwrites some of the functionality, as we are using only volumetric data anyway. It does support a scaling factor and has some messy attempt at upscaling as well. We use it for categorical data mostly, like masks. It's available here:

https://github.com/LIOMLab/liom-toolkit/blob/main/liom_toolkit/utils/io.py#L261

There are some methods to create the coordinate transformation dictionaries and the axes array as well.
Another repo I'm working on has similar work, some of it a bit more refined:

https://github.com/linum-uqam/linumpy/blob/main/linumpy/io/zarr.py

[will-moore]

ngff-zarr has a scale option ("the pixel spacing for the spatial dims"), e.g.

scale={'y': 1.0, 'x': 1.0},

and for downsampling it has

scale_factors (int of minimum length, int per scale or dict of spatial dimension int's per scale) – If a single integer, scale factors in spatial dimensions will be increased by a factor of two until this minimum length is reached. If a list, integer scale factors to apply uniformly across all spatial dimensions or along individual spatial dimensions. Examples: 64 or [2, 4] or [{‘x’: 2, ‘y’: 4 }, {‘x’: 5, ‘y’: 10}] Scaling is constrained by size of chunks

EDIT: the scale option could alternatively be in the form of a list: [1.0, 1.0, 0.4, 0.5, 0.5] which is how scale is stored in a coordinateTransform. I don't think there is much to choose from when comparing this to {'y': 0.5, 'x': 0.5}.

If we are going to calculate coordianteTransformations, we could also fix #403.