Add image IO loading code from cellfinder & create image IO submodule within IO

[adamltyson]

This PR does a few things:

• Moves data loading code from cellfinder to this package (see Move data loading code to brainglobe_utils.image_io.load cellfinder#405)
• Moves the image_io code into a submodule within IO (closes Move image_io into IO? #69)
• Updates some of existing image IO tests

Once merged, this should be released as 0.5.0 (to match the pinning in other packages)

Related PRs:

• Add image IO loading code from cellfinder & create image IO submodule within IO #73
• Update brainglobe-utils image IO docs brainglobe.github.io#184
• Update use of brainglobe-utils image IO brainglobe-segmentation#176
• Update use of brainio to brainglobe-utils brainglobe-atlasapi#288
• Update use of brainglobe_utils image IO submodule brainreg#199
• Update from imio to brainglobe_utils.IO.image brainrender#346

[codecov]

Codecov Report

Attention: Patch coverage is 72.09302% with 12 lines in your changes are missing coverage. Please review.

Project coverage is 89.76%. Comparing base (66e88a4) to head (a1a53b5).

Files	Patch %	Lines
brainglobe_utils/IO/image/load.py	67.56%	12 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #73      +/-   ##
==========================================
- Coverage   90.38%   89.76%   -0.62%     
==========================================
  Files          35       35              
  Lines        1393     1427      +34     
==========================================
+ Hits         1259     1281      +22     
- Misses        134      146      +12     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[alessandrofelder]

Thanks for this @adamltyson !

It largely looks good to me, but I noticed a potential problem around being too strict with tiff axis metadata (similar to one we had previously). I suggest applying the same approach as before (I can do it and add to this PR if you like... let me know.)

[alessandrofelder]

This is probably too strict? We missed this on initial review, but caught this on a later review of related functionality. I expect we want to be more permissive here based on previous discussions around how clean we expect TIFF metadata to be. At the very least, we should be consistent between read_z_stack and get_size_image_from_file_paths functions?

I suggest doing the equivalent of ed40e38 (#67) for read_z_stack.

[adamltyson]

The code added here is just copied and pasted from cellfinder, so should these changes go into a different PR? Or did I miss something?

[alessandrofelder]

You didn't miss anything.
Sure, maybe it's better to put it in a different PR.
We should get that PR merged before releasing though, otherwise users that don't have xyz (in any order) in their tiff metadata will experience a change in behaviour.