Autofocus help

I am not sure what this means. Can you clarify?

Hi sorry for late response, by quick turnaround i mean an other way of finding the focus point than the one used today.
something like peak intensity over pixels, or snr distribution over the image does works on other type of imagingā€¦

I donā€™t think there is anything particularly ā€œquickā€ about this. While the methods you are referring to might be sound in theory (we have other implementations of AF), we are having difficulty ā€œapproximatingā€ these types of metrics over ā€œwhole screenā€ images (in any reasonable period of time).

One option would be trying the pinpoint FWHM method if you have Pinpoint.

Thanks,
Jared

Hello jared and Ken, i have to try the fwhm with pin point you show, but iā€™m afraid this take ages to run a vcurve with.
Iā€™m sorry to use the word quick as this is too many often heard by devsā€¦
However, we develloped at work an autofocus solution on a 900x900 pixels 16 bit image running at 12fps
using spatialy distributed snr methode .
Iā€™m not a dev myself, but the guy i was working with were not saying that was a big thing to doā€¦
only my two centsā€¦ :smile:
centainly the high frame rate helps in this situation and is far from what we use we takin a sky pictureā€¦

Thanks Jared - does the FWHM metric cope better with SCT/RCTs?

Buzz, I didnā€™t notice a huge difference. The biggest influencer is necking down your focus spread so you donā€™t see the donuts or minimize them as much as possible.

We can all take one glance at an image and say that itā€™s out of focus; we can see the doughnuts. And if we change focus and try again we can say if itā€™s better or worse.

Is there some way that, rather than avoid the problem of doughnuts, they can be used as an indication of focus quality? Lack of quality really.

The circular Hough transform comes to mindā€¦

Chris

While we really appreciate the suggestions, the fact remains that we have tried many different ideas, and while mathematically sound, we have not refined them to the point where the economy of power required to perform them across a large scale image is satisfactory to most machines. We will continue to work on itā€¦

Tell you what Ken, if I can come up with something that works Iā€™ll give you first refusal :slight_smile:

All Iā€™m suggesting is that we should think about how to solve this problem rather than how to avoid it. Thereā€™s been a huge amount of research on pattern recognition and some of it may have something useful that would help.

Chris.

Well now that my focus motor is upside down and backlash is handled properly, I can help others to use autofocus with an SCT and SGP. Here is a focus curve from last night:

This is with an Edge11 with reducer. This focus curve is a re-run after finding focus - and indicates the curve is not only well behaved, but it is repeatable. The focus setup is just a robofocus on the primary focuser and it is geared down so there are about 2000 steps per rotation of the focus knob - so the range shown here is very close to focus. This curve was started close to focus and spans only the central parabolic section, and avoids the stars becoming donuts. It also uses the central 50% of the field and 2x binning.

For a non-edge sct where coma and field curvature would be a factor, I would make sure it is collimated and use the central cropped region.

My only complaint is that the exact focus should be found based on the parabolic shape of the curve rather than the intersection of two fitted straight lines. The routines in FocusMax and others are based on going far from focus and looking at a single star - but when you have many stars to analyze you should be able to stay near focus and get a good view of the shape of the curve.

Oh - and I also have the ā€œadvanced focusā€ thing turned off here.

Once the mechanics are solid and backlash is handled properly - I think the existing code should work well as-is. If it doesnā€™t there may be other factors in the setup or something. But mainly, as suggested above, I would stay closer to focus during the curve so donuts donā€™t appear.

Frank

@Chris

Please feel free to point us to research or other public sources of information. For a variety of reasons, we must politely decline code-based contributions from our users.

Ken

@freestar8n that looks promising and gives me an ideaā€¦

@ken - just a thought - you mentioned the time taken to compute the entire image - obviously you are going for ā€˜fullā€™ image and focusmax / maxim go for a single star. Perhaps there is a happy medium - if you think about it focusmax is very picky on what star it uses and goes away to find the Goldilocks one (just right) - maybe SGP can select say 10-20 stars selected by their intensity in the full image and do the HFR calculation on those alone?
The second thought is prompted by the U rather than V curve above - recall my algorithm for fitting it with a quadratic - that is just maths and easy to implement and would only be triggered if your line-fitting routine could not find one.
The excel chart that can be used to model its effectiveness is still there in dropbox:

If I set it up for the curve above - it figures a focus point of about 34487

Anyway, itā€™s just a thought.

I think your idea of fitting a quadratic makes sense but in your example you are choosing three arbitrary points around the minimum thus not taking advantage of the other data. I suggest using a least-squares fit such as given here Classroom Resources - National Council of Teachers of Mathematics That would use all the data points. Since the data curve is quite flat, curve fitting has the potential of giving a better result than trying to do a linear fit of the sides of the curve. In my own experience, I often find that there are one or more clear outlier points. Perhaps an approach that does two curve fits would work better. The first attempt would use all the data and the second attempt would remove data points that are off the curve by some amount. If there are too many divergent points that would be a clue that the process is failing.

Also, the idea of selecting a subset of stars makes sense to reduce the computation. I assume that giving preference to stars near the center of the image would give a better result. Perhaps using some sort of weighting approach where stars near the center contribute more to the result.

Lastly, as was pointed out by another poster, when you start getting donuts the star diameters are clearly increasing. So perhaps a hybrid algorithm that looks at HFR and star diameter would be the way to go. The current algorithm starts off by moving the focuser to one end of the curve as defined by the user. Perhaps a better approach would be to take one image it the current focuser position to establish a baseline. If the star diameters are getting much larger than the baseline you know there is a problem. The current algorithm is predicated on the idea that the focus is near the ideal so why not take advantage of that fact. Moving the focuser in steps away from the current position (rather than moving to the curve edge) would give feedback about whether you are getting into large diameters. Of course, backlash has to be taken into account.

1 Like

Hi Frank,

Iā€™m happy to take up your offer of help! :slight_smile: I have a standard C11 and my SXVR-H694 and reducer gives a field of about 22x28 arcmin. With that FOV, thereā€™s a bit of distortion, though nothing like what I got with my old QHY8. Do you think Iā€™m better off with full FOV/more stars or subframe/fewer stars? I donā€™t have much trouble with focusing, but better is always good. And Iā€™m collimated with Metaguide, of course!

Kevin

Per my previous post, I tried the data that buzz provided with a least squares fit. The resulting graph shows a very nice correlation between the actual and calculated curve. However, for this particular data there is not a lot of difference between the least squares calculation and the SGP or 3 points calculations for the actual focus position. Nevertheless, the least squares calculation is on better theoretical footing than doing linear fits of the sides of the curve.

Here is a DropBox link to the Excel sheet. Dropbox - Error

Hi-

When I said ā€œthe focus should be found based on the parabolic shapeā€ - what I meant was to use a curve fit rather than the two straight-line fits. I have my own focus code but it doesnā€™t integrate well with SGP and I think the sgp approach should work fine. In my own code, for an sct I found that quadratic isnā€™t adequate to describe the shape of the curve and it needs at least a cubic fit.

I donā€™t know how people are currently doing focus runs with sgp, but if they are getting big donuts with an sct, it sounds like they are thinking of focusmax with one bright star rather than sgp with many stars - so you donā€™t need to go so far from focus. In my case I used a fairly dense star field with uniform star brightness and then a 50% crop mainly to speed the process. The seeing was fairly good so the curve was well shaped - but it should still be ok with imperfect seeing.

I havenā€™t used this enough to know that it is robust in an unattended imaging session, but it seems promising so far - as long as you start near focus.

And for focusing an sct with the primary focuser - make sure backlash is handled and goes the right direction. In my case I use a full turn of backlash compensation - which takes about 45 seconds and adds a lot of time to the process. But it only gets invoked at the start of autofocus and when it completes.

Frank

Of course, all our ā€˜helpā€™ is interesting but not the entire story. It is easy for us to sit back and say ā€™ off you go Ken, here is an equation, what is the problem? Can I have it for 2.5?". Finding an algorithm that Ken and Jared can code and for it to work robustly in hundreds of different cases is a completely different matter. With the diverse range of equipment, it does seem more likely there may need to be alternatives to suit wide-range and close-range focusing. Clearly FM does wide range with linear regression - Iā€™ll have to dig it out and try it with ahem, Maxim, to see how it copes with my RCT!

So, off you go Ken. Can I have it for a beta for next week? :wink:

My main point is that the existing code appears to work well well for an sct when used in this way. The line intersection routine isnā€™t ideal here - but it is essentially perfect focus for my setup because the horizontal scale is so fine.

By capturing the minimum of the focus curve in detail with multiple stars, there is no need to go far from focus where donuts and other algorithms are required.

For an sct and some other setups - it does require backlash to be handled properly, and it does require starting from near focus in the first place.

I used focusmax with maxim and I didnā€™t find it worked well - and I didnā€™t like the idea of using only one star for all the information - and extrapolating far from focus. The sgp implementation captures the main aspects that I would want in an autofocus routine.

Iā€™m not sure if the approach I describe here will give a nice curve for everyone as it did for me - but my setup is relatively challenging, being an sct with robofocus on the primary focuser. So if it works for me - it seems like it should work for others - and for those who are having trouble with the existing routine.

Frank

an sct is not a fast newtonian, and the results on my fast obstructed ota are pretty
strange and time consuming, i found focusing completly non repetable, position differs with filters, exposure duration
star distribution and numbers, and so on.
I did try to implement offsets, and wasnā€™t able to have something reproductible.
So far, focumax stay the gold standard for focusing (at least in my opinion for my particular setupā€¦).

I have to go back on this when possible. and make more tests to find out what i missed.