Post processing
Once stitched, the data are ready for further analysis such as identification of labeled cells, tracing fibre tracts, or identifying compart ments within the volume. You may, however, still want to correct for illumination changes with depth or remove seams at tile edges. Whilst these operations usually producer nicer-looking images they may well have no effect on your ability to extract useful data from the images. As such, these steps are optional and in-house we rarely conduct them.
Although we can increase laser power with depth when taking multiple optical sections per physical section, the compensation is never perfect.
Furthermore, since different regions of an organ can scatter light to different degrees and have different densities, no single laser power correction will work over a whole organ.
Thus, we can do a local correction for changing illumination with depth.
This works well but fails in areas where there is a very large drop in intensity or when the imaging plane is far below the surface.
The correction is implemented with correctZilluminationInDirectory, which has the option of either replacing the original stitched data or placing the corrected sections in a new directory, allowing for comparison with the originals.
Avoid retaining multiple versions of the same stitched stack with slightly different corrections in place.
This is a recipe for creating terabytes of redundant data.
Re-stitching is cheap, so maintain only the data you need.
Bellow show the before and after effects of z-illumination correct.
Even with perfect tile placement, there will be huge artifacts at tile edges and within single tiles if no corrections are applied. By default we correct for uneven illumination by dividing out the average tile. This is done on optical section, channel, and tile row specific basis, since the average images look different if divided up in this way. If average images have been calculated then illumination correction is performed automatically during tile loading. Even following illumination correction, tile edges remain apparent. Cleaning up the tile edges is possible in various ways.
One option is graded blending of the overlapping tile borders to create a smoother join.
In the literature this is commonly known as ‘feathering.’
Whilst this option is easy to do, we have not found it produces great results.
One reason for this is that tiles are never perfectly aligned and so averaging the overlapping areas produces
blurring.
The second option is a substantially more elaborate family of approaches known
as gradient-domain stitching.
These techniques seek to minimise intensity changes across tile borders by making more global changes to intensi
ty gradients across the image.
As a by-product this often also corrects for exposure differences between adjacent tiles.
StitchIt uses a published implementation by calling the compiled binaries from MATLAB with the
applyGIST2section and applyGIST2section_BATCH commands.
The results are usually very effective but the algorithm is relatively time consuming.
The GIST algorithm will need to be run on a machine with many cores if it is to complete in a reasonable time. Although the algorithm is multi-threaded, it doesn’t seem to speed up a great deal as more threads are added.
On an 8 core i7, the best way to get speed is run each image on perhaps 2 to 4 cores and run about 12 images
simultaneously.
You will end up running about 100 threads this way, which seems crazy but it works.
Unfortunately, the implementation of the algorithm does have a tendency to hang from time to time.
applyGIST2section_BATCH attempts to catch these occurrences, kill processes associated with a stalled section and restart them. As of this writing, this approach works well but isn’t perfect.
Please check, therefore, whether all sections have been produced before conducting further analyses.
You can re-run applyGIST2section_BATCH with the overwrite flag disabled in order to generate any images that were missed the first time.