Try out m2stitch for general mosaic tile stitching

[evamaxfield]

Use Case

Please provide a use case to help us understand your request in context

We have a whole host of open issues about mosaics not being correct so going to use this single issue as a higher level "what can we do to solve a bunch of them."

Solution

Please describe your ideal solution

From napari conversation, m2stitch looks like a pretty good option. I got it almost working in ~30 minutes:

The compute time is much longer than ours because it is actually doing boundary checking / overlap, and which tile should overlap which other tile, and so on, where as in a lot of cases we are simply just shoving tiles one next to each other.

If we can offload tile stitching to a library that would be better imo, even if slower because that single libary may get faster with time.

Notes

While working on this, I realized that I think a part of the problem with our current workflow is that AICSImage defaults to stitching the mosaic image. I think in the future (in the v5 update??) it may be good to have AICSImage separate out the functionality from "default behavior" as to not confuse users as to "why is it taking so long to load this image".

An example of this may be:

img = AICSImage("my-big-tiled-image.lif")
img.dims  # <Dimensions M: 400, T: 1, C: 1, Z: 60, Y: 456, X: 456>
stitched = img.stitch_mosaic()  # with some optional "dims" parameter??
# Right after the `stitch_mosaic` function is called,
# we log a message that says "this process may take a while"
# and just like how the `m2stitch` library is currently doing, we show a progress bar.
# That should _hopefully_ help avoid user confusion?

[psobolewskiPhD]

Checking out m2stitch and https://github.com/labsyspharm/ashlar have long been on my to-do list.
Thinking aloud, I think there is room for quick-n-dirty put tile together preview of mosaics—as long as it is correct & responsive—and proper stitching. Love the idea of a warning and progress bar.
Then in the napari plugin it could be added to the check box menu so the user could see the mosaic and then stitch it. All of course with preserving access to the tiles in case of wanting to process them as a stack.

BTW, has stitching always been the default? I know I was adding FALSE programmatically, but I don't remember that behavior in napari-aicsimageio. In the case of LIF where the stitching isn't correct it's annoying, especially with no undo, so to speak.

[evamaxfield]

BTW, has stitching always been the default? I know I was adding FALSE programmatically, but I don't remember that behavior in napari-aicsimageio. In the case of LIF where the stitching isn't correct it's annoying, especially with no undo, so to speak.

Nope, napari-aicsimageio defaults to using the underlying reader data https://github.com/AllenCellModeling/napari-aicsimageio/blob/main/napari_aicsimageio/core.py#L52

The Reader has mosaic_data, mosaic_dask_data, etc. properties though which is what the larger AICSImage object uses if a mosaic tile is detected: https://github.com/AllenCellModeling/aicsimageio/blob/main/aicsimageio/aics_image.py#L404

---

Thinking aloud, I think there is room for quick-n-dirty put tile together preview of mosaics—as long as it is correct & responsive—and proper stitching.

Agree. I think there is room for a parameter that informs how to stitch and we can use it to switch between algs.

---

Then in the napari plugin it could be added to the check box menu so the user could see the mosaic and then stitch it. All of course with preserving access to the tiles in case of wanting to process them as a stack.

You could do this today if you wanted to now that we are storing the AICSImage object in the layer metadata. Granted, it will be the inaccurate stitch. But I really like that idea too.

[psobolewskiPhD]

You could do this today if you wanted to now that we are storing the AICSImage object in the layer metadata. Granted, it will be the inaccurate stitch. But I really like that idea too.

..but this would still be programatic via the console, right?
I think a GUI checkbox for the plugin (or a preference or something) would be better for a non-programatic python user.

FYI, while playing with this I can confirm the LIF mosaics are still not correct—for my samples—see: #278
I think this is fixable without m2stitch/etc. for the quick/crude stitch.

For the plugin, some more ideas maybe from here:
https://napari.zulipchat.com/#narrow/stream/212875-general/topic/reading.20coordinates/near/260354402
@tlambert03 said:

for a quick and dirty visualization (no actual stitching like GCStitching) you can simply set layer.translate appropriately on each sub-image to shift it where it belongs in the canvas. we do this in napari-micromanager when collecting tiled acquisition.

More from @VolkerH using dask:
https://napari.zulipchat.com/#narrow/stream/212875-general/topic/reading.20coordinates/near/260379087

[evamaxfield]

I think a GUI checkbox for the plugin (or a preference or something) would be better for a non-programatic python user.

Gotcha.

I don't really have time to dive deep into this right now. So anyone looking at this thread and wanting to take a stab at it, feel free.

[jo-mueller]

Thinking aloud, I think there is room for quick-n-dirty put tile together preview of mosaics—as long as it is correct & responsive—and proper stitching. Love the idea of a warning and progress bar.

This would be super helpful. Many of the image data I work with have actually been stitched at the microscope on acquisition so the quick'n'dirty approach would be exactly what I need.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.