[quickpalm] Correct for stage drift

[Nico Stuurman]

Hi Ricardo,

Can you explain how the "Correct for particle drift" option works? I
did select an ROI in an image and run this option, but the result seem
to be introduction of more jitter and I do not know what the code is
doing.

Naively, I would think that the most efficient way to correct for
stage drift is to find spots that occur in two consecutive images and
use these to reconstruct movement of the image as a whole. Once you
have that, it is straight forward to subtract from each of the
individual particles.

Best,

Nico

[Ricardo Henriques]

Hi Nico,

Can you explain how the "Correct for particle drift" option works?  I did select an ROI in an image and run this option, but the result seem to be introduction of more jitter and I do not know what the code is doing.

I created a small example movie tutorial on http://code.google.com/p/quickpalm/wiki/Tutorial_Drift_correction.

Naively, I would think that the most efficient way to correct for stage drift is to find spots that occur in two consecutive images and use these to reconstruct movement of the image as a whole.  Once you have that, it is straight forward to subtract from each of the individual particles.

You are correct and that is partially what the algorithm is doing except there is a part that is not very straight forward. So, the idea is that the user selects for example beads on the reconstruction and adds them to the ROI manager, next the correction algorithm calculates the center of the cluster correspondent to each bead and calculates the joint displacement over time. Each bead has its own displacement in time that is partially random by nature and is due to the noise fluctuations that create some localization inaccuracy, it is for this reason that it is important to select more than one (I would say at least 3) beads so that we can get a joint displacement that is mostly independent of the individual localization error. Once we have the displacement value it is then subtracted to the particle table and hopefully the drift is corrected.

The challenge comes from the probability of the beads not being detected in all the frames due to several possible problems such as noise fluctuation, bead blinking, other signals appearing on the same region, bad temper from the part of the detection algorithm and/or Godzilla attacking your local town. For this reason the drift correction algorithm tries to interpolate missing positions in time for each cluster - this is the main reason why the algorithm has an iterative part, it basically:

a) - tries to interpolate the bead missing positions in time

b) - recalculates the center of each cluster

c) - recalculates the joint displacement

d) - subtracts the displacement to all particles

e) - loops back to a) unless the joint displacement estimation stops varying from iteration to iteration 

There are some conditions that need to be met in order for this to work well, namely:

  - the beads/landmarks need to be sub-diffraction

  - they cannot be saturated

  - the sparsity of the tracks needs to be fairly small, or in other words, beads really need to be detected in most frames

  - by experience the algorithm has problems dealing with drifts higher than 500nm XY and 200nm in Z

I would definitely appreciate if anyone has suggestions for improvements :). 

Let me know if this is understandable or I can try to explain a bit further.

Cheers,

Ricardo Henriques

--
Ricardo Henriques
PhD Student
Gene Expression and Biophysics Unit
Institute of Molecular Medicine
Faculty of Medicine, University of Lisbon
Av. Prof. Egas Moniz
1649-028 Lisbon, Portugal
Phone: + 351 217999503, Ext: 47318
Fax: + 351 217999504
E-mail: rhenr...@fm.ul.pt

[Nico Stuurman]

Can you explain how the "Correct for particle drift" option works?  I did select an ROI in an image and run this option, but the result seem to be introduction of more jitter and I do not know what the code is doing.

I created a small example movie tutorial on http://code.google.com/p/quickpalm/wiki/Tutorial_Drift_correction.

Naively, I would think that the most efficient way to correct for stage drift is to find spots that occur in two consecutive images and use these to reconstruct movement of the image as a whole.  Once you have that, it is straight forward to subtract from each of the individual particles.

You are correct and that is partially what the algorithm is doing except there is a part that is not very straight forward. So, the idea is that the user selects for example beads on the reconstruction and adds them to the ROI manager, next the correction algorithm calculates the center of the cluster correspondent to each bead and calculates the joint displacement over time.

Ah, so you are using fiducial markers.  That definitely explains why this correction did not work for me at all.

The alternative approach (more elegant in my mind) is to use the "experimental" molecules.  Most spots should appear in more than one image, so their frame to frame displacement can be used to estimate stage drift.  As long as a sufficient number of spots persists from one frame to the next, molecule jitter and noise-induced localization inaccuracy will average out in the stage movement estimate.  

A possibly related question: what is the optimum number of spots per area?

Best,

Nico

[Ricardo Henriques]

hi,

> The alternative approach (more elegant in my mind) is to use the
> "experimental" molecules. Most spots should appear in more than one
> image, so their frame to frame displacement can be used to estimate
> stage drift. As long as a sufficient number of spots persists from
> one frame to the next, molecule jitter and noise-induced localization
> inaccuracy will average out in the stage movement estimate.

Yes, indeed that would be the more elegant way of doing it and the
cool part is that perhaps it could be done directly during the
acquisition. I did create an algorithm for this but the drift
estimation this way was always under-estimated. The main problem came
from having a huge amount of molecules blinking close to each other
and correlating what is the same molecule in diferent frames. I only
worked on this for a couple of days though, perhaps with a bit of
patience there is a way to getting it to work.

> A possibly related question: what is the optimum number of spots per
> area?

the algorithm when detecting a single particle looks into an area that
is twice the size of the estimated FWHM... roughly for a 512x512 in 2D
it would be good to get around 100 particles per frame or in 3D with
astigmatism around 20

cheers,
Ricardo
>
> Best,
>
> Nico