[OpenSPIM] Anti-drift update

[Luke Stuyvenberg]

Hi Aurelia,

Interestingly, the 'suggested' diffs didn't seem to be lining up all 
that often -- and there's certainly enough shape information there for 
the phase correlation to have corrected for the displacement... It may 
be that a change in imglib2 has caused these effects, but it could just 
as easily be that the suggested diffs are being written improperly. 
Perhaps the phase correlation algorithm has changed somehow, and it's 
picking non-ideal correlation shifts? (This could possibly cause the 
entirely-automatic corrections to under-correct.)

A few other ideas to check:

- Is it possible the camera or its firmware is reversing the image 
horizontally (as some webcams do, to produce the 'mirror' effect)? And 
is your camera mounted right-side up? i.e. is the top of the frame in 
the direction of the top of the sample chamber?
- Did the flip or mirror device settings have an effect? (I don't know 
that the PicardStage device adapter respects the 'flip' setting; a quirk 
in the MM programming made this next to impossible last time I tried.)
- How's the contrast/signal when looking at your sample?

This would be a lot less confusing if our earlier anti-drift tests had 
shown the same behavior! ;-)

As a final thought, could you try guiding the anti-drift through an 
entire acquisition? It would help narrow the search by determining if 
the automatic (phase-correlation) correction is to blame for this issue, 
or if the anti-drift in general is at fault.

Luke

On 8/12/2014 9:25 AM, Aurelia Honerkamp-Smith wrote:
> Hi Luke,
>
> Thanks!  I'll send you the anti-drift debugging images in a moment.  I 
> measured pixel size by taking a picture of my calibration grid and 
> counting pixels per line.  I only vaguely verified its accuracy by 
> checking that the displacement of the embryo in the composite image I 
> sent before was about the same as the correction listed in the 
> anti-drift log file, and since they match approximately, I didn't look 
> further.  I could use the "move a bead with the stage" method to check 
> this more carefully, but it seems to be about right.
> The test is very repeatable, and in the case of making a small 
> correction to either Y or Z the stage moves to the suggested location 
> and then doesn't move significantly afterwards.
> Let me know if you think of some more helpful test I could do.  I'm 
> not certain that there isn't some hardware oddity causing this, but so 
> far I haven't figured out what it could be.
>
> Aurelia
>
>
>
> On Tue, Aug 12, 2014 at 3:47 AM, Luke Stuyvenberg 
> <stuyvenberg at wisc.edu <mailto:stuyvenberg at wisc.edu>> wrote:
>
>     Hi Aurelia,
>
>     Sorry about the delay; I've just moved across the States, and ran
>     into enormous trouble getting my internet connection established.
>
>
>     On 7/31/2014 10:21 AM, Aurelia Honerkamp-Smith wrote:
>
>         If I make a correction to Y or Z, I get the result I expect;
>         the image moves the right distance, in the right direction,
>         and then doesn't move again in the last 3 frames. But if I
>         make a correction in X, the stage moves to the correct
>         position, but then on the following frame moves 2x the
>         previous distance, and then next time moves 2x the previous
>         one again, until it leaves the field of view.  The attached
>         image shows z-projections of subsequent frames, with red being
>         the first one, green the second, and blue is third frame.  If
>         I correct to the left instead of right, the embryo continues
>         off to the left instead.  Setting the stage or the camera to
>         "transpose mirror X" in the tools/property browser changes
>         whether the live view mouse control behaves correctly, but
>         doesn't alter this behavior.
>         A sample log file showing the anti-drift corrections:
>         ...
>
>     It's interesting to me that Y isn't affected -- I presume you've
>     tried this same test with a slight Y correction? And how did you
>     measure your pixel size/have you verified its accuracy? Is this
>     same test repeatable? I've been working on a test to validate the
>     behavior of the anti-drift, and while it's not yet advanced enough
>     for me to be certain there's no software fault here, I haven't
>     been able to obtain these dramatic jerks so far.
>
>     When anti-drift is on, the software produces a directory
>     containing some images useful for debugging problems with it -- if
>     it's not too large, could you compress and send those files? (If
>     they're more than a few megabytes, you can probably send it
>     directly to me to spare other users' inboxes.) They might also
>     help identify any problems.
>
>     Hope these questions help shed some light on the issue,
>     Luke
>
>
>     On 7/31/2014 10:21 AM, Aurelia Honerkamp-Smith wrote:
>
>         Hi,
>         I'm still having trouble with the anti-drift function, and I'm
>         not sure how to proceed.  To explain the trouble, I made the
>         following test: I set up a 5-time point acquisition with only
>         one view, turned on the anti-drift, and made a manual
>         correction to first one, then made no more adjustments after
>         that.  The frames are 100 seconds apart, so no significant
>         actual drift should be occurring.
>         If I make a correction to Y or Z, I get the result I expect;
>         the image moves the right distance, in the right direction,
>         and then doesn't move again in the last 3 frames. But if I
>         make a correction in X, the stage moves to the correct
>         position, but then on the following frame moves 2x the
>         previous distance, and then next time moves 2x the previous
>         one again, until it leaves the field of view.  The attached
>         image shows z-projections of subsequent frames, with red being
>         the first one, green the second, and blue is third frame.  If
>         I correct to the left instead of right, the embryo continues
>         off to the left instead.  Setting the stage or the camera to
>         "transpose mirror X" in the tools/property browser changes
>         whether the live view mouse control behaves correctly, but
>         doesn't alter this behavior.
>         A sample log file showing the anti-drift corrections:
>         TP 0 view 0: Offset: {8.6508; 0; 0}  (this x correction is the
>         one I have put in)
>         TP 0 view 0: Offset: {16.46055; -0.2493; 0}
>         TP 0 view 0: Offset: {34.48305; 0.2403; 0}
>         TP 0 view 0: Offset: {69.08625; -1.08135; 0}
>
>         It seems like there is a sign error of some kind, but I can't
>         figure out a way to change my configuration to correct it.  I
>         have already switched the X and Y serial numbers in my
>         configuration file, which improved things a little (previously
>         this test resulted in the embryo traveling in circles).
>         Any ideas?
>         Thanks,
>         Aurelia
>
>
>
>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openspim.org/pipermail/openspim/attachments/20140820/c922e0d2/attachment.html>