Flexible dimension ordering#166
Conversation
tests/test_zarr.py
Outdated
| dimension_x = acquire.StorageDimension() | ||
| dimension_x.name = "x" | ||
| dimension_x.kind = acquire.DimensionType.Space | ||
| dimension_x.array_size_px = 64 | ||
| dimension_x.chunk_size_px = 64 |
There was a problem hiding this comment.
Does this construction work?
| dimension_x = acquire.StorageDimension() | |
| dimension_x.name = "x" | |
| dimension_x.kind = acquire.DimensionType.Space | |
| dimension_x.array_size_px = 64 | |
| dimension_x.chunk_size_px = 64 | |
| dimension_x = acquire.StorageDimension(name="x", | |
| kind=acquire.DimensionType.Space, | |
| array_size_px=64, | |
| chunk_size_px=64) |
Also, we might support string translation for enums,
| dimension_x = acquire.StorageDimension() | |
| dimension_x.name = "x" | |
| dimension_x.kind = acquire.DimensionType.Space | |
| dimension_x.array_size_px = 64 | |
| dimension_x.chunk_size_px = 64 | |
| dimension_x = acquire.StorageDimension(name="x", | |
| kind="Space", | |
| array_size_px=64, | |
| chunk_size_px=64) |
I'm not sure which is best, but I like using the constructor here.
There was a problem hiding this comment.
The former construction doesn't work (but I think I could figure out how to make it work). I don't like string translation for the enums. The values are already there and AFAIK we don't do it for the other enums. I was wrong about that last part lol
The former construction doesn't work -- it wants a string, but it works with a string. I didn't realize we had the kwargs constructor here.
| class DimensionType: | ||
| Space: ClassVar[DimensionType] | ||
| Channel: ClassVar[DimensionType] | ||
| Time: ClassVar[DimensionType] | ||
| Other: ClassVar[DimensionType] |
There was a problem hiding this comment.
Do we have documentation that might guide users on which one to pick?
In my head, these affect ome-zarr metadata and (in the future maybe) impact what we do with on-the-fly lod's. e.g. We might downsample in space and time but not channel.
There was a problem hiding this comment.
All we have is this in the acquire-driver-zarr readme:
The first two dimensions should represent the width and height of the frame, respectively. The array_size_px for these dimensions should match the width and height of the frame, and the kind field should be DimensionType_Space. The rest of the dimensions should match the order of acquisition.
We might downsample in space and time but not channel.
Yeah exactly. I can add docstrings in acquire.pyi
2 participants
Depends on acquire-project/acquire-common#32 and acquire-project/acquire-driver-zarr#225.