Stitching

These are developer notes on the process of stitching data

stitchSection first prepares for stitching by doing the following:

• Read in the meta-data (mosaic file) (readMetaData2Stitchit) and the StitchIt INI file (readStitchItINI).
• Determine the names of the directories which contain the raw data (directoryBaseName).
• Create empty directories into which the assembled sections will be stored.

It then enters a parallel for loop (parfor) and assembles sections in parallel. This can be an abitrary number of threads, but in practice it works at a round the number of cores (or virtual cores) supported by the machine. However, depending on the RAID array, we may hit an IO bottleneck before reaching the full number of cores. The parfor loop does the following:

• Loads tiles and the positions (row/column) of those tiles in the grid (tileLoad).
• Uses the information extracted so far to either calculate the naive tile positions (gridPos2Pixel) or the position of each tile based upon the stage (stagePos2PixelPos).
• The workhorse function, stitcher, now assembles the images using the tile positions and tile data. Optional alpha-blending or chessboard stitching are conducted by stitcher. Note that stitcher places tiles in the reverse order to that in which they were acquired. This ensures that only non-photobleached pixels are visible when no alpha-blending is conducted.
• The images (including optional down-sampled images) are now saved. Also saved is a CSV file with the tile positions. Once all images have been built, the loop ends. The function then confirms that all stitched images are the same size. It issues a warning if not but doesn’t attempt to correct the mistake. Finally, stitchSection writes a file to the stitched sections directory to log what parameters were used to assemble the data.