Official Request for Improved Autofocus in SGP


Add me to the list. AF is slow but reliable on my 80mm refractor but it is unusable with my 10" RC. I have to focus manually by just eyeballing a portion of the star field (subframe) and tweaking the focus between images until I am happy. And I do bin 2x2 when focusing, to address Peter’s post above.

If you can focus using a small portion of the frame, providing an option to take multiple frames at each focus point would help minimize the effects of seeing by using some statistical analysis of the frames at a given focus point.


With respect to ROI focusing, it would be useful to choose the position of ROE. This can then serve to address issues like tilt tip in a system by measuring focusing in four corners.


really agree about this request.
It takes too long, mainly because of the time spent in downloading the whole frame (I have a KAF16200). Sometimes I do it manually…
Hope this will arrive soon !



+1. I upgraded to a 16200 camera, and with the longer download times, the AF session takes quite a bit longer.

I agree that the ROI method will give up some feature, namely to find the best average focus across the whole frame. To address the difference of the focus across the frame due to field curvature, etc., perhaps you could do it in steps:

  1. Create ROI to acheive best focus for a star near the central part of the frame.
  2. Take a full frame image and make a HFR map showing the areas that are sharp/soft and highlight stars in the frame that would have HFR values equivalent to the frame-average HFR.
  3. Make a map of the stars in these regions to use later for this profile as the ROI star you’d focus on.



ROI should be positionable within the frame, so you should be able to place and size the ROI as you need in order to optimize the performance of your focus throughout the frame. The ROI should not always be centered.

I think that AF would really need to be an optimized pipeline in SGP, tuned for the kind of camera. I think CCD benefits might be limited beyond simply the readout speed increase of ROI.

CMOS, however, could potentially benefit from a rethink in how AF is done. The way the normal downloads work, it currently takes ~2 seconds for SGP to read a frame even with the very high speed CMOS cameras. I know those cameras can read out a single full frame in about 0.4 seconds, and in video mode with an ROI of even 400x400 pixels they can crank out several hundred frames per second. I think it might be possible to use uncompressed ROI video and simple frame-grabbing to dramatically speed up the AF performance if you ROI brighter stars. And in the event that brighter stars are not available, with a dramatic improvement in AF performance it should be more viable to slew to a nearby bright star, AF on that, then slew back, and still be done in less time than it currently takes an AF run to complete.

With video ROI and frame grabbing, it should be possible to yank out multiple samples per focus point in seconds (or if the stars in the ROI are bright enough, less than a second), run through a 10-15 sample AF routine about a minute or less, and get back to business running the sequence as if AF barely happened.

Throw in an AF frequency curve, so that you can focus more often earlier in the evening, and you can improve things even more. The cost of doing AF in areas where there is a high temperature gradient through each night and frequent AF for the first few hours of each night is required, and possibly high frequency through lower altitude imaging is required, the cost of AF is fairly burdensome. It currently takes me several minutes every 10 minutes to run AF for the first 2-3 hours of the evening right now, which is an overhead cost of around 25-35%.


I’ll also support this request. For those of us who shoot with a DSLR it would be a great benefit.


So are there any concrete paths for customers to bank on, or is this still in a state of design decisions?


Still in design decisions. I’d like to add some robustness to our existing method and potentially add another option for auto focus. Having an external mechanism would be great too but that’s likely further out. Don’t bank on anything until you see it in a release or beta.



Appreciate the communication Jared. Happy to hold off and see how things evolve here. Lets keep the lines open through the process so folks can rest well. :wink:


I’d like to throw my 2 cents worth in this discussion. I support the request. I find that AF is a great add on in the imaging toolbox but one reaches some limitations quickly, one of which is the night long supervision.
I inquired in the past about having a “smart” AF that would decide when to autofocus on its own. Instead of having to decide on a predetermined curve of AF frequency the start of the night, the user would decide the drift tolerance he is ready to live with during the imaging session. Once SGP has reached that value, AF would be launched automatically. There would then be less wasted time in autofocusing when the scope has stabilized and is not really needed while you are getting value added sleep :slight_smile: . A pre-established curve would have some of those benefits but involves guess work by the user at the beginning of the night and it’s efficiency would depend a lot on the atmospheric conditions and temperature shifts that really happen that night. Those shifts are not always those anticipated or at that the anticipated rate.


I agree with Stephan’s post above in that SGP should only Auto-Focus when the actual target image indicates that a focus tweak is needed. Once the AF-ROI idea is implemented and the time required for AF is reduced, then SGP could look at each target image (the actual light frames) and decide, based on user input thresholds, if an AF run is needed. Then we would not need all those triggers like, run AF every 5 minutes, or 5 frames, or .5 degrees.

Just the 2 cents of a beginner…


This was discussed before, several years ago, about using an HFR trigger for AF. At the time it was discounted. If I recall correctly, the conclusion was it was very difficult to separate genuine focus drift from other factors that smudge stars, including changing seeing conditions and variations in autoguider performance. I think it is one of those nice ideas that seems like a sensible concept but in practice, falls short.


I disagree here. With a smart autofocus you would be guaranteed to have the best focus for the conditions at that time, even with seeing that is changing. If the autoguiding is the issue then not even the autofocusing pre-determined curve will be of any help either, you will have to supervise the AF as we have to do right now with even good guiding.
I think the idea was dismissed at that time as it was deemed difficult to get it implemented.


Out of interest - has it ever been implemented? I’m thinking Prism / MDL / FM / TSX.

[update - I’m talking specifically about using HFR as a trigger for AF. There would obviously be some form of limit within which there would be no action but I could also imagine my system spending its entire time doing AF runs - when it seems to work very well using focus-only triggers like filter changes and temperature.]


I love AF when it works, and I get perfect V curves, but it is slow and I frequently have issues with it, particularly with NB. Also odd that it can work fine half the night then suddenly go skewy. As things stand, improving AF would be my top priority, particularly speeding it up.


On a positive side, the integration with FocusLock was a very good idea and a great step forward for ONAG users.


In the early days, I had the same issue with NB. I don’t bother anymore. I focus with an LPS filter and then use filter offsets. It is much faster and more reliable. I only trigger AF routines with temp changes with all scopes and after a meridian flip with my RCT.

It takes about an hour to figure the offsets (especially if you use something like a GoldFocus mask) and then you are done!

I have a principled engineering objection to HFR triggered AF. The causes of variations in HFR are many. The causes of focus shifts are temperature, filter changes and mechanical movements in mirrors. I think SGP has those covered. If anything else is moving (say a focus mechanism is slipping) then it is better to fix the mechanical issue rather than use a blunderbuss approach to AF triggers?


I would like to see AF improvements as well, up until now I did not see any need, I have a Tak FSQ ands a GSO RC that work fast and reliable (USB3 camera helps). But recently I have run into something that I can’t explain with another Tak FSQ, it’s impossible to get a good V-curve, when I focus with Batinov, I get perfect round stars over the complete field … but SGP algorithm is thrown off for some reason. On next occasion I will try pinpoint again. External options would be welcome as it gives a lot of flexibility and avoids that some users start looking somewhere else to resolve their focusing issues …



I think that FocusLock is the only way in the near-term to achieve real-time focus. There have been a lot of good suggestions so far in this thread for different approaches to improve how SGP handles it. While I do have a ONAG / Focuslock combo on my RC, it does not work with my newt due to backfocus issues. So I am needing improvements also. At this point we really have to sit back and see what Jared and Ken do. I am hoping for a FocusMax integration since they already do an intergration with PemPro…so the plumbing has to be there to be fairly close to making it happen.


Just wanted to thank everyone for adding their thoughts, ideas and support for this! There are a lot of interesting ideas out there about how AF can be done. I have always been quite intrigued with the FocusLock approach…to use an optical aberration is pretty ingenious. Would be great if we could always focus that way…but perhaps there is another ingenious way to check the focus of each individual frame to help guide the next AF run? SGP does have the image history feature, perhaps that could be leveraged to enhance AF.

I am really looking forward to seeing what Jared and Ken can do here. I think this will be a huge benefit to SGP users, even if the only thing that can be done is to improve the robustness and reliability of the feature.