|
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 |
|
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 |
|
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 |
|
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.
|
|
PS I am using the latest nightly build.
|
|
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? |
|
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.
|
|
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. ------------------------------------------------------------------------------ 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 |
|
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.
|
|
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 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 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 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 |
|
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.
|
|
Hi Conor, For the "proper" experiment, I wanted to use a narrower search range for 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 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 |
|
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 meknow 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 |
|
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:
------------------------------------------------------------------------------ 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 |
| Powered by Nabble | See how NAML generates this page |
