<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hi Aurelia,<br>
<br>
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.)<br>
<br>
A few other ideas to check:<br>
<br>
- 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?<br>
- 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.)<br>
- How's the contrast/signal when looking at your sample?<br>
<br>
This would be a lot less confusing if our earlier anti-drift tests
had shown the same behavior! ;-)<br>
<br>
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.<br>
<br>
Luke<br>
<br>
On 8/12/2014 9:25 AM, Aurelia Honerkamp-Smith wrote:<br>
</div>
<blockquote
cite="mid:CAHAw+8b4q5Z9Kuhfpm0-97Ltf-ySb=izyQfRfJfAOkRPwaNS5Q@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>
<div>Hi Luke, <br>
<br>
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. <br>
</div>
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. <br>
</div>
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. <br>
<br>
</div>
Aurelia<br>
<br>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Tue, Aug 12, 2014 at 3:47 AM, Luke
Stuyvenberg <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:stuyvenberg@wisc.edu" target="_blank">stuyvenberg@wisc.edu</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Hi
Aurelia,<br>
<br>
Sorry about the delay; I've just moved across the States,
and ran into enormous trouble getting my internet connection
established.
<div class=""><br>
<br>
On 7/31/2014 10:21 AM, Aurelia Honerkamp-Smith wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">
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.<br>
A sample log file showing the anti-drift corrections:<br>
</div>
...<br>
</blockquote>
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.<br>
<br>
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.<br>
<br>
Hope these questions help shed some light on the issue,<br>
Luke
<div class="HOEnZb">
<div class="h5"><br>
<br>
On 7/31/2014 10:21 AM, Aurelia Honerkamp-Smith wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
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.<br>
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.<br>
A sample log file showing the anti-drift corrections:<br>
TP 0 view 0: Offset: {8.6508; 0; 0} (this x
correction is the one I have put in)<br>
TP 0 view 0: Offset: {16.46055; -0.2493; 0}<br>
TP 0 view 0: Offset: {34.48305; 0.2403; 0}<br>
TP 0 view 0: Offset: {69.08625; -1.08135; 0}<br>
<br>
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).<br>
Any ideas?<br>
Thanks,<br>
Aurelia<br>
<br>
<br>
</blockquote>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>