cannot find reliable displacements for low-resolution data

[zahramansoor]

Hello,

I am interested in using your software to stitch a low-resolution volumetric image (5.91 um/voxel) acquired using a light-sheet microscope. I have used your software successfully with higher resolution light-sheet images.

However, I am not able to get adequate alignment and stitching on my low-resolutions images using the same parameters I am using for my previous high-resolution dataset. As an example, this is the image output I get after a "stitch test" in the GUI.

After alignment, when I go to the thresholding step, I basically get no reliable displacements in this dataset:

Continuing with the default settings and merging the planes, I get:

What parameters can I tweak to improve this alignment. Or am I making a mistake during the import/setup step?

Any help would be appreciated!

P.S. Attaching my xml import file as well. xml_import.txt

[iannellog]

From what I see, you have given to TeraStitcher wrong information about overlap between tiles. I understand that you have a dataset with two tiles along V (vertical) dimension. If you look at the import panel, you find that overlap along V is 0 (overlap along H is 768 because you have just one column of tiles and the tile size is likely 768x768). If overlap is 0, TeraStitcher cannot align the tiles.

The problem is in the import step. If you are relying on the standard import procedure (dataset organized in a two-level hierarchy of folders) pay attention to the folder names, remembering that they code the physical position of tiles in tens of microns. Since your voxel size is changed, folder names have to be coded accordingly. There is a similar problem if you externally generate a first xml import file.

You must consider the relations that there exist among:

• mechanical displacement induced by the instrument (measured in microns)
• voxel size (in microns)
• displacement between tile used by TeraStitcher (measured in pixels)
• overlap between tiles (in pixels)
• tile size (in pixels)

displacement_between_tiles = mechanical_displacement / voxel_size overlap = tile_size - displacement_between_tiles

[zahramansoor]

Hello,

Thank you for your response!

I wanted to clarify one thing: where can you tell the overlap along V is 0? In my import panel I have attached, my overlap (in voxels) is 0 in X (which I assume is H [horizontal] in the convention you are using?) because my image is a 1x2 tiled image in X and Y. Since my tiles are only in the Y orientation, I would assume my overlap in X should be 0?

Your answer regarding the folder hierarchy was helpful. I realize I was calculating this overlap slightly incorrectly. However even with that correction I am not able to get reliable displacements in which the reliability is > 0.5 (attaching my xml compute file below): xml_displcomp.txt

This is what my merged file looks after my overlap correction:

If you zoom in you can see the mismatch in Y:

This now has a much smaller error than my previous image, but if there is a more robust algorithm to correct this please let me know!

[iannellog]

In our convention H is horizontal (what most people call 'X') and V is vertical (what most people call 'Y'. Since your matrix is 1x2, overlap along X does not matter, and the software should set it conventionally to an arbitrary number (usually the tile size).

The question is: this is the size of your tiles in X-Y?

From your xml I can argue that it is something like 1568 (2048 would imply a very large overlap). If this is true there are several potential problems: 1) the overlap is too small to compute a reliable cross correlation; this is unlikely because your voxel size is large and an overlap of 120 pixel correspond to more than 600 um 2) you need a larger search region than the default one (25 pixels, the attribute 'delay' in the xml); try a search region of 50 (options --sV and --sH) 3) tiles are not correctly aligned along Z; this is difficult to correct because you have only 10 slices, but a disalignment along Z generates also the impossibility to perfectly align along X-Y.

Best.

-- Giulio

[zahramansoor]

Hi Giulio,

Thanks for your reply! Your estimate about the overlap is correct. If so, then I should try option #2 based on your suggestions.

Your point in #3 is also possible - unfortunately it is likely a limitation of our hardware and the way we secure our sample. We assume these misalignments are small, and I haven't seen an obvious example indicating otherwise, but I can look at the data more closely to see if that is the case.

Thanks again for your input! This was extremely useful!

Zahra.

[zahramansoor]

Increasing the search region size worked! I tested it in multiple volumes, and it now seems to work pretty well with our datasets. Thanks again for your help!