lr_fuse for stitched data with each path in a separate file

[neuromantic99]

Description

What is this PR

• Bug fix
• Addition of a new feature
• Other

Why is this PR needed?

Currently lr_fuse expects a single ImageMosaic and does not save the result. When the left and right paths have multiple tiles in each (that have been stitched post-hoc), the left and right data should be in separate .h5 files.

What does this PR do?

Changes the functionality in lr_fuse to work with two .h5 files (one for each illumination side). Moves existing functionality (whereby both illumination sides are in a single file) to ImageMosaic.

Checklist:

• The code has been tested locally
• Tests have been added to cover all new functionality (unit & integration)
• The documentation has been updated to reflect any changes
• The code has been formatted with pre-commit

[IgorTatarnikov]

Curious that saving outside of the function fails. I wonder if it has something to with .h5 files being closed when one of the ImageMosaic objects is garbage collected thus closing the .h5 file.

[IgorTatarnikov]

This looks great and would be a welcome addition!

We'll have to make sure we support two workflows simultaneously. Some users will have an untiled acquisition form multiple illuminations in one h5 file, whereas others will have the two illuminations in separate files. We could either get clever with the function arguments, or create two separate functions entirely.

Alternatively, perhaps there should a fuse illumintations function inside the ImageMosaic class that combines illuminations in one file, and a separate l_r_fuse function that takes mulitple ImageMosaics

[neuromantic99]

This looks great and would be a welcome addition!

We'll have to make sure we support two workflows simultaneously. Some users will have an untiled acquisition form multiple illuminations in one h5 file, whereas others will have the two illuminations in separate files. We could either get clever with the function arguments, or create two separate functions entirely.

Alternatively, perhaps there should a fuse illumintations function inside the ImageMosaic class that combines illuminations in one file, and a separate l_r_fuse function that takes mulitple ImageMosaics

Hi Igor,

That's great, happy to work on it.

The fuse_illuminations approach was what I tried originally. However I ran into the same issue as indicated in the comment that saving the fused image outside of the function fails. In both cases dask.compute() (which errors in register_shutters in the fuse_immunations approach) fails with OSError: Can't synchronously read data (identifier is not of specified type). Do you have any thoughts on this? I confirmed that the actual datatype is as expected so I think it's something weird happening with the h5 file being closed or something else being GCd like you say.

Interestingly this error does not throw when I run the code in my vscode debugger, which I believe is forced single threaded - though this is hideously slow so not a viable solution I think

[IgorTatarnikov]

The error not being thrown during debugging make a bit of sense, the debugger is keeping a reference to the object open preventing it from being GCd.

I would suggest moving the current implementation to a method in brainglobe_stitch.image_mosaic.ImageMosaic. This method would keep the assumptions of the current implementation, which are: there are two illuminations, they occur along the last axis (x), and the file contains two arrays per channel corresponding to the illuminations.

The new implementation can stay in lr_fuse.py and maybe take paths as arguments and instantiate the ImageMosaics in the scope of the function. The function would take two paths, one for each channel, other parameters relating to the lr_fuse operation, and an output path where the fused image will be saved.

[neuromantic99]

The error not being thrown during debugging make a bit of sense, the debugger is keeping a reference to the object open preventing it from being GCd.

I would suggest moving the current implementation to a method in brainglobe_stitch.image_mosaic.ImageMosaic. This method would keep the assumptions of the current implementation, which are: there are two illuminations, they occur along the last axis (x), and the file contains two arrays per channel corresponding to the illuminations.

The new implementation can stay in lr_fuse.py and maybe take paths as arguments and instantiate the ImageMosaics in the scope of the function. The function would take two paths, one for each channel, other parameters relating to the lr_fuse operation, and an output path where the fused image will be saved.

Have implemented the above suggestions, haven't added unit or integration tests yet or updated the documentation, lmk if necessary.