New Auto Focus Trigger based on Focus Metric Change

Sequence Generator
1

Monitoring the focus metric as a means to trigger auto focus is a moderately popular item requested here on the forum. Some version of SGPro 4 will see it come into beta. The work is largely done and we may decide to put it out with 4.1, but not if it jeopardizes the stability of the current beta. For the most part, 4.1 is “feature locked”. That said, this is a brain dump of how it works and also notes for me when it comes time to write up help files. Need to do this while it’s still at the front of my brain.

A statement about this implementation… it is pre-Beta right now. There will be errors in both thought and implementation. There are almost certainly some edge-case situations that will cause this process to break. Please don’t treat this like a release-ready feature. Use this thread for discussion.

How does it work?

Actuating the Trigger

It’s just another trigger like every other trigger. You can define the allowable change in your focus metric (maybe a percent, maybe a value at 1x1 binning) that is allowed without refocus and then define how many consecutive light frames must be outside of this bound to trigger auto focus. It’s unfortunately a rather simplistic approach to analyzing focus stability, but the truth of the matter is that the average length of an astro-exposure means we are going to be data starved for this measurement. We may only have between 1 and 3 data points before we have to make a decision so using regression or other techniques really isn’t that useful.

The current implementation requires that consecutive frames be above the metric’s change threshold before auto focus is triggered. This can help to compensate for reality and the fact that your HFR measurements from frame to frame may be a little bit jerky…

After Auto Focus

After a successful in-sequence auto focus, SGPro will assign a “baseline measurement”. Every auto focus in a SGPro sequence runs in the context of a Target Event (row on the sequencer). Because events contain properties that can dramatically alter the focus metric for any image, each sequence Event must have its own baseline marker. In other words, SGPro won’t calculate the difference in focus between the image at the end of one event and the beginning of another.

Because each event must have its own baseline, it is highly advisable to couple this trigger with the trigger that will run AF on every filter change. Filters are the most common “separator” of events and doing this will ensure that the new Sequence Event will have a good focus baseline measurement right away.

After Completion of the First Light Frame (after auto focus)

After auto focus for an event, SGPro will use the first focus metric value as the baseline marker for an event. This is the value to which all other measurements will be compared.

After Completion of Subsequent Light Frame

Assuming the Sequence Event has a valid baseline measurement associated with it, we can now measure new images and watch for meaningful change (as specified by you). See the rules above on actuation.

Before Starting the Next Light Frame

If auto focus needs to run, it will run. Afterward, this cycle will repeat.

Other

The event options window will now display its individual Image History along with the value it’s currently using as a baseline. It may be useful in establishing the percent deviation allowed or when troubleshooting, but otherwise, it’s just “interesting data”.

FAQ

With a single absolute value defined for the change threshold, how will it work between various binning modes?

We’ll see how this works and we may end up with a percentage value here, but right now SGPro will just scale this value as required (like it does for every other binning influenced value). The absolute value might be easier to measure since you can use values directly off the existing history charts.

Are Sequence Event baseline markers saved with the sequence or equipment profile?

No, these values are only ever associated with the current session and may not be meaningful between sessions. For instance, the baseline marker at the end of a session the night before may have a higher (less good) focus measurement that the one you can get at the beginning of the session the next night. This mismatch may create a scenario where it takes a long time for the focus measurement to pass the threshold. Your focus won’t be terrible, but it could be better.

Does it work with event rotation?

It does. Because every event has its own baseline measurement, the sequence can move on to the next event without overwriting any “common” baseline.

What about Narrow Band frames?

As long as they are sufficiently integrated and have sufficient data for measurement, they will not be any different from any other type of frame.

What if I use a Broadband Override Filter for my Narrowband Event?

This is also fine. The measurements captured during auto focus are not relevant to this trigger. This trigger will only compare measurements from images in the same event.

4 Likes
2

Looks like a great plan! One thing I would suggest.

I assume that the number of frames needed to exceed the threshold to trigger an autofocus will be user settable. In that case, rather than using the first frame after an autofocus as a baseline, it might make more sense to use the average of the number of frames set by the user.

Due to seeing, the focus metric can change from frame to frame, which is why the user can set the number of frames needed for a trigger … to avoid a single frame being an outlier. By the same token, using a single frame after an autofocus could be an outlier. So if the user chose 3 frame for the trigger, then take the average of the 3 frames after the autofocus and use that for a baseline.

-Dan

1 Like
3

That’s fair. I wonder if this would be sufficient in almost all cases or if there is need for a more black and white approach.

4

Ken,

Great idea.

One thing to consider is the trigger metric itself. SGP calculates both HFR and number of stars detected. A weighted function using both may be a more robust way to use the image metrics to trigger an autofocus run. The weighting factor could be a user parameter, defaulting to 100% HFR.

Revised comment:

I agree that doing an autofocus on a temperature change setting is the most viable and reliable method. I use it for my 9.25" SCT with great success. The HFR and star count metrics for each subframe are sensitive to atmospheric conditions that change through the night, especially when high, thin clouds pass over. Temperature change is seen as a slower “drift” as it gets colder as the night progresses.

I do have issues with autofocus performance on my SCT. Usually, autofocus runs well. However, there are some targets with few stars where the central obstruction creates donuts as the focus point is moved to generate the curve. SGP then chooses different stars to calculate the HFR, and it can cause great variation, so much so that a good curve cannot be created when trying to get an HFR range of 2 to 3x. The PSFs from the donuts cannot be used, and smaller stars that would be used with a refractor are ignored. The star count may be a more robust metric, perhaps combined in a simple weighting combination with HFR. Otherwise, some means to use the donuts would make autofocus more robust for OTAs with central obstructions.

Mark

5

Ken:

Seems like a lot of work for a relatively small benefit. I would suggest that temperature change is the #1 cause of needing to refocus during an imaging run. I would guess that equipment shifts during a meridian flip would probably be #2 and filter offsets would probably be #3.

Simply having a well made, temperature compensating focuser solves the temperature issue. With a properly calibrated focuser / imaging train, focusing adjustments are made continuously throughout the exposures. As an extra measure, auto focusing triggered by a temperature change is already available as a way to tweak the temperature compensation of your system.

Auto focusing on filter change as well as auto focusing after a meridian flip is already a part of SGPro.

Charlie

6

I actually agree with you here, but we have been berated for years for not having this and we finally caved. Some folks swear that temperature is insufficient for them. I don’t think I will ever use this particular trigger myself… temperature has always been sufficient for me. In terms of a lot of work, it really wasn’t. It took all of 6 hours. What I am most concerned about is the possibility of having to support it. We’ll see how it goes.

7

Ken,

Revised comment:

I agree that doing an autofocus on a temperature change setting is the most viable and reliable method. I use it for my 9.25" SCT with great success. The HFR and star count metrics for each subframe are sensitive to atmospheric conditions that change through the night, especially when high, thin clouds pass over. Temperature change is seen as a slower “drift” as it gets colder as the night progresses.

I do have issues with autofocus performance on my SCT. Usually, autofocus runs well. However, there are some targets with few stars where the central obstruction creates donuts as the focus point is moved to generate the curve. SGP then chooses different stars to calculate the HFR, and it can cause great variation, so much so that a good curve cannot be created when trying to get an HFR range of 2 to 3x. The PSFs from the donuts cannot be used, and smaller stars that would be used with a refractor are ignored. The star count may be a more robust metric, perhaps combined in a simple weighting combination with HFR. Otherwise, some means to use the donuts would make autofocus more robust for OTAs with central obstructions.

Mark

1 Like
8

Hi Mark,
That is interesting that you sometimes have this problem. I have not had this happen, and I often use an Edge 9.25 with a Canon 6D. I’m using 9 data points and a step size of 70, and SGP gives me very good focus. My temperature comp in SGP is set at -4 steps/degree.
Dean

9

I think the combination of star count and HFR is probably more robust than HFR on its own. Other capture apps have struggled using HFR as a metric, for example, having worked out the right threshold it still might repeatedly spend time doing AF, due to tracking errors or worsening seeing.

Temperature alone is not a guarantee - as the sensors typically react to changes considerably more quickly than lumps of glass and aluminium. This is also about having an insurance policy. AF can go wrong and you don’t want to be locked into a wrong AF result for most of the night. I find the existing SGP controls, in combination, work effectively. I have 1C temp change, AF after filter change (or filter offset) and AF after 90 minutes or resume. In that way, if I get caught out, the damage is limited to a few subs.

10

In what way do you mean? Like weighting the HFR based on start count?

11

I have noticed a trend that worsening HFR is often accompanied with a fall in star count at the same time. If they are already being calculated, combining them may improve robustness.

Everyone’s take and experience is different. Trouble is, when you throw out a lifebuoy, you want it to float.