AllenNeuralDynamics / aind-smartspim-stitch

Stitching and fusion pipeline in the cloud
MIT License
3 stars 1 forks source link

Stitching artifacts #25

Closed galenlynch closed 7 months ago

galenlynch commented 1 year ago

The borders between tiles are clearly visible in stitched volumes as bands of lower intensity signal, e.g. in this volume. There is no reduction in signal intensity of the raw images, as can be seen e.g. here (you may need to view the raw image in imageJ or other software to correct for the exposure of that image), suggesting that these bands of reduced intensity are introduced by the stitching process itself. It would be nice to not have the stitching process introduce artifacts, if possible.

I am including screen shots for ease of viewing.

Here is the stitched output with visible stitching artifacts: stitched

Here is one of the raw tiles, with no change in signal intensity at the border: raw_image

galenlynch commented 1 year ago

Bump @camilolaiton

galenlynch commented 10 months ago

This might actually be due to bleaching.

A more recent example showing the artifact I'm talking about: Neuroglancer Link You can see a pronounced dip of intensity that runs across (ML) the striatum in all channels, here I am just looking at 640. Screen shot below: image

When you find the tiles anterior and posterior to this same boundary in the striatum, the anterior edge of the tiles also seem to have a dip of intensity, although the first example I posted seems worse.

Screen shot of the tiles placed near each other: image

The tiles are this one and this one, which are probably not exactly in the same DV plane as the Neuroglancer link, but the artifact spans the whole z stack so the plane selection doesn't matter that much.

The intensity along the anterior edge seems to dip in a manner that's consistent with the stitched volume: image

Anyways, maybe we should look at some more brains, but I'm starting to be convinced that it's not a blending problem.

camilolaiton commented 10 months ago

Hi @galenlynch, thanks for looking into this as well. We did not see any change by running another blending algorithm which supports your findings. I'll be happy to look into other datasets and it might also be worth to start looking into this tool which seems promising for illumination correction using flat fields: https://www.nature.com/articles/ncomms14836

adamkglaser commented 10 months ago

This looks like a standard shading artifact for SPIM (or any microscopy method). Just like with the ExA-SPIM there are two components.

(1) the light sheet intensity is Gaussian and should be dimmer at the edges. I know Jeff designed the smartSPIM with a cylindrical lens light sheet which will exhibit this. I'm not sure how over expanded he designed it, i.e. what is the Gaussian intensity at the left/right edges expected to be. It is ~50-60% on the ExA-SPIM.

(2) overlapping regions will be photobleached more because they are hit 2x. To check whether this is also a factor, one could look at the overlapping regions and try to estimate what % of a tile is 'darker' -> should match the overlap set in the scanning setup. On the ExA-SPIM this is a big factor and doing the exercise above gives a pixel width of dark banding which almost exactly matches the expected 15% overlap.

If the issue is just (1) then it would be possible to measure a flatfield calibration by imaging something that should be 100% uniformly fluorescent (just fill the chamber with water and some diluted dye). If (2) is a factor, it isn't as straightforward to measure an experimental correction factor. And it probably needs to be corrected retrospectively. This is the case for the ExA-SPIM data, and we are exploring this package called BASIC which is the go to in fluorescence microscopy for this type of issue. Cameron is looking into this now, probably makes sense to explore it for smartSPIM data too?

https://www.nature.com/articles/ncomms14836 https://pypi.org/project/BaSiCPy/

camilolaiton commented 7 months ago

This issue was resolved here.

Please, feel free to reopen it or create new issues on that repo related to flat-field correction problems. Thanks!