Grid/Stitching collection plugin- unsure about .registered text file

Hi,

I’m using Grid/Collection as part of a Jython script to stitch whole wells of multichannel images, some of which are easy to stitch (DAPI) and some of which don’t stitch well on their own (eg, small foci images). I had therefore taken the strategy of aligning the DAPI images via “normal” Grid stitching, then using the TileConfiguration.registered.txt file, changing the names in it (editing _DAPI.tif to _FITC.tif or _Cy3.tif in each line of the file names), and applying that alignment to all of the other channels using the “Positions from file” option.

This was all well and good, but on a recent batch of images I realized that while all my non-DAPI channels were always aligned perfectly, the DAPI channel itself (which I’d used to create the .registered file) was not always actually aligning to the other channels correctly, typically in the top-left corner of the image. Sometimes whole tiles were gone, other times they were off by 15-20 pixels. Sometimes it looked perfect!

Ultimately, I can work around this by then re-performing the DAPI stitching based on the .registered file, which worked well to “fix” all the stitches that worked poorly in my hands, but I’m worried it signals an underlying issue. Shouldn’t the positions in the .registered file match the stitch that is made in the same step?

Please let me know if you need follow up info/example images, or if I was unclear in any way.

1 Like

Hi @bcimini,

That’s really weird.

First, a tangential idea - I’m confident I’ve run the Grid/Stitching plugin with multi-channel images.
Meaning, it may be worth combining your channels, and running the plugin on those. (Hopefully the non-DAPI channels don’t hurt the stitching quality.) If that works, it would save you the extra step of editing the .registered. file, and ideally, sidestep this weird behavior too.

Anyway…

So here, am I right that you mean that it behaves correctly for some datasets but incorrectly for others?

John

1 Like

I agree. Stitching multi-channel images directly should work equally well, if not better, than only relying on a single channel. As far as I can tell, the mean of all channels is considered for registering overlapping tiles in this case.

This reminds me of this issue:

I observed that tiles that cannot be linked will be discarded in the stitching result, but they still end up being listed in the TileConfiguration.registered.txt.
@bcimini did you have a look at the coordinates in your .registered.txt files? Do they make sense?

It is indeed really weird! It had worked perfectly on a few image sets, then all of a sudden I noticed a few where it DIDN’T, so then I was in a panic re-stitiching everything to meet a deadline.

First, a tangential idea - I’m confident I’ve run the Grid/Stitching plugin with multi-channel images.
Meaning, it may be worth combining your channels, and running the plugin on those. (Hopefully the non-DAPI channels don’t hurt the stitching quality.)

On my data, trying to include all channels did actually affect the stitching quality, at least some of the time, which is I went to the single-channel-based approach.

I observed that tiles that cannot be linked will be discarded in the stitching result, but they still end up being listed in the TileConfiguration.registered.txt .

I’m less worried about the cases where tiles are missing (see first screenshot- green is the nuclei as output by the first run of Grid/Collection stitching, red is the stitch I got by stitching from the TileConfiguration, teal is phalloidin), than the one or two cases where it seems to be offset by 10 or 20 pixels (see second screenshot)- missing nuclei on the edge I can happily ignore, but the offset was scary to me and why I wanted to flag your attention.

image

2 Likes