BiaPyX/BiaPy

Input zarr axes order in config file while loading Zarr/H5

Closed this issue · 3 comments

ClementCaporal commented

Hello!

Thank you for your work

Pitch

I would like to load in BiaPy any zarr format without having to respect the current specific order (z, y, x, c).
I think for example that many zarr will respect the ome-zarr convention (t, z, c, y, x)

It could be a variable in the config file

danifranco commented

Hi!

Just added TEST.BY_CHUNKS.INPUT_IMG_AXES_ORDER variable in this commit so you can control it as suggested. Now four different types of axis orders are supported ['TZCYX', 'TZYXC', 'ZCYX', 'ZYXC']. The default behaviour is to expect 'TZCYX' order as ome-zarr.

Hope you find it useful. Let me know if you find any issue! :D

  • 🎉2
ClementCaporal commented

Hello @danifranco.
Thank you very much for your work.

I have several small questions:

  • Is there a reason to support only these axis order? (['TZCYX', 'TZYXC', 'ZCYX', 'ZYXC']). If not I propose this pull request for a versatile TEST.BY_CHUNKS.INPUT_IMG_AXES_ORDER : #45 . The main idea is to sort the axis on the fly using a new util.order_dimensions() function.
  • This lines suggest that T is always first? Is there a specific utility to add it to the data_shape ?
  • 🚀1
danifranco commented

Hello!

  • There was not specific motivation to only support 4 axis order. The function and rest of the changes added in your PR are awesome. Thanks a lot!
  • I decided to make the T always first and include it even if the user didn't select it just to have a consistent output, nothing more behind... I'm open to any suggestions. In insert_patch_into_dataset() the part that each GPU processes is created. Then, the main process is in charge of merging those pieces into the final large Zarr here or here. So, maybe we can apply the same procedure to have an output as the user's input axis order. I'm not very used to work with Zarr files but it could be interesting, no? What you do think? If so, do you want to make the changes? So everything could support versatile axis order.

Another thing, could you please only commit the changes in those lines that you really change something? I mean, now there are a lot of additions/removals because of blank spaces and it's hard to see sometimes what's new was added.

Again, thanks a lot for the changes Clement!!