Pad images with 0 on right and bottom, if images differ in dimensions

[MSHelm]

Fixes #366

The macsima reader now first checks all image dimensions in X/Y. If there are mismatches, a warning is thrown, and the images are padded to the bottom/right with 0s.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 96.42857% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 62.31%. Comparing base (3101b5b) to head (45f6096).

Files with missing lines	Patch %	Lines
src/spatialdata_io/readers/macsima.py	96.42%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #371      +/-   ##
==========================================
+ Coverage   61.85%   62.31%   +0.45%     
==========================================
  Files          26       26              
  Lines        3138     3163      +25     
==========================================
+ Hits         1941     1971      +30     
+ Misses       1197     1192       -5     

Files with missing lines	Coverage Δ
src/spatialdata_io/readers/macsima.py	95.36% <96.42%> (+1.69%)	⬆️

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[MSHelm]

@LucaMarconato did you find time to have a look at this PR yet? I think it would be really helpful to bring spatialdata-io on par with harpy.

[LucaMarconato]

Hi @MSHelm, thanks for the PR, it looks good. I only made some minor code-style changes and expanded a bit on comments and docstrings.

One extra thing that I noticed: harpy applies padding also on the top and left of the images https://github.com/saeyslab/harpy/blob/7907a0bf4515ccf19ca2659049213b865b245507/src/harpy/io/_macsima.py#L358, using information (translation_x and translation_y metadata) found with the _get_translation() function https://github.com/saeyslab/harpy/blob/7907a0bf4515ccf19ca2659049213b865b245507/src/harpy/io/_macsima.py#L472, and defaulting to 0, 0 when not found. In that latter case, the behaviors of harpy and spatialdata-io coincide.

Could you comment on this please? Do you think that padding on the top left should be supported for some datasets?

[MSHelm]

Hi @LucaMarconato , thank you for the review!

The problem with the PR was, that internally I didnt find data sets that had this issue, so I had to rely solely on the single data set provided by @nbonine, which didnt have values aside from 0 in the planes attribute.
I asked internally how we do the stitching, which is snake wise from top left, to bottom left, one right, up again etc. So honestly I simply assumed that if a shift happens it would always go into the bottom/right direction.
I could have copy pasted the code from harpy but since I didnt have the means to verify it, I didnt do that. I also didnt find test data in their repo that actually tests the functionality.

So long story short, for me that was the simplest, most intuitive solution, lacking a larger suite of test images to implement and verify a more sophisticated approach :)

[ArneDefauw]

Hi @MSHelm , I also had a look at your PR.

Internally, we had several datasets that stored a non-zero offset in the ome tiff metadata after preprocessing with MACSiQView software. In harpy we fetch it via this helper function https://github.com/saeyslab/harpy/blob/main/src/harpy/io/_macsima.py#L472. And then we do the following:

pad_y_prepend = _translation[0] means: add that many blank rows before the image along the Y axis, i.e. above it. This effectively shifts the image downward on the shared canvas.

pad_y_append = max_y - _size[0] means: add enough blank rows after the image along the Y axis, i.e. below it, so that this image reaches the same final height as all the others.

And

translations = _get_translations(imgs)
sizes = np.array([_arr.shape[-2:] for _arr in arrays])
sizes_trans = sizes + translations
max_y, max_x = np.max(sizes_trans, axis=0)

So each image has an original height/width, plus a metadata-derived y, x offset. The code creates a common canvas large enough for all translated images.

Note that _get_translations() substracts the minimum y/x positions, so the topmost/leftmost image starts at offset 0 (even if it would have translation y,x=(100,100). But that would be an edge case. The leftmost/topmost image always has offset 0, 0 in the metadata ).

Unfortunately, I currently do not have a dataset available with this issue that I can publicly share. But I think it should be possible to create an artificial ome tiff with a non zero offset, in order to test this code branch.

On a side note, I think there is a small typo here:

https://github.com/MSHelm/spatialdata-io/blob/45f6096118114b93ff2789289f4b37355cd6c021/src/spatialdata_io/readers/macsima.py#L264

you probably mean:

if (pad_y, pad_x) != (0, 0)