search

SWC-Advanced-Microscopy / StitchIt

Stitching of large tiled datasets
GNU Lesser General Public License v3.0
17 stars 7 forks source link

Revisit the way we subtract the background tiles at some point #14

Closed raacampbell closed 7 years ago

raacampbell commented 7 years ago

The BakingTray tile loader currently uses the background tiles found by ./preProcessTiles/private/writeTileStats.m to subtract this from the average tile. The process is somewhat ad-hoc and was motivated by the offset added to the amp. We stopped doing this now and so empty tiles should be near zero. I think, therefore, that we should modift this code in the light of this. See also: #46

raacampbell commented 7 years ago

Thinking of addressing this with a background subtracter class that contains the images and the methods to apply the correction. Then can have different classes for different correction types. e.g. for average tiles and for cidre.

raacampbell commented 7 years ago

Related to this is the now orphan lowValueThreshold parameter in the INI file. If we indeed calculate this value adaptively, then lowValueThreshold (which is currently doing nothing) should definitely be removed.

raacampbell commented 7 years ago

I think this has been done?

raacampbell commented 7 years ago

Try mixture of Gaussians approach for getting the offset (was #61)

raacampbell commented 7 years ago

Upgraded because of BakingTray Issue 57 which caused channel 2 of MoA_20 to stitch badly.

raacampbell commented 7 years ago

We now (c553da5209a3b6c770af25353dcfd804f009c42c) calculate the offset based on a Gaussian mixture model applied to the dimmest tiles. This allows for the use of a biased amplifier and also corrects for acquisitions where the auto bias adjustment in ScanImage is causing problems. However, there is no ability currently to enable/disable the application of the offset when tiles are loaded. It is currently done by editing a flag in bakingtray.tileLoad. We need maybe an INI setting to deal with this if it becomes a feature we really need to use.

ablot commented 7 years ago

I think that most of this issue has been fixed on the dev branch.

Related: I'd like to add an option to fix the offset in preProcessTile (for instance calculate it on the first optical plane and then keep it constant). I think it would solve most of the issue if the offset is constant during the recording. Do you have any objection/advice?

raacampbell commented 7 years ago

Sure, let's do that and see how we go. It ought to work.