Post-processing
Once stitched, the data are ready for further analysis such as identification of labeled cells, tracing fibre tracts, or identifying compartments 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 can never be perfect. This is because different regions of an organ have different densities and so scatter light to different degrees. No single laser power correction will work over a whole organ. For example, in brain tissue a reasonable correction for the white matter will be insufficient for the grey matter.
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.
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. The raw data are always left untouched on the disk. A directory called
rawData/stitchitPreProcessingFiles contains the average tile illumination data from each section as well as various other statistics. Grand average tile averages are stored in rawData/averageDir and generated by collateAverageImages. For example the file rawData/averageDir/2/01_bruteAverageTrimmean.mat contains correct data for channel 2 optical plane 1. You can load this structure and look at it in MATLAB:>> load averageDir/2/01_bruteAverageTrimmean.mat
>> who
Your variables are:
avData
>> avData
avData =
struct with fields:
evenRows: [562x562 single]
oddRows: [562x562 single]
pooledRows: [562x562 single]
evenN: 5808
oddN: 6529
poolN: 12337
correctionType: 'bruteAverageTrimmean'
channel: 2
layer: 1
details: [1x1 struct]
StitchIt divides the raw data tiles by the image stacks in
evenRows, oddRows, or pooledRows to remove the illumination artifacts. Which it uses is defined by the illumCorType: split causes a different correction to be used for the odd and even rows. pool causes a single correction to be used for all tile rows. pool should suffice in most cases. If you notice odd issues with the illumination correction, first try setting doIlluminationCorrection to 0 and restitch (or use peekSection) to see what your data look like. You can also imagesc avData.pooledRows to see what the average tile looks like. If there is some problem with the average tile, this will manifest in the stitched image. You could try using grand averages from a different experiment or from a different channel if weird stuff is happening.Even with perfect tile placement, there might be substantial artifacts at tile edges and within single tiles if no corrections are applied. The degree to which this happens depends on factors such as field of view size and microscope alignment. Even following illumination correction, tile edges remain apparent:
Cleaning up the tile edges is possible in various ways. One option is graded blending (or "feathering") of the overlapping tile borders to create a smoother join.
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 image processing. 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 external binaries from MATLAB with the
applyGIST2section and applyGIST2section_BATCH commands. The results are usually very effective:
If it looks so great, why isn't the gradient-domain approach integrated into the main pipeline? There are a few reasons:
- The algorithm is relatively time consuming.
- Compiling the binaries can sometimes be a pain.
- The implementation of the algorithm sometimes hangs and needs to be restarted.
- Most importantly: the GIST algorithm adds subtle features to the images that weren't there before. There can be odd flare effects, etc, if something bright is found at a tile border.
For these reasons, we employ the GIST seam removal for producing images for talks or publication but we don't analyse using GIST-processsed data. For more information see Setting up seamless stitching.