Autofocus Problem

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Autofocus Problem

Eik Schumann
Dear list,
I was trying to use autofocus-algorythms these days on dapi-stained cell
nuclei.
First I tried "oughta-focus". The advantage here is that you can watch
the algorythm working. I used the autofocus in a multidimensional
aquisition setup including a stack-aquisition. During aquisition I
observed the autofocus finding the sharpest plane. But after that the
z-drive started the stack off-focus and ended in the plane with the best
contrast. So the autofocus seemed to work somehow, but this plane is not
taken over as the central plane of the stack .
Since I defined a relative Z-range (-3µm --> 3µm) I didn`t expect this
behaviour.
To control if this is a behaviour specific to "oughtaFocus" I tried
"SimpleAutoFocus".
On a fix position SimpleAF worked quite fine when clicking the
"AutoFocus now" button. (I just checked with a snapShot before and after
AF).
Intergrating simpleAF in a multidimensional aquisition was less
successful. Again the sharpest plane wasn`t in the center but somewhere
in the last quarter of the stack.
Is the autofocus supposed to work on ROIs during aquisition?
In case anybody used any of the AF-algorythms more successful I would be
pleased to get some advice how to do it.
Thank you in advance

Eik

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
micro-manager-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/micro-manager-general
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Re: Autofocus Problem

Arthur D. Edelstein
Hi Eik,

This sounds like a bug in multidimensional acquisition rather than the
autofocus plugin. What version of Micro-Manager are you using? Please
make sure you have upgraded to the latest nightly build. If you still
find this bug, please let me know.

Best regards,
Arthur



On Tue, Oct 11, 2011 at 8:21 AM, Eik Schumann <[hidden email]> wrote:

> Dear list,
> I was trying to use autofocus-algorythms these days on dapi-stained cell
> nuclei.
> First I tried "oughta-focus". The advantage here is that you can watch
> the algorythm working. I used the autofocus in a multidimensional
> aquisition setup including a stack-aquisition. During aquisition I
> observed the autofocus finding the sharpest plane. But after that the
> z-drive started the stack off-focus and ended in the plane with the best
> contrast. So the autofocus seemed to work somehow, but this plane is not
> taken over as the central plane of the stack .
> Since I defined a relative Z-range (-3µm --> 3µm) I didn`t expect this
> behaviour.
> To control if this is a behaviour specific to "oughtaFocus" I tried
> "SimpleAutoFocus".
> On a fix position SimpleAF worked quite fine when clicking the
> "AutoFocus now" button. (I just checked with a snapShot before and after
> AF).
> Intergrating simpleAF in a multidimensional aquisition was less
> successful. Again the sharpest plane wasn`t in the center but somewhere
> in the last quarter of the stack.
> Is the autofocus supposed to work on ROIs during aquisition?
> In case anybody used any of the AF-algorythms more successful I would be
> pleased to get some advice how to do it.
> Thank you in advance
>
> Eik
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2d-oct
> _______________________________________________
> micro-manager-general mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/micro-manager-general
>

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
micro-manager-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/micro-manager-general
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Re: Autofocus Problem

Eik Schumann
In reply to this post by Eik Schumann
Hello Arthur,
I was using the nightly build MMSetup32BIT_1.4.7_20111002
Now I tried to upgrade, but the PI-GCS2 device adapter is not included
in this build. Using the old dll generates a device version conflict.
So I can not test with the newest build.
Is something wrong with the new PI-GCS2 adapter?

But concerning autofocus: the autofocus plugins usually work without
problems?

Best Regards

Eik


 > Hi Eik,
 >
 > This sounds like a bug in multidimensional acquisition rather than the
 > autofocus plugin. What version of Micro-Manager are you using? Please
 > make sure you have upgraded to the latest nightly build. If you still
 > find this bug, please let me know.
 >
 > Best regards,
 > Arthur



On Tue, Oct 11, 2011 at 8:21 AM, Eik Schumann <[hidden email]> wrote:

 > Dear list,
 > I was trying to use autofocus-algorythms these days on dapi-stained cell
 > nuclei.
 > First I tried "oughta-focus". The advantage here is that you can watch
 > the algorythm working. I used the autofocus in a multidimensional
 > aquisition setup including a stack-aquisition. During aquisition I
 > observed the autofocus finding the sharpest plane. But after that the
 > z-drive started the stack off-focus and ended in the plane with the best
 > contrast. So the autofocus seemed to work somehow, but this plane is not
 > taken over as the central plane of the stack .
 > Since I defined a relative Z-range (-3µm --> 3µm) I didn`t expect this
 > behaviour.
 > To control if this is a behaviour specific to "oughtaFocus" I tried
 > "SimpleAutoFocus".
 > On a fix position SimpleAF worked quite fine when clicking the
 > "AutoFocus now" button. (I just checked with a snapShot before and after
 > AF).
 > Intergrating simpleAF in a multidimensional aquisition was less
 > successful. Again the sharpest plane wasn`t in the center but somewhere
 > in the last quarter of the stack.
 > Is the autofocus supposed to work on ROIs during aquisition?
 > In case anybody used any of the AF-algorythms more successful I would be
 > pleased to get some advice how to do it.
 > Thank you in advance
 >
 > Eik
 >
 >
------------------------------------------------------------------------------
 > All the data continuously generated in your IT infrastructure contains a
 > definitive record of customers, application performance, security
 > threats, fraudulent activity and more. Splunk takes this data and makes
 > sense of it. Business sense. IT sense. Common sense.
 > http://p.sf.net/sfu/splunk-d2d-oct
 > _______________________________________________
 > micro-manager-general mailing list

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
micro-manager-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/micro-manager-general
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Re: Autofocus Problem

Conor
In reply to this post by Eik Schumann
Hello,

I am having the same problem.  I have a set of acquisition positions which are all offset from the sample in the z-direction (due to agar shrinkage overnight).  I am attempting to track the z-position during a timecourse using oughtafocus.  If I move to one of my multidimensional acquisition positions and press the autofocus button, micromanager focusses magically.  If instead I try to carry out a fully automatic multidimensional acquisition (with the autofocus option selected) using the same oughtafocus settings, the acquired image is not in focus.  By displaying intermediate images during focus (ShowImage->True, very useful for debugging) I can even see that oughtafocus is finding sharp images, exactly as when I use it "manually", however multidimensional acquisition does not store the focussed image for my timelapse.

Any tips for how to get oughtafocus and multidimensional acquisition to communicate with each other would be appreciated.

Regards,

CONOR.

Eik Schumann wrote
...So the autofocus seemed to work somehow, but this plane is not
taken over as the central plane of the stack .
Since I defined a relative Z-range (-3µm --> 3µm) I didn`t expect this
behaviour.
To control if this is a behaviour specific to "oughtaFocus" I tried
"SimpleAutoFocus".
On a fix position SimpleAF worked quite fine when clicking the
"AutoFocus now" button. (I just checked with a snapShot before and after
AF)....
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Re: Autofocus Problem

Conor
PS I am using the latest nightly build.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Re: Autofocus Problem

Zhanna
I noticed the same, so I introduced some changes to the Autofocus.java (https://valelab.ucsf.edu/svn/micromanager2/trunk/autofocus/Autofocus.java):
- I set the limits of my Z stage, so that it does not try to go over them;
- then I simply commented out breaking condition in both Rough and Fine search loops, because it caused choosing the wrong image plane (so, at the moment it acts always as a full autofocus, but it works perfectly!):
/*else if (bestSh - curSh > THRES*bestSh && bestDist < 5000){
               break;
            }*/

At the moment I'm trying to find a better exit condition, but if it's made according to the "sharpness",which is proportional to exposure time, I need to get the value of the exposure. So if it is possible to get exposure time into the plugin, that would solve the problem, I guess (at least for my probes - fluorescent beads).

I have encountered another problem - when replacing the native MMAutofocus.jar with the modified version, other plugins "disappear" - I cannot use them, and the preferences dialog shows up only after I start Autofocus once. If I try to install other AF plugins via the Startup.bsh, the pref. dialog does not work at all - it does not show any fields to enter values. (I bet it's not the right way to do, but I have no idea what is correct)

Any suggestions?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Re: Autofocus Problem

Conor
Thanks for the tip Zhanna!  Very helpful.

I can't really see an equivalent condition in the Oughtfocus code:

https://valelab.ucsf.edu/svn/micromanager2/trunk/autofocus/OughtaFocus.java

I don't see the "run" function from autofocus.java being used in OughtaFocus.java, though I might be missing something.

Perhaps there are two conflicting definitions of THRESH, one from multidimensional acqusition and one from autofocus, causing this conflict?  Otherwise, I'm not sure I can see why this change would allow multi-d + autofocus to work where before multi-d + autofocus doesn't work AND autofocus alone does work.

Regards,

CONOR.

Zhanna wrote
I noticed the same, so I introduced some changes to the Autofocus.java (https://valelab.ucsf.edu/svn/micromanager2/trunk/autofocus/Autofocus.java):
- I set the limits of my Z stage, so that it does not try to go over them;
- then I simply commented out breaking condition in both Rough and Fine search loops, because it caused choosing the wrong image plane (so, at the moment it acts always as a full autofocus, but it works perfectly!):
/*else if (bestSh - curSh > THRES*bestSh && bestDist < 5000){
               break;
            }*/

...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Re: Autofocus Problem

Arthur D. Edelstein
Hi Conor, Zhanna, and Eik,

Thanks to Conor's help, I have fixed a bug where using multiple positions caused Multi-Dimensional Acquisition to incorrectly disregard the results of autofocus. The fix should be available in the next nightly builds. Please let me know if autofocus works correctly for you now, or if you are still encountering problems.

Best regards,
Arthur


On Sat, Oct 22, 2011 at 5:28 AM, Conor <[hidden email]> wrote:
Thanks for the tip Zhanna!  Very helpful.

I can't really see an equivalent condition in the Oughtfocus code:

https://valelab.ucsf.edu/svn/micromanager2/trunk/autofocus/OughtaFocus.java

I don't see the "run" function from autofocus.java being used in
OughtaFocus.java, though I might be missing something.

Perhaps there are two conflicting definitions of THRESH, one from
multidimensional acqusition and one from autofocus, causing this conflict?
Otherwise, I'm not sure I can see why this change would allow multi-d +
autofocus to work where before multi-d + autofocus doesn't work AND
autofocus alone does work.

Regards,

CONOR.


Zhanna wrote:
>
> I noticed the same, so I introduced some changes to the Autofocus.java
> (https://valelab.ucsf.edu/svn/micromanager2/trunk/autofocus/Autofocus.java):
> - I set the limits of my Z stage, so that it does not try to go over them;
> - then I simply commented out breaking condition in both Rough and Fine
> search loops, because it caused choosing the wrong image plane (so, at the
> moment it acts always as a full autofocus, but it works perfectly!):
> /*else if (bestSh - curSh > THRES*bestSh && bestDist < 5000){
>                break;
>             }*/
>
> ...
>


--
View this message in context: http://micro-manager.3463995.n2.nabble.com/Autofocus-Problem-tp6881383p6920026.html
Sent from the Micro-Manager mailing list archive at Nabble.com.

------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
_______________________________________________
micro-manager-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/micro-manager-general


------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
_______________________________________________
micro-manager-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/micro-manager-general
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Re: Autofocus Problem

Conor
Hello Arthur,

Many thanks for looking into this!  Acquisition is much improved, I've been able to get a long list of positions focussed and captured successfully.  Does micromanager now update the z-position in the acquisition position list after autofocus?  I hadn't noticed that before, that is a great improvement and will make my life a lot easier.

I still have a couple of gremlins, probably related to imperfect autofocus settings on my part, but I will try a proper experiment at 60 locations overnight tonight and see how that goes.

One thing I did notice just now, that I had not noticed before today was that during multi-d acquisition the last image displayed by Live view before it is "stopped" for autofocussing is one of the subject while the stage is still moving.  This image has motion blur as well as focus blur.  I wonder if this moving image is used as the first image in the autofocus sequence?  That would cause a problem for the search algorithm as it would not understand blurriness caused by anything but z-position.

Thanks again,

CONOR.



Arthur D. Edelstein wrote
Hi Conor, Zhanna, and Eik,

Thanks to Conor's help, I have fixed a bug where using multiple positions
caused Multi-Dimensional Acquisition to incorrectly disregard the results of
autofocus. The fix should be available in the next nightly builds. Please
let me know if autofocus works correctly for you now, or if you are still
encountering problems.

Best regards,
Arthur
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Re: Autofocus Problem

Arthur D. Edelstein
Hi Conor,

> Many thanks for looking into this!  Acquisition is much improved, I've been
able to get a long list of positions focussed and captured successfully.

Great, I'm glad!

Does micromanager now update the z-position in the acquisition position list
after autofocus?

This was the intended behavior, but was affected by the bug you reported. I hope it is now working correctly.
 
I still have a couple of gremlins, probably related to imperfect autofocus
settings on my part, but I will try a proper experiment at 60 locations
overnight tonight and see how that goes.

I'll be interested to hear it. What kinds of settings do you use in your proper experiment?
 
One thing I did notice just now, that I had not noticed before today was
that during multi-d acquisition the last image displayed by Live view before
it is "stopped" for autofocussing is one of the subject while the stage is
still moving.  This image has motion blur as well as focus blur.  I wonder
if this moving image is used as the first image in the autofocus sequence?

It is not supposed to be. I can think of at least one camera adapter with a bug that might cause this, however. What camera are you using?

Best regards,
Arthur

------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
_______________________________________________
micro-manager-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/micro-manager-general
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Re: Autofocus Problem

Conor
Hello again,

Great.  Updating z-position is very sensible.  I guess it could cause problems if focus fails once for whatever reason though, as the whole process would then be likely to diverge away from focus.

For the "proper" experiment, I wanted to use a narrower search range for autofocus, to get capture times down as much as possible.  Perhaps I was over keen with this.  I have been running it for an hour or so and many of my points have already lost focus, but a few stalwarts are staying in focus, which I'm very pleased about.

I'm using a ProgRes MF.  If you know of any issues with that, please let me know and I will get in touch with the guys from JenOptik.

Regards,

CONOR.

Arthur D. Edelstein wrote
Does micromanager now update the z-position in the acquisition position list
> after autofocus?
>

This was the intended behavior, but was affected by the bug you reported. I
hope it is now working correctly.


> I still have a couple of gremlins, probably related to imperfect autofocus
> settings on my part, but I will try a proper experiment at 60 locations
> overnight tonight and see how that goes.
>

I'll be interested to hear it. What kinds of settings do you use in your
proper experiment?


> One thing I did notice just now, that I had not noticed before today was
> that during multi-d acquisition the last image displayed by Live view
> before
> it is "stopped" for autofocussing is one of the subject while the stage is
> still moving.  This image has motion blur as well as focus blur.  I wonder
> if this moving image is used as the first image in the autofocus sequence?
>

It is not supposed to be. I can think of at least one camera adapter with a
bug that might cause this, however. What camera are you using?

Best regards,
Arthur
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Re: Autofocus Problem

Arthur D. Edelstein
Hi Conor,
 
For the "proper" experiment, I wanted to use a narrower search range for
autofocus, to get capture times down as much as possible.  Perhaps I was
over keen with this.  I have been running it for an hour or so and many of
my points have already lost focus, but a few stalwarts are staying in focus,
which I'm very pleased about.

You may find that the OughtaFocus search time is not too badly increased if you, say, double the range, because the algorithm (Brent's method) usually converges better than quadratically. To speed up the autofocus search, you can also try increasing the tolerance so that OughtaFocus doesn't spend extra iterations over-optimizing the position. If your camera is a bottleneck, you can try imposing a crop factor or shortening the exposure time. And of course you may not need to run autofocus at every time point.

I'm using a ProgRes MF.  If you know of any issues with that, please let me
know and I will get in touch with the guys from JenOptik.

I'm not aware of any. You can check to see if whether after you run live mode, pressing snap gives you a fresh image (and not the last image from live).
 
Best regards,
Arthur


------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
_______________________________________________
micro-manager-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/micro-manager-general
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Autofocus - another aspect

Peter Haub
I would like to add one aspect to the autofocus discussion.

While we are currently working out suitable autofocus modes and parameters for our project we found that the way to calculate focus values by dividing mean edge intensity by mean intensity of the image - a method described in papers, widely used in the field and optionally utilized in the OughtaFocus - can lead to focus failures.

Focus values of dark images calculated in this way exceed the values from in-focus images.

To give an (artificial) example I have created a IJ image stack of one image (DAPI stained cells). Image 1 is the original. The images 2 to 5 or smoothed with a Gaussian (radius 0.5, 1.0, 2.0, 4.0) to simulated out of focus z-positions. To simulated the problem I have divided image 5 by a value of 20. (Cells can be visualized be increasing the contrast.)
With a short IJ macro I calculated the edge based sharpness in the way the OughtyFocus is doing it:
          double meanIntensity = ip.getStatistics().mean;
          ip.findEdges();
          double meanEdge = ip.getStatistics().mean;         
          return meanEdge/meanIntensity;

The values for the example stack are:
Focus Value 'Edge' (slice 1) =0.396118778135568
Focus Value 'Edge' (slice 2) =0.3956836609095465
Focus Value 'Edge' (slice 3) =0.39129756958318224
Focus Value 'Edge' (slice 4) =0.3784508143789083
Focus Value 'Edge' (slice 5) =1.818627450980392

Even if in the most practical situations the method will work, I think it is worth to know about this aspect and to avoid circumstance in which this problem may become relevant.

Regards,
Peter

ps: Attached you find a resized version of the test stack and the IJ plugin.

pps: Black images (as a result of camera problems) lead to a division by zero.


On 27.10.2011 20:45, Arthur D. Edelstein wrote:
Hi Conor,


For the "proper" experiment, I wanted to use a narrower search range for
autofocus, to get capture times down as much as possible.  Perhaps I was
over keen with this.  I have been running it for an hour or so and many of
my points have already lost focus, but a few stalwarts are staying in
focus,
which I'm very pleased about.

You may find that the OughtaFocus search time is not too badly increased if
you, say, double the range, because the algorithm (Brent's method) usually
converges better than quadratically. To speed up the autofocus search, you
can also try increasing the tolerance so that OughtaFocus doesn't spend
extra iterations over-optimizing the position. If your camera is a
bottleneck, you can try imposing a crop factor or shortening the exposure
time. And of course you may not need to run autofocus at every time point.

I'm using a ProgRes MF.  If you know of any issues with that, please let me
know and I will get in touch with the guys from JenOptik.

I'm not aware of any. You can check to see if whether after you run live
mode, pressing snap gives you a fresh image (and not the last image from
live).

Best regards,
Arthur

------------------------------------------------------------------------------ The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev
_______________________________________________ micro-manager-general mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/micro-manager-general

------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
_______________________________________________
micro-manager-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/micro-manager-general

AutoFocusTest.7z (28K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Re: Autofocus - another aspect

Arthur D. Edelstein
Hi Peter,

Thanks for your feedback. I had a look at your images, and it seems to me that by dimming the image you have introduced rounding errors in pixel intensity that produce artefactual edges. Slice 5 is so dim that most pixels are zero, and the strong normalized edge values are the result of small-valued pixels (1-4 counts) adjacent to zero-valued pixels, where most of the background is exactly zero. Those pixel counts don't seem very realistic to me, but perhaps I'm unaware of some special cases. Have you acquired such an image in a real experiment?

In any case, it's probably always useful to experiment with different autofocus methods and parameters to find the best one that works for a given microscope setup and specimen. I'm also open to suggestions for other image scoring options for OughtaFocus.

Best regards,
Arthur


On Fri, Oct 28, 2011 at 1:24 AM, Peter Haub <[hidden email]> wrote:
I would like to add one aspect to the autofocus discussion.

While we are currently working out suitable autofocus modes and parameters for our project we found that the way to calculate focus values by dividing mean edge intensity by mean intensity of the image - a method described in papers, widely used in the field and optionally utilized in the OughtaFocus - can lead to focus failures.

Focus values of dark images calculated in this way exceed the values from in-focus images.

To give an (artificial) example I have created a IJ image stack of one image (DAPI stained cells). Image 1 is the original. The images 2 to 5 or smoothed with a Gaussian (radius 0.5, 1.0, 2.0, 4.0) to simulated out of focus z-positions. To simulated the problem I have divided image 5 by a value of 20. (Cells can be visualized be increasing the contrast.)
With a short IJ macro I calculated the edge based sharpness in the way the OughtyFocus is doing it:
          double meanIntensity = ip.getStatistics().mean;
          ip.findEdges();
          double meanEdge = ip.getStatistics().mean;         
          return meanEdge/meanIntensity;

The values for the example stack are:
Focus Value 'Edge' (slice 1) =0.396118778135568
Focus Value 'Edge' (slice 2) =0.3956836609095465
Focus Value 'Edge' (slice 3) =0.39129756958318224
Focus Value 'Edge' (slice 4) =0.3784508143789083
Focus Value 'Edge' (slice 5) =1.818627450980392

Even if in the most practical situations the method will work, I think it is worth to know about this aspect and to avoid circumstance in which this problem may become relevant.

Regards,
Peter

ps: Attached you find a resized version of the test stack and the IJ plugin.

pps: Black images (as a result of camera problems) lead to a division by zero.


On 27.10.2011 20:45, Arthur D. Edelstein wrote:
Hi Conor,


For the "proper" experiment, I wanted to use a narrower search range for
autofocus, to get capture times down as much as possible.  Perhaps I was
over keen with this.  I have been running it for an hour or so and many of
my points have already lost focus, but a few stalwarts are staying in
focus,
which I'm very pleased about.

You may find that the OughtaFocus search time is not too badly increased if
you, say, double the range, because the algorithm (Brent's method) usually
converges better than quadratically. To speed up the autofocus search, you
can also try increasing the tolerance so that OughtaFocus doesn't spend
extra iterations over-optimizing the position. If your camera is a
bottleneck, you can try imposing a crop factor or shortening the exposure
time. And of course you may not need to run autofocus at every time point.

I'm using a ProgRes MF.  If you know of any issues with that, please let me
know and I will get in touch with the guys from JenOptik.

I'm not aware of any. You can check to see if whether after you run live
mode, pressing snap gives you a fresh image (and not the last image from
live).

Best regards,
Arthur

------------------------------------------------------------------------------ The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev
_______________________________________________ micro-manager-general mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/micro-manager-general

------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
_______________________________________________
micro-manager-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/micro-manager-general



------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
_______________________________________________
micro-manager-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/micro-manager-general
Loading...