Hello, John.

I agree with you that Altitude is probably not a good trigger to consider because it will interfere with other triggers and won't add much.

Returning to the HFR trigger: I already knew, but I pondered further, that the actual HFR considered by Ekos to trigger an autofocus run is not the HFR measured from the last image acquired, but a value obtained from a run of the focuser app, which is usually a very short acquisition of a few seconds if not less. Now, while the HFR of a lengthy acquisition (say, 10 to 300 seconds) averages seeing, the focuser's short acquisitions (1 second for Lum in my instance) might provide radically different outcomes. In my experience, this leads to a great dependence on seeing conditions, which, if unstable, causes autofocus to run more frequently than necessary.

Aside from the fact that the algorithm, or at least the software UI, should be more explicit about whether the HFR is constant or changed each time, wouldn't it be more rational to utilize the HFR from the most recent acquired image in a sequence as the HFR value considered?

Best wishes, Massimo

Hi Massimo,

So the HFR check could be done against the sub. Alfred also mentioned this at the top of this thread. Initially this seems like a good idea because, after all, subs are what we care about and focus frames are just a way to get there.

However, there are issues, with this...
1. Whether or not you are in focus is the job of Focus, not Capture. And Focus uses focus frames to determine whether you are in focus. The reference of being "in focus" is the output from a successful Autofocus of the focuser position and HFR.
2. As you say it makes no sense to compare a subframe with a focus frame (for many reasons, the exposure and gain may be different, the filter may be different, etc etc).
3. So the reference HFR can only sensibly be compared with another focus frame taken under similar conditions as were used for Autofocus (exposure, gain, filter, etc).
4. You could, theoretically, run Autofocus then take the first sub of the sequence job, then analyse the sub and get the HFR. Because its the first sub after Autofocus, you should still be in focus - this would be the assumption. This could then be used as the reference and subsequent subframe HFRs compared to it. But its now dependent on guiding, etc. If guiding was off on the first frame your trigger HFR will be off.

Ultimately, there are many things that affect the HFR in a sub that have nothing to do with focus. So I think the existing method of using focus frames rather than subs should be superior (but haven't tried it).

Hello, John.

You nailed it. Probably, the existing implementation of the HFR focus algorithm is the most logical option.

I feel that all boils down to writing a better tooltip for the "Save sequence HFR value to file" (post 98055), similar to the previously mentioned "fixed Y or updated Y". The way it is defined presently is a little ambiguous. Also, double-check that the algorithm is working as planned. I have the impression that even when I unchecked the "Save sequence HFR value to file" option, the value was not updated (I know this because in some sequences I tried putting a value of 0.0 as the limiting HFR value, which should have been updated with the result of the first autofocus run, but didn't change, resulting in an autofocus run before each subs...)

Perhaps incorporate an easy mechanism to analyze the value of HFR determined by the in-sequence HFR Focus checks. Nowadays, I believe the only way to check for it is to browse through the focuser log... or to control the updated value in the "Focus if HFR value > than" field, both of which are quite inconvenient. What about adding the parameters of these "focuser acquisition subs" to the analysis module?!? Too much overhead???

<em>1. Whether or not you are in focus is the job of Focus, not Capture. And Focus uses focus frames to determine whether you are in focus. The reference of being "in focus" is the output from a successful Autofocus of the focuser position and HFR.</em>

True, but this is the programmer's point of view. The user, however, sees how HFR develops and how - in some cases - focus reacts inappropriately.

<em>2. As you say it makes no sense to compare a subframe with a focus frame (for many reasons, the exposure and gain may be different, the filter may be different, etc etc).</em>

Totally agree.

<em>4. You could, theoretically, run Autofocus then take the first sub of the sequence job, then analyse the sub and get the HFR. Because its the first sub after Autofocus, you should still be in focus - this would be the assumption. This could then be used as the reference and subsequent subframe HFRs compared to it. But its now dependent on guiding, etc. If guiding was off on the first frame your trigger HFR will be off.</em>

Absolutely. The initial focus run makes sure we start the first sub at the best possible focus position. Ekos should keep track of focus run HFR strictly separated from sub HFR. The sub HFR is the result of all imperfections combined: Focus, seeing, refraction, guiding, wind, etc. In order to eliminate seeing, guiding and wind from the list, focus run should use short exposures. It doesn't make much sense to take 3s focus frames when your telescope can deliver 0.8" resolution but seeing is 2.5". With regard to guiding errors ruining the reference sub, this should be taken care of by the "abort if guide deviation >" feature in "Guide and Focus limits".

The procedure I envisage goes something like this:

1. Initial focus run (short exposures), remember "reference focus HFR".
2. Take the 1st sub and remember "reference sub HFR".
3. Take the 2nd/next sub and compare 2nd sub HFR vs. reference sub HFR.
3a. If the 2nd sub HFR is below the threshold, continue with the next sub.
3b. If the 2nd sub HFR is worse than the reference sub HFR by a certain margin, it means at least one of the imperfections has deteriorated, POSSIBLY focus has drifted. Whether focus has drifted or something else has happened, has to be determined by taking a short focus exposure. Its HFR should be compared vs. the "reference focus HFR".
3ba. If the current focus HFR is within a certain threshold compared to the "reference focus HFR", continue with the next sub. (Focus position is still ok, the deterioration of sub HFR must have been caused by something else, running a re-focus at this point won't yield any improvement)
3bb. If the current focus HFR is worse than the reference focus HFR by a certain margin, start a full re-focus run. Remember the re-focus run HFR as new "reference focus HFR".
4. Repeat at 2. but remember current sub HFR as the new "reference sub HFR".

Advantages: Spend time only on what is really necessary.
Make reasonable use of sub HFR to prevent unnecessary focus checks and re-focus runs.
Use quick focus checks to prevent unnecessary re-focus runs.
Catch focus drift at the earliest time possible (= when a sub is received), unlike fixed time intervals.

An advanced implementation of focus check could compensate for refraction effects depending on the object's altitude.
Instead of taking just one short exposure for focus check, the median of a few short exposures could be used to make things more reliable. Determining the median of 3 short exposures for focus check should take less than 5 seconds.

<em>Ultimately, there are many things that affect the HFR in a sub that have nothing to do with focus. So I think the existing method of using focus frames rather than subs should be superior (but haven't tried it).</em>

That's being dealt with by short exposure focus checks only if sub HFR suggests so. The short exposure focus check should eliminate seeing, wind and guiding errors from the equation. The effect of refraction on HFR can be computed and compensated for.

Thanks very much for the feedback!

There are very good suggestions in here that I need to think about some more.

At the moment Analyze typically gets events that result in "something happening":, e.g. Autofocus. None of the periodic refocus criteria (time, tenperature, etc) generate events to Analyze. Maybe they should? I'll have a think.

Thanks for the algo Alfred. I'll have a think about it. Its quite a bit more complex than the current setup.

I've currenty made some changes which I'm testing, to...
1. Have a mechanism to use Last Autofocus + tolerance% to trigger an Autofocus.
2. Have a fixed HFR value that is only changed by the user.
3. Have an option for the existing "median measure" that works as today. If nobody comes forward as a user I'll decommission this in future but obviously don't want to take away something that is useful to someone.

This is more complex than it sounds as the existing code has a number of bugs which I'm also trying to fix. Such as, if you run HFR Check with time based focusing, the time base doesn't work. Similar story for HFR Check with Autofocus after Meridian Flip.

Hi John,

I use the "median measure," but I don't see any evident effect... I won't miss it much.

I agree that adding too much to the analyze panel is detrimental... perhaps include a keyword in the subs .fit files that reports the autofocus check's HFR value?!? No idea how much trouble is that.

Alfred stated something that struck a chord with me: "Instead of taking just one short exposure for focus check, the median of a few short exposures could be used to make things more reliable. Determining the median of 3 short exposures for focus check should take less than 5 seconds."
This, in my opinion, may be a significant optimization. The HFR focus subs are nearly in the "lucky imaging" realm: exposures are brief, I used 0.5 seconds or less for Lum, thus the observed "single point" HFR is significantly dispersed. This doesn't matter much for an autofocus run that involves fitting an entire V curve made up of many data points; however, depending on a single sub to estimate the HFR value of future picture subs...?!? If you loop focus subs, you will notice the HFR constantly leaping in value up and down owing to air turbulence; if each up jump initiates an autofocus run, it is simple to understand how the majority of the autofocus runs will be initiated when there is no actual necessity. Presently only the tolerance value (if it is actually working) prevents this. That, I believe, is one of the key reasons I see so many focus runs being conducted when they are not needed.

Why not include something similar to the parameter recently added to the "abort if guide deviation >" function that allows to specify the number of excursions beyond the limit? A simple parameter allowing to select the number of focus subs averaged to determine the limit HFR value... doable?

My two cents.


my two cents.

Best
Massimo

There is a parameter in Focus->Process called "Average Over". It defaults to 1 frame but you can set it to whatever you like, say 3, and it will take 3 frames at each datapoint during focus and each HFR Check and calculate a robust average (median for 3, sigma clipped value > 3).

This is existing functionality so you can give it a go now.

I have this set to 3 as my default but didn't know this setting was used by the focus check, too. Thanks an awful lot for your hard work, it's much appreciated!

Yes, I used that option a few times. However, this means that every autofocus run takes twice or three times longer... To improve the statistics of the focus checks, I suggest making the option implementable individually for the focus checks subs independently from the global autofocus option...

I think what Massimo poposes makes a lot of sense. BTW, if I recall correctly, even the "capture image" button



will trigger 3 images instead of 1 when "average over" is set to 3 frames.

Yes, Alfred, I employed that feature when my seeing was fubar or when I was in a hurry and didn't give the scope time to acclimatate.

By the way I was thinking whether averaging a few focus checks and using the standard deviation of the HFR may provide an estimate of sky quality... but I digress.

I just re-read what was said and want to make clear that what I thought was proposed is separating the "average over" feature. In other words: Have separate "average over" settings for refocus runs and focus checks. This way we could have reliable focus checks without prolonging focus runs by the same factor.