[OpenSPIM] Anti-drift update

[Aurelia Honerkamp-Smith]

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>
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/20140812/3f45d271/attachment-0002.html>