I’m all for a much more elaborate star detection code that measures fwhm and recognizes donuts and does all the right stuff. The more sophisticated and robust the better. But I’m also saying that the sgp routine works extremely well and essentially perfectly for me - but I need to babysit it. That is why I posted what I consider to be top class results from sct imaging - to show that using sgp for focusing and acquisition works extremely well as-is. The main problem for me isn’t the detection method - but the rejection method. And I think most any star detection algorithm would need a heuristic to recognize non-stars from true stars. And ideally it would reject saturated stars - etc.
SGP with a simple focuser on the primary works fantastically - but I need to check the result and redo it as needed.
But sure - fwhm measurement, donut measurement - all that stuff would be great. But the two issues preventing me from going automatic are the small star issue for focusing, and the solve/slew accuracy for centering.
Here’s an example of the kind of curve I can get focusing with SGP and robofocus on the primary focuser. Note that this is a second curve after already running autofocus - so the fact that this parabola is well centered indicates the previous focus was found accurately - and the curve - and focus point - are repeatable. The whole curve is taken close to focus so there are no donuts appearing at all. The curve is not v-shaped - which is more of a focusmax thing. Instead it is a nice parabola and it shows not only where focus is - but how much it will change if you move a few steps away from it.
So for people with secondary obstructions, I would aim for a curve like this instead of the very steep V curves I sometimes see. This does assume the focus was close originally and that may take some manual work to find it at the beginning of an imaging session - but once you start imaging it should work ok.
I am not using smart focus or anything - I found that it tended to go astray for various reasons.
I don’t always get curves like this - and the main problem is big jumps during the curve caused by small non-stars. I don’t have a lot of stars in the field because this is fairly long focus sct work at 0.57" per pixel with 8300 ccd.
As you can see the HFD function has selected a part of the doughnut and determined an HFD value that’s too small. I agree that the scope needs collimating. That’s a fragment of a 16 mbyte FITS image, I can post it if it helps. It’s taken at prime focus with an 8300 on a C11, I think that’s the same as Frank is using.
The story behind this is that I was collecting a series of several hundred 30 second images of a star (WASP-33) to see if the exoplanet transit could be detected. It could.
SGP was not involved, mostly because the scope only had a manual focuser.
Well - that image is pretty far out of focus - right? I think we all agree the current HFD code does not handle donuts well. But most of us in this thread, including the OP’s initial post, are referring specifically to what is needed for autofocus to happen reliably. And my point is that you can do autofocus well by staying close to focus and sampling near the parabola - so donuts don’t appear.
If you were doing photometry then I certainly would have aimed for better focus.
My images are with Edge11 at f/7 so possibly different from yours. And the stars across the field are very tight and uniform - but I use the central 40% or so for focus anyway. During the focus curve they just swell slightly on either side - but that gives excellent info for focus.
You could certainly have code that did a good job of modeling those star shapes - but I’m not sure what the real need is. It would help when focus curves are starting far from focus - but I would avoid that in the first place and let the autofocus routine find the exact focus.
This wasn’t far out of focus, just the normal drift after a few hours. It’s a 100% scale fragment of an 8300 image acquired at 1x1 binning. It’s a C11 at F/10 so slightly longer focus than you have.
Yes, this the sort of image that I would like to be able to use - and ones far more out of focus than this. I don’t think this should be excluded from a discussion of improving the autofocus process.
Having to start autofocus with an image that’s already practically in focus seems to me to miss the point. I would like to be able to start with an image that is grossly out of focus and have a process that will get to a good focus, all automatically and not needing babysitting. This is what I think is needed to get autofocus to happen reliably.
The reason I am trying to get focusing to work more robustly is so that it can be invoked periodically and automatically during the imaging session - in which case it would never get out of focus like that in the first place. I believe that is how people with refractors are currently operating with sgp all the time - and it’s one of the things sgp is designed to do. For some of them with little backlash it takes maybe 30 seconds or something - while for me with more backlash it takes 2-3 minutes. But that is still minor during a long imaging session - and I want the stars to drift no more than 0.2" or something - so nowhere near donut. The main thing is for it to happen reliably while I’m asleep.
In my case I just need to refocus about once per hour manually - but I would prefer to do it once per 40 minutes or so automatically - and know that each focus works well.
It doesn’t take very long with frame/focus to get the initial focus point very close manually - after which automatic focus should just do its thing and without donuts. So I don’t view the requirement to be close to focus at the start as a big deal. And there is “smart focus” in case it is far away - but I don’t use it.
For accurate photometry I would not want the fwhm wandering very much. At the same time, photometry is much less dependent on tight focus than high res imaging is - unless the object is really faint. But I still wouldn’t want the fwhm to change much.
Once again - sure - having sgp be as smart and functional as possible would be great, so that if I were arbitrarily far from focus it would figure it out and end up perfect. But as it is - it works almost perfectly for me - and others apparently - except for this thing with small stars messing up the curve.
I too typically run the autofocus 2x at the start of the night to get a nice U rather than a J curve. This is before a Sequence run. I should not really have to do that? That’s not the best goal of automation. If it does not do that then a full second method is needed. This has been already that committed too by our friendly developers.
I agree with Chris. The autofocus system needs to be robust enough to get good data on out of focus situations. On a technically level I think this is achievable with full frame HFR.
The decision is Jared and Ken’s on which takes less work. A second method or modification of this one. Their efforts are greatly appreciated either way.
If you get a J curve - did you try turning on smart focus? It should expand the range and make it a U curve I think.
Sure - better donut handling, fwhm’s and all measurements in arc-seconds - would be great. But even with that - bad star recognition is important - and can be improved now with the existing HFR code. With that - automation during the run would be possible for me - and improved for others. With additional effort, unattended focus at the start of the run and far from focus would also be possible.
I personally don’t mind having the focus be close at the start anyway. My sct is in a semi-permanent patio setup and it is already close when I start it up. And if it isn’t, it doesn’t take much manual work to get it close if needed - with bin 4x4 and short exposures.
I guess I’m separating what would be “nice” from what is an actual show-stopper for automated imaging in my case.
Another reason I would be grateful for FWHM measurement of a single bright star is that autofocus seems to me to be very hit and miss with the warm columns on my 8300 sensor. Providing a set of darks each within 2 seconds is probably reasonable but seems excessively restrictive. If I need to record fainter stars for focusing then I would need a new set of darks - yes I know they build up over time but are they really necessary ?
In my case, it is not a case of “would be nice”. Autofocus is a complete “show stopper” on my scope with the notable exception of Hyperstar setup where it works beautifully. It is essentially useless at 3910mm and only rarely works at 2737mm with the reducer. Even at perfect focus (as perfect as I can get with a Bahtinov mask), SGP will frequently not select any real stars at all regardless of the settings on the sliders for nebulosity rejection and number of stars, or exposure length. If it does select real stars, the number is always very small, and as soon as the autofocus routine takes it even very slightly out of focus (nowhere near enough to cause donuts) it fails to find real stars. My guess is that the stars are just too “big”, since I am fairly heavily oversampled at 0.32"/px. So for some of us, it is not a matter of making the routine better and more reliable, it is a matter of making it useable at all.
I never had a problem with it finding some stars - but I can believe the system is overall tuned for stars that are fairly small in terms of pixel width. I am at about 1950mm with 8300 ccd, which yields 0.57" per pixel. For autofocus I bin x2 resulting in about 1" per binned pixel - and I use 2s focus exposures with C filter. This will give a handful of good stars in most cases. I find best autofocus curves working with a patch of sky that has a number of perhaps 9-10 mag stars in the center - but most deep sky objects will have enough stars - but there will be false stars that throw off the curve.
Ken has already said that fwhm calc. is not in the near future and pinpoint is required - so I am proposing simpler fixes that would work for most of us - without drastically changing the core algorithm. I think that for your issue of stars that are “too big” the key is to assess star size based on the fundamental measure that is most important - and that is arc-seconds. That can be done with the existing HFD code and would remove this implicit dependence on focal length. If the user enters the expected range of star sizes in arc-seconds that should be counted, then the autofocus algorithm can do a more sensible accept/reject of star candidates independent of focal length and binning.
For your immediate needs I would make sure to bin for autofocus images - in your case perhaps x3 if possible.
I think another thing that would help is to allow the number of autofocus stars used to go much lower - so only the really good stars are counted. The current minimum AF sample size is 15 - and I think it should go all the way down to 1. For me, 5-10 is a good number. This is very different from wide field refractor imaging where 100 may be easy to get.
My camera won’t bin 3x3. The problems I am having are with 2x2 binning. I haven’t tried 4x4. Maybe I should.
I’m content knowing that Ken and Jared recognize that this is a problem and are working on it. I hope they come up with a solution that works for all scopes and focal lengths and encourage them to find a more universal solution. I have confidence that they will. I’m glad it works for you. It doesn’t work for me.
This matches the behavior I get with my AT6RC with Moonlight focuser. I have found that I need to be very close to focus before using the auto-focus routine. Otherwise, the autofocus routine will tend to move in the direction of larger and larger donuts. I also see “U” curves rather than perfect “V” curves when it works.
I had an auto-focus failure the other night. I started with the scope in good focus, but I think I had scheduled the sequence start time about 20 minutes before full darkness. I had set it up to start at a certain time because I was doing visual observation with another scope at the same time. After the sequence started I looked at the computer screen and realized it was hung up on the centering step. When I inspected the image it was trying to plate solve, I saw that it contained no visible stars! At first I thought I had a camera problem, but soon figured out the scope was way out of focus. I had not watched the auto-focus routine, but I concluded that it must have moved the scope way out of focus; while thinking it was in focus. I had to stop the sequence and do a manual re-focus before restarting the sequence with auto-focus turned off. After the sequence completed I realized my manual focus was not very good because when the image was significantly zoomed I was seeing very small donuts in the smaller stars.
One interesting thing I did this morning was install the latest 2.5.1.2 Beta on my laptop and load in a couple images to test the Star Size slider. One of the images was one with a good focus while the other was from the batch mentioned above. I adjusted the slider on both images to use around 20 stars for the HFR calculation. It was interesting that the HFR calculated for the image I knew was out of focus was about 50% greater than the value calculated for the in focus image. That seems to imply that the Beta version might have worked much better for my situation if I had been using it and had used the Star size selector to limit the number of selected stars. However, I know it would not have solved the “OPERATOR ERROR” of starting the sequence before the sky was fully dark! I may be able to test the 2.5.1.2 Beta version on Tuesday night if our weather cooperates.
