As well as autofocus works for most systems, it has some challenges for long FL systems. This is true particularly during galaxy season - with galaxies having bright features. I have been struggling for several nights now to image M82 at 3910mm FL. For nearly every run, it starts out just fine, but once the central part of the galaxy comes closer to focus, the AF routine finds these features and thinks they’re stars. Inevitably, the HFR assigned by SGP is substantially greater than that for actual stars. This gets complicated by the sparse star background where there aren’t enough actual stars to dilute the contribution from the galaxy parts. I see two potential solutions to this. First, users could define an “exclusion area” for which SGP will not try to find stars. A more elegant approach, IMO, and one that would probably improve AF overall would be to allow outlier rejection. This could be a user-selectable number of sigma units and should be relatively easy to implement (in theory).
For now, I have to turn off smart focus since the center point is frequently higher in HFR than the two neighboring points, causing the AF routine to think something went wrong and invoke smart focus. Often, this causes the focus to get hopelessly lost. This means that almost every AF run results in a bad fit and SGP resorts to a weighted average of the lowest HFR points. This is not good, and I typically have to reject 30 to 40% of the subs for bad focus as a result. At f/11, every sub counts. No tweaking of settings results on any improvement. Outlier rejection would allow me to reject the artificially high HFR galaxy parts and result in successful focus.
Galaxies being deteced as stars during autofocus is a problem with all systems it seems, it does of course not create bad problems for faster large FOV system thou.
Here’s M81 and M82 being detected as a star with a FSQ130 @ f/3.5
M82 has a HFR several times larger than the average star so it should be easy to reject it?
There’s the rub. If you look at M82 above and imagine it occupying about a full 3/4 of the frame, you can see that there are very few actual stars in frame. 3910mm plus a 4/3 sensor means a very tiny FOV. Few stars - in and of itself - is not a problem. AF works very well even with just a handful of stars. But when you have, say, 8 stars at an HFR of 3, and one galaxy portion with an HFR of 12, the average will be drastically skewed high.
I’ll run some focus packs tonight, skies permitting.
I have made a suggestion in the past that I think would:
a) fix your issue
b) give more reliable auto-focus results in all scenarios
c) be very simple for the developers to implement
The suggestion is to simply reject from consideration all stars that have an HFR greater than say 8.
Effectively what this does is eliminate (mostly) the multiple star groupings that the current algorithm thinks are a single star, with a resulting very large HFR contribution. Exactly what is happening in your case.
In images with a high density of stars, such as any image in the milky way, there are a very large percentage of multiple star groupings. Including any multiple star group dilutes the accuracy of the overall HFR calculation because the HFR of the multi star group changes very little over a wide range of focus.
In very detailed studies I have done in the past of my focus images, the HFR values of a single star track very closely the combined HFR and all 200 stars currently being used, so having only a few stars in the collection will yield excellent results.
Unfortunately, this is not true if this “single star” is actually 2 or more stars, which may well be the case within a galaxy. As detailed in my post above, the HFR of several stars considered by the algorithm as a single star is not very sensitive to a wide range of focus positions, as a true single star would be.
This is completely unworkable for oversampled imaging trains. My QHY163M at 3910mm will have HFRs greater than 5 or 6 when in perfect focus. An arbitrary upper limit of 8 would make AF impossible. In fact, any arbitrary rejection threshold would be just that - arbitrary - and would not be effective over a wide range of imaging trains. A statistical outlier rejection would.
Then perhaps a more workable solution is to set the threshold at the halfway point (or some other percentage) of the HFR values. This would be completely dynamic for each unique image train.
The details at the galaxy core are picked up and mess the whole focus calculations. There are only 3 stars available in this field but you will notice that SGP is working on 8 stars. I have 2-3 nights’ data with bad focus and I realized this when I started stacking for test purposes.
For star fields such as that you’ll probably have to increase the exposure
to attempt to get more stars or move off target to focus. Unfortunately if
there isn’t much data we won’t be able to automate focus. Maybe we can see
about defaulting into a single star mode in cases like this.
Implementing my suggestion might be the equivalent of single star mode. Certainly would eliminate the bad multi-star selections. What is your problem with this. Seems so simple. Just try it.
How about just letting the user select a subframe for autofocus that excludes the offending stars or objects?Seems simpler and would also be great for cameras with large chips and slow downloads. One could even set that up for multiple objects with a little more effort but that would be optional.
Not great if one has a less than fairly flat field but one assumes that this should not be an issue with decent optics and it’s use would be optional anyway.
I’ve given the “exclusion zone” concept some thought and don’t think it is the best approach. In my case, anyway, the problem isn’t just some other feature being identified as a star and getting an incorrect HFR. In many cases, on the more out-of-focus AF images, SGP picks up just a “hot spot” part of an out-of-focus star, leading to an artificially low HFR. This is common for dimmer stars. So a robust outlier rejection approach would reject both high and low HFR outliers. The simplest and most robust approach that I can think of is statistical rejection. It’s very simple - calculate the mean and standard deviation for the HFRs and let the user select how many standard deviations (sigmas) from the mean he wants to reject. This will work very well on either side of the mean, does not require the user to take the time to select a subframe for an exclusion area, is essentially infinitely tweakable and is computationally inexpensive and fast. Coding should be simple as well. I’ve done it numerous times. In fact, part of the coding is already done since SGP already calculates the mean HFR.
Jared, I have tried longer exposure times as well but that is not helping either for some reason. SGP refuses to recognize some stars, maybe due to low contrast etc… for example, in the NGC4490 frame I have shared above, there are at least 4 more stars that SGP can use but for some reason these are not recognized as stars. Today is cloudy unfortunately but I will give this another chance with longer exposures.
Moving to another region for focusing is not an option here either. Platesolve 2 and Astrometry.net cannot solve these frames with so few stars and I’m centering the objects manualy, which takes quite a long time ( I’m operating this system remotely. The sluggish internet connection makes nudging the scope precisely a very difficult task).
Meanwhile, I would be more than happy working in Single star mode. [Edit] Being able to select a subframe for focusing, as CCDMan suggested above, would be a much better option though… if it is doable of course…otherwise, single star should yield much better results than the current situation in extreme cases like mine and spokeshave’s.
By the way, because this set up is way too oversampled, I’m using 4x4 binning for focusing and platesolving. Do you think this can contribute to the problem ? Working at 3910mm is a real challenge!
Outlier rejection may not work in my case here as the outliers have the majority and they will dictate what the norm is… Out of 8 reference points only 3 are stars…
Hmm, sounds like this may be what I was experiencing last night, so rather than starting a new thread, I’ll post here. I FINALLY got around to writing/completing my ASCOM driver for my Arduino based focus motor and was all excited to have SGP auto focus, but every time I ran the sequence it took off to never-never land and went from being in good focus to getting donuts on my C11, and it just kept going further and further off focus. I wasn’t paying close attention to what it was doing initially, but after resetting and watching it a few times, I came to the conclusion that it was picking different stars for the calculation and as it got closer to focus, the brightest (presumably the core of M82, but I was using too short of an exposure to know for sure) would suddenly start being recognized as a star and it would stop, plot a line, and go outside the specified search region. Of course there it wouldn’t detect anything as a star and just kept getting zeros and moving further afield. That in and of itself is disturbing since from night to night in a Texas winter the temperature variation can cause focus to range much further than this was searching. If SGP can’t recognize defocused stars and figure out where it needs to go then that’s pretty disappointing. I’ll eventually add temperature sensing and attempt to use that, but this isn’t a very auspicious start!
I’m running at the default, so it’s enabled. I was wondering what that does (didn’t have time to research it) but assumed I wanted my software to be smart! I’ll give that a try this evening.
I’ll give that a try this evening.