Strange Misalignments when Stitching

Dear ImageJ Forum,

I am trying to modify the Stitching plugin to stitch a regular grid of tiles, taking into account the pecularities of our microscope, but I regularly get tile misalignments that I really can’t explain.

To ensure this wasn’t due to the fact that I fiddled with the internals of the stitcher, I took two tiles that would end up misaligned, saved the (roughly) overlapping regions as individual tiffs and aligned them using the normal “pairwise stitching” plugin. The options used were “Compute Overlap” and I set “Check Peaks” to a value of 10.

Below are the links to the original 16bit tiffs (preview is not working on them, sorry) and the results from Matlab’s phase correlation alignment module (imregcorr) compared to ImageJ’s stitching result (click on the preview to see the full image). I would appreciate if anyone could shed some light on what’s happening there.


Matlab ->

ImageJ ->

The two images you included don’t have much in common. I am not sure how to align them even manually. Are the two image (img1 and img2) overlapping horizontally as img1 <-> img2?

If the images have very little content in common, the phase-correlation-image-alignment method used in the GridCollection stitching plugin will not work.

Some more details on how you are expecting those two images to overlap and align would be helpful.

On a related note, if you are trying to stitch a regular grid of image tiles I might be able to save you some work.

My definition for a regular grid of image tiles is a roughly constant image overlap per direction (e.g., horizontal overlap = 10% ± 2%, vertical overlap = 12% ±3%).

Additionally, if you are working with a stepper motor driven automated microscope stage there are the mechanical uncertainties of the system.

We have developed an image stitching tool (and Fiji plugin) for just this stitching paradigm.

Take a look and see if the stage model we use fits your use case.

The most powerful aspect of MIST is the ability to specify the known overlap (e.g., 10%), the overlap uncertainty (3%), and the stage mechanical repeatability (e.g., 10 pixels). The tool will then constrain the possible stitching to fit within that stage model, optimizing the translations between images to maximize correlation.


Hi Michael,
thanks for the heads up, the only issue for using it out-of-the-box is that we need 3D tiled stitching (serial two-photon tomograph, each tile is a 10 image z-stack). I’m actually using the maximum projections of the tiles to calculate the shifts in x/y within a section and the first/last image of each tile to calculate the x/y shift between different different tiles along the z axis.
However, your codebase might indeed be a very good starting point to add that functionality. I will have a closer look at it.


If you do end up digging into the code-base feel free to message me if you need anything.

The code base is more complicated than it otherwise would need to be in order to handle the CUDA and FFTW libraries we use to speed up the compute. The base Java stitching implementation uses the same FFT library as the GridCollection stitching. I would start looking through the code base at the JavaStitchingExecutor or the general StitchingExecutor at line 318 which orchestrates a stitching run.

Will do, thank you.
As an answer to your initial first question about the overlap, the matlab example (first red/green image in my post) shows the correct alignment between the images.