enable slicing stacks in arbitrary dimensions

[martinschorb]

Hi, this should enable extracting only sub-dimensional parts of stacks. (-> single channels of multi-channel stacks for MoBIE etc...)

I have not checked how it can be tested yet, but the actual slicing happens in cluster_tools, so it might be more interesting to test there...

constantinpape/cluster_tools#42

[martinschorb]

I hijacked the input_key because it is propagated everywhere. (plus there is no type check at least in mobie-python)

I have no preference whether it is passed as tuple, list or (maybe?) dict. Whatever yo prefer...

[martinschorb]

Oh wait. It might not even be necessary to propagate it all the way up to elf here.
Maybe the updated cluster_tools are sufficient. I just started my hack in here and then noticed that most stuff happens downstream only.

[martinschorb]

OK, it is necessary to change things here due to the type checks.

[martinschorb]

Hi @constantinpape ,
what do you think of the slicing? Do you approve the general idea? What about hijacking the key parameter? Would you alternatively prefer an additional parameter for the dimension reduction?

I thought about looking into the tests and found out that so far, IO functionality is tested both here as well as in cluster_tools (downscaling) . Do you think we also need the slicing tests implemented in both repos or would here (elf) be the correct place?

[constantinpape]

Hi @martinschorb ,
if I understand the goal of the PR correctly you want to enable copying just a sub-volume of a tif stack with cluster_tools. And to that end you want to enable slicing via the key argument of __getitem__ in ImageStackFile (so that it can be passed in cluster_tools). Let me know if I understand this correctly.

This approach has the downside that it duplicates the functionality already implemented by ImageStackDataset in getitem. And it potentially creates some confusion because it breaks the correspondence to h5py or zarr, where the File just selects the Dataset and the slicing is done on the dataset level.

I think there is a way how you can achieve this in cluster_tools already without any changes, I will follow up in constantinpape/cluster_tools#42.

[martinschorb]

This approach has the downside that it duplicates the functionality already implemented by ImageStackDataset in getitem. And it potentially creates some confusion because it breaks the correspondence to h5py or zarr, where the File just selects the Dataset and the slicing is done on the dataset level.

OK, great. I was not fully aware of the exact logic in ImageStackDataset and ImageStackFile.

So, do I get it right that the idea would be to present a single stack as ImageStackDataset and hand over the rois (=channel/slice/...) as key?

[constantinpape]

So, do I get it right that the idea would be to present a single stack as ImageStackDataset and hand over the rois (=channel/slice/...) as key?

Yes, exactly.

[martinschorb]

Would the best place to implement this then be the channel parameter of mobie.add_image to make it use ImageStackDataset with the relevant roi keys?
Do you want to revive your channel branch, or should we create a new one?

[constantinpape]

Would the best place to implement this then be the channel parameter of mobie.add_image to make it use ImageStackDataset with the relevant roi keys?

channel already has a different meaning in mobie.add_image. It is used to select a specific image for data stored in ome.zarr. This means it refers to the data that is written by add_image and not directly to the input data. And this is something rather specific for ome.zarr.

So you would need to add it with some other parameter name to avoid overloading the meaning of channel. Maybe selected_input_channel?

Do you want to revive your channel branch, or should we create a new one?

You can go ahead and create a new one. (The channel branch was used to implement the functionality for ome.zarr channels mentioned above.)