The AF routine does not fail the sequence when the HFR is out of spec, let’s say it calculated the intersection at HFR 1.14, if the final validation frame is HFR 2 the sequence should either fail or retry the AF routine (preferably user selectable).
Currently SGP shows an error box informing the user that the HFR is out of spec (very useful in a program which main goal is automation) and continues imaging out of focus.
This has been requested by many folks for several years, but no improvements to the autofocus routine have been implemented for a couple of years.
IMHO the deficiencies in the autofocus routine are the most serious shortcomings in what is otherwise the best image capture program on the market.
Just to be clear, when all the focus related factors are ok, the autofocus routine works spectacularly well, providing excellent, reproducible great focus. Those factors include: reasonable seeing and clear weather, mechanically sound focus equipment, not too large of a central obstruction for non-refractor scopes. Probably other factors I have missed.
However, there are the following serious problems with the autofocus routine:
Hopefully someday these issues will be addressed.
Even the most accurate system in the world can fail, what I’m asking is to allow the user to deal with it by actually failing. The funny bit is that SGP already detects some kind of error, for instance when HFR is out of spec with the calculated value, so we just need to take that trigger and give the user options.
Some of your points are completely valid ones, others I can’t subscribe because I do not meet the required conditions (long focal lengths).
The current algorithm used when “smart AF” is on is incapable of deal with clouds, it will get lost going bananas instead of failing. You really need to have a cloud watcher and the safety monitor working (not all of us are imaging on an observatory).
Here is an excellent example of problem #3 listed above. This was from last night using my Orion Optics AG12" Newtonian, which consistently gives me excellent V curves when there are good conditions.
Here are the three focus curves I got before I lost the remainder of the night’s imaging, due to temporary clouds present during the third focus.
Clearly, a rather perfect focus curve.
Another very good focus curve.
A terrible focus curve.
In spite of this curve being quite poor, the program selected 19275 as the best focus (because it was the lowest value) and moved to that position. Which was about 50 off the correct best focus position.
Only for this third focus did the program issue at error to the log:
[07/31/19 23:37:51.105][DEBUG] [Camera Thread] Warning! Auto focus validation frame HFR (3.55) might be out of tolerance with respect to expected HFR (3.48 or lower).
The really big problem with this happening is the focus can be so far out that the plate solve process for the next target may never succeed, and subsequent focus runs may never find ok focus. This has happened many times for me where I have lost the remainder of the night’s imaging due to a bad focus run. If the program made do change whatsoever in this case, my focus would stay very close to perfect because I use temperature compensation.
NOTE: this example is not nearly as bad as many I have experienced. I am presenting this one because it occurred last night.
I suggest the following fixes for this problem. The first should be really easy to implement, the second only slightly harder.
If the log warning message is triggered, just do one of the following, as specified by a new user setting:
a) totally ignore this focus run. This can work quite well if temperature compensation has been set.
b) rerun the focus sequence X times until a good focus run occurs.
Calculate a quality measure for the run. This could be as simple as the least square fit measure of the left and right sides of the V curve. The program is already calculating these lines. Just allow the user to set a minimum acceptable value for this quality measure. If the run fails, proceed with either a) or b) above.
The problem here is that the dev team seems to ignore anything related with AF, it’s not the first time people suggest improvements to the AF.
Are we asking for something dumb or unfeasible ?
@Jared doesn’t even answer to this.
Not much to say. Yes, it’s a known issue and something we need to address.
Thanks,
Jared
Thank you so much @Jared for confirming that you know this is a problem and that you need to address it. Could you please confirm that you will address it, and in the near future? Please provide an estimated timeline.
There are multiple threads on here where the auto focus has been discussed and we’ve committed to addressing it. We’re currently looking into a couple of avenues, one of which is FocusMax integration, the other is more of a revamping of our internal auto focus routine. I don’t have a timeline for either. But the FocusMax integration will likely come first as it is less complex than a revamping of our current auto focus.
Thanks,
Jared
That’s a downer… FocusMax is a commercial product so I couldn’t care less for its integration on SGP.
If you don’t have all the time required, maybe it could be more profitable overall to invest your time on the API (Yes I’m the one requesting this some months ago) and let third party people like us build SGP modules.
True, but we’ve had a LOT of requests for this.
The FocusMax support would end up doing that and we would make it generic as well so other 3rd party “auto focusers” could be implemented as well.
Thanks,
Jared
APIs to support third party products are always a great idea and welcome.
However:
Why would you even consider putting a higher priority on adding an API to support third party Auto Focus routines (not an easy enhancement), when you could with much less effort just add minor tweaks to the existing SGP focus routine to fix its problems? You talk about rewriting the focus routine to fix these issues. It does not need a rewrite, it just needs a few easy tweaks.
You already have the BEST AUTOFOCUS ROUTINE ON THE MARKET.
At least when conditions are good. You mention a lot of people have requested support for FocusMax. They are asking for FocusMax support because you have not fixed the remaining issues with the existing routine. If these were fixed, hardly any of your users would ask for FocusMax. If you do add support for FocusMax, I will not use it. I will continue to use the SGP routine, even if it does not get fixed. It is too good (most of the time) to waist time with an inferior product (which costs a lot of money). The problems with FocusMax are extensive, well covered by many users in many topics on this forum and other forums.
So, how to fix the remaining problems with SGP focus with simple to add minor enhancements:
Problems:
Lack of ability to ignore/rerun bad focus runs.
In my opinion this is the most serious deficiency, and one of the easiest to correct. The other focus routines have it including FM, why don’t we have it? So easy to implement. Just rerun the focus run if the quality of this run is poor. How to measure the quality? You are already calculating 99% of what you need by computing the least square fit lines on the left and right sides of the V. Just sum up the left and right side deviations and let the user specify a minimum required value. Done.
Serious problems with the routine for long FL scopes with the resulting small FOV. This provides far fewer stars, and particularly when a globular is in the center, may not work at all.
For folks with this hardware, this is likely their most serious problem with the current routine.
How to (maybe) fix this:
I am venturing to assert that the main culprit in this situation is the fact that SGP includes many multi-star clusters as single stars in its computation. This happens most frequently around globulars and dense star fields. One version of the star detection routine can, I think Ken has said, correctly eliminate these. However, that version is very CPU intensive, so in the interest of better performance, a version that allows lots of these to be included is now in place.
Multi-star groups considered to be a single star are a DISASTER for the focus routine.
Why? Between best focus and worst focus in a typical focus run, a typical single star will have HFR go from 2 to 6, a 300% increase in size. The typical multi-star star will have HFR go from 10 to 13, a 30% increase in size. This is a 10 to 1 difference in sensitivity.
I see two easy ways to fix this:
a) allow the user to choose the CPU intensive routine which will eliminate these multi-star clusters
b) In each focus image, only use 50 percent of the selected stars with the smallest HFR values. Since multi-star clusters have the largest HFR values, ignoring the 50% with the largest HFR values will eliminate most, if not all of the multi-star clusters, with virtually no negative repercussions. And so simple. This is obviously a crude hack to eliminate them, but why not? It will work amazingly well. With a little testing on problem images you will quickly find out if 50% works well or you need to use even fewer stars, like 30%. So what? It won’t affect the accuracy of the end result. Any number of stars from 3 or 4 up is plenty to get great results. FocusMax does ok with just 1.
Fix these three issues, and you will have, far and away, the best focus product on the market, UNDER ALL IMAGING CONDITIONS.
I agree 100% with jmacon above. I don’t want to use a third party Auto Focus routine I want to use the SGP routine with minor improvements. I have a C9.25 (SCT) running at native focal length and usually achieve good AF runs. Now and again I get an obviously bad curve, for whatever reason, (similar to jmacon’s 3rd curve in his second post). I also think some simple fail safe logic would stop this type of silly result being used in the active sequence. Doing a simple re-run from the last good position usually gives me a good result. Item 1 in jmacon’s previous post.
Fair enough @jmacon. We’ll reconsider the FocusMax support and see about adding some of your suggestions first.
Thanks,
Jared
Indeed, fixing the native process is the best but think about the future: Despite being a comercial product SGP is the work of only two people, allowing 3rd party to extend will bring it to another level.
Hi Jared,
I was wondering if there are any features in the works for avoiding the HFR calculation including star clusters. I had been getting typically OK focus routines, but now that I have a new camera and filter wheel that I’m trying to set my offsets and temp compensation for, I’m finding that the double/triple ‘stars’ are preventing me from getting as nice a curve as I used to get. I’m binning 2X2 and moving my minimum star size up/down, but I can’t seem to avoid the scenario where artificially large HFR numbers come into the overall calculation and throw things off. This is a screen shot of one of my better focus runs, with some of the star groupings shown.
Thanks,
Jeremy
A handful of groupings won’t have much effect on your auto focus. If you can provide some auto focus packs for bad runs we can take a look but this run looks pretty good to me.
Jared
Hi Jared,
Thanks for the response. I haven’t had any obviously ‘bad runs’ lately, since I’ve been tweaking things. My problem is sometimes that I have too many stars, but folks with an OAG probably have the opposite situation. So I think it would be a good thing for the algorithm to try and discard the star clusters in the spirit of continuous improvement. Maybe it’s as simple as giving us another manually entered parameter, like maximum star size?
In any case, as I’ve been working on bringing up my new QHY600 and filter wheel setup, I came up with a way to calibrate my focus position per filter, and accounting for temperature. For me, my aluminum OTA is quite sensitive to temperature, so essentially the temperature never really stabilizes; even 1 deg C is significant. I made an excel spreadsheet to account for all three variables; the filter, the focus position attained, and the temperature recorded immediately after each focus run. My procedure was to focus each filter in order, LRGB Ha OIII SII, then repeat that cycle 5 times, noting the focus position and temperature after each focus run. There was some small amount of time in between each focus run, but it took several hours to complete.
I made a simple linear fit to the data entered in the orange cells, using the LINEST function in Excel, so I could create an estimate for each filter’s focus position vs. temperature modeled as a straight line, y=mx+b. If you look at the graph, the linear behavior is apparent, at least over this small temperature range. The ‘y’ being focus position, ‘x’ being temperature, ‘m’ being the temperature coefficient (focus pos/deg C) and ‘b’ being the y-intercept. Once I have this simple model, I can plug in a temperature from which I can predict what the focus position would have been IF I had performed the focus at that same temperature for all the filters. In my case, I entered 20 degrees, so I could plug in those predicted focus position values into SGP, now with a level playing field, so to speak. The temperature coefficient was calculated by averaging the ‘m’ from each filter’s linear estimation, so it represents 35 runs worth of data. That number was then entered into SGP, so that it can actively move focus position with temperature for each sub frame, but still perform the autofocus routine at every time or temperature interval that I specify.
It occurred to me afterwards that this whole thing could potentially be automated. I know there is the Temperature Compensation Trainer in SGP, but maybe this method could be added/incorporated, so that a complete filter set offset and temperature coefficient could be done as a one-button operation, auto-populating the necessary fields in the focus setup window. I was guiding the entire time, so if the SNR dropped in PHD, maybe that could be used to flag, pause or reject a focus run?
I’d be happy to share the spreadsheet as well.
Thanks,
Jeremy
Hi Jeremy,
your approach of determining the focus position and temperature coefficient for different filters is essentially OK. And yes, there is a way to get and evaluate the data with less effort: simply use Mikael’s ‘SGP Auto Focus LogViewer’, see SGP AutoFocus LogViewer SGP AutoFocus LogViewer . The download URL is SGP AutoFocus LogViewer download | SourceForge.net .
This application extracts and evaluates the AF data in logfiles of SGP.
Bernd
Hi Bernd,
Thanks for the tip, that looks like a very useful utility for logging the focus data. I could probably make a place in my excel file to drop the text into, which could automatically update my data input cells.
Thanks,
Jeremy
SGP AF LogViewer also will perform the linear regression, providing the regression equations for all applied filters. Please click on ‘Position-Temp Graph’. The filter can be chosen with the drop down menu ‘Analyze filter’.
Bernd
