Bug in linear drift correction
24 views
Skip to first unread message
Sven Proppert
Jun 27, 2015, 6:37:30 AM6/27/15
to rapidstor...@googlegroups.com
Hi friends,
please be aware that the linear drift correction is apparently corrupted... To cut it short, the linear drift correction works fine but gives wrong values. If for example you need to subtract a linear drift of 1 pm/fr to get a drift-free image, the real value subtracted is 3. In other words: If you did the drift correction manually with a data handling software like Origin, you would need to subtract a drift of 3 pm/fr in order to get the same result.
This should not bother you too much in most cases but becomes a problem when doing sequential two color dSTORM because in order to get colocalization of corresponding signals, you need to subtract the drift that occured in the first measurement thom the found localizations of the second color. If you would subtract the value estimated with the linear drift correction module (1 pm/fr * 10.000 frames), your data will be shifted because you should have subtracted 3 * 1 pm/fr * frame. When entering the correct value, the measurements will give the correct result.
For debugging purposes, I uploaded exemplary data (~15 MB) to my dropbox account which can be downloaded here: https://dl.dropboxusercontent.com/u/1078013/lindrift-usecase.zip
The data consists of a 100 nm Tetraspeck bead on a glass surface surrounded by water. The movement in y was induced by moving the stage manually with a more or less constant velocity. The asymmetric pixel sizes stem from the fact that this was a 3D measurement, but the data can without any problems be evaluated in 2D when the pixel sizes are set appropriately (85 nm in x and 110 nm in y for the red channel). You should increase the PSF FWHM value slightly (maybe to 500 nm) because the image is not sharp (astigmatic distortion).
I added some instructions for 2D and 3D evaluation as well as for readily transformed evaluation of the green signal. After drift correction, the red and the green localization cloud should mostly coincide with a small offset remaining, als the transformation data apparently was not perfect...
The bug showed up when I tried to do two-color 3D with a channel-alignment raw-transformation fed to rapidSTORM, but I also tried the most basic case (2D fitting, no two channel alignment) and the bug remains. So to make it clear: I have no reason to assume that the bug has anything to do with channel alignment or 3D but is a general issue.
A last remark: I do not know whether the factor is exactly 3. It might also be Pi or sqrt(10) or other "typical candidates" but it looks as if it was rather 2.9 - 3 than a higher value. A closer look to the source might give clarity...
If you have questions, please contact me by posting to this newsgroup.
Cheers,
Sven
please be aware that the linear drift correction is apparently corrupted... To cut it short, the linear drift correction works fine but gives wrong values. If for example you need to subtract a linear drift of 1 pm/fr to get a drift-free image, the real value subtracted is 3. In other words: If you did the drift correction manually with a data handling software like Origin, you would need to subtract a drift of 3 pm/fr in order to get the same result.
This should not bother you too much in most cases but becomes a problem when doing sequential two color dSTORM because in order to get colocalization of corresponding signals, you need to subtract the drift that occured in the first measurement thom the found localizations of the second color. If you would subtract the value estimated with the linear drift correction module (1 pm/fr * 10.000 frames), your data will be shifted because you should have subtracted 3 * 1 pm/fr * frame. When entering the correct value, the measurements will give the correct result.
For debugging purposes, I uploaded exemplary data (~15 MB) to my dropbox account which can be downloaded here: https://dl.dropboxusercontent.com/u/1078013/lindrift-usecase.zip
The data consists of a 100 nm Tetraspeck bead on a glass surface surrounded by water. The movement in y was induced by moving the stage manually with a more or less constant velocity. The asymmetric pixel sizes stem from the fact that this was a 3D measurement, but the data can without any problems be evaluated in 2D when the pixel sizes are set appropriately (85 nm in x and 110 nm in y for the red channel). You should increase the PSF FWHM value slightly (maybe to 500 nm) because the image is not sharp (astigmatic distortion).
I added some instructions for 2D and 3D evaluation as well as for readily transformed evaluation of the green signal. After drift correction, the red and the green localization cloud should mostly coincide with a small offset remaining, als the transformation data apparently was not perfect...
The bug showed up when I tried to do two-color 3D with a channel-alignment raw-transformation fed to rapidSTORM, but I also tried the most basic case (2D fitting, no two channel alignment) and the bug remains. So to make it clear: I have no reason to assume that the bug has anything to do with channel alignment or 3D but is a general issue.
A last remark: I do not know whether the factor is exactly 3. It might also be Pi or sqrt(10) or other "typical candidates" but it looks as if it was rather 2.9 - 3 than a higher value. A closer look to the source might give clarity...
If you have questions, please contact me by posting to this newsgroup.
Cheers,
Sven
Reply all
Reply to author
Forward
0 new messages