Here is a link to an AF_Pack that was ok with 2.5.1.5:
https://dl.dropboxusercontent.com/u/37743511/SGPData/AFPack_25.zip
Here is a link to a log of one of last night’s 2.5.1.6 AF runs that did not find stars:
https://dl.dropboxusercontent.com/u/37743511/SGPData/sg_logfile_20160424183555.txt
Frank
Ken:
Testing 2.5.1.6 with frames from the AF packs I created last Friday night shows this release still has an initialization error with the min star size parameter. This sequence shows it every time on my PC:
Toggling the star icon multiple times keeps finding 300 stars. Then click min star size spin control and change it to 11 and the star count immediately drops to a dozen:
Click min star size control and change it back to 12 and the count drops further:
So, it appears the initial click of the star icon to calculate the HFR of the loaded image does not read the min star count value from the loaded SGP file. In fact, this action repeats when a new image is loaded so the action of loading an image is setting the min star size value (internally) to either 0 or 1 and a click of the spin control is needed to update the min star size value.
Charlie
Do you have a multi-target sequence in your tests? This is kind of broken right now because each target has its own min star size. We still haven’t decided if targets get their own min pixel size or if they will share one from the sequence. Until we decide this, we can’t fix this issue… just consider it a beta artifact for now.
I had quite good success with 2.5.1.6 last night. AFPacks are in dropbox:
https://www.dropbox.com/sh/e4hlnjq87jhh8o4/AACab2ouH3GjHoLwvrWTWbGBa?dl=0
I don’t currently use multi target sequences but considering how much variation there is in star field densities from target to target, it seems to me like the min star size would need to be target specific.
Having said that, I realize there are users who want to set up a multi target sequence and then just turn it loose and have SGP do everything without further intervention. I have always referred to this as robotic imaging and it is very different than just basic remote imaging where the user is still managing most aspects of the imaging session.
I appreciate the appeal that robotic imaging has for many people but it requires a really complex application to support it. Perhaps the Equipment Profile could have a default min star size value that gets used when a target is created but allow it to be tweaked on a target by target basis.
Charlie
Possibly… we will treat this in an empirical manner I suppose. Right now my thought is that, regardless of target, there is a minimum star size that you want to detect for a CCD / Scope combination… meaning for most targets, this setting would be static and target agnostic. That said, there will be special cases where this needs to change to meet the needs of a target (especially in data poor regions). So… in line with your last comment, we will probably head down this route prior to release.
Very hard to beat v - curves like this. The new routine works fantastic with my 6D and Edge 9.25 with Feather Touch/Micro Touch at 2350mm. My step size used to be 90, because anything bigger would put me into donut land and it would get very unreliable. I can now go deep into donuts, and it just doesn’t seem to care, so I have increased the step size to 120. This gives me nice reliable v - curves with steep sides as you see here. Being able to play in donut land saves the hassle of having to get nearly perfect focus with a Bahtinov mask at the start of the night. This is no longer needed, and SGP finds focus even from a long ways out now. Great job guys!
Dean
OK - I just tried 2.5.1.7 - and it did ok with the default value of 4 pixels for min star size - so I set it to 2 and it found no stars. Then I set it to 3 and it worked ok.
What exactly does this min star size thing do? I had proposed this some time ago as a way to reject stars that were nonsensically small. But when I set it to 2, I get no stars at all. The higher I set it - the more stars I get. Are you sure this isn’t setting the maximum star size used for the HFR calculation?
Frank
Hello,
always the same behavior with SGP 2.5.1.7, star circle are not perfectly centered (nearby dead pixels detected as star?) and nearby stars give some big HFR, ( are these high values filtered before the mean HFR is calculated?
Thanks.
Pascal
Frank,
I noticed something similar. For example if I change star size from 4 to 5, nothing happens. Then to 6, it would show more stars, then 7, less stars and even less stars for 8. It’s possible double stars were included at certain star size setting that causes confusion.
Have you tried increasing star size up to 10? Did it eventually make more sense?
Maybe upload your sample image so Ken/Jared could examine it.
Peter
EDIT: I have not imaged since last October due to clouds, I measured HFR on a 7 minute sub (unbinned 1x1) instead of typical 7 second binned 2x2.
It sounds like you have set this value way too low. This value sets a range (in order to minimize user settings). It does set the minimum value… give me that much credit, but to your point, it also sets the maximum limit to 1 order of magnitude larger than the minimum. If you are not detecting ANY stars with a 1x1 min star size of 2, it probably means that you have a binning of 2x2 , in which case the min star size is 1 and the max is 10. You likely have no stars with a diameter smaller than 10 px. I have tried other methods like rejection based on standard deviation, but this falls apart when the sample sizes grow too small. The reason we set a max size is because the new detection algorithms are blob / shape based and we want to avoid detection of very strong nebulae signals and globular clusters as a single object.
That’s fine - that explains it. Now that I know how it works I can work with that.
In the previous versions before the min star size feature - I would often get stars with < 1 HFR. Yes I am binned x2 but my seeing is good and my HFR can go below 1 in binned mode. So setting the min value to 2, the very minimum allowed, didn’t seem unreasonable. I think my HFR focus curves do go below 1 at times.
So I can tune things empirically and it does seem to work - but it would help to clarify exactly how this works. It sounds like if you set a min value of 2, it will specify a range of stars approx 2-20 in unbinned pixel size. Is that 2 number a hard limit?
But I’m still unclear on the factor of 2 - since you are measuring HFR, but you also talk about “size”. Is that size value also a radius - or is it a diameter - or something else?
I guess something else going on is that your code for calculating HFR is different - and you may not even be finding false tiny stars any more. I’m not sure. Either way - it is definitely working better and very robust through unattended focus sessions with sct.
A key indication of better behavior is when I look at the star size measurements across the screen. They are much more consistent now and independent of intensity - whereas before different stars would have different HFR’s - and mixed in were stars with 0.3 HFR or something. So I think many things have improved together to make it more robust.
Thanks,
Frank
I think the key reason that many users who commented here that the routine worked perfectly for them is:
I can do both of the above and get excellent results on my refractor, and reasonable results on my RC12.
The big problem with trying to tune the Mininum Star Size with the current routine is it needs small values (2 to 6) to work well if the starting focus is close to good focus, and it needs large values (say 10 to 14) if the start is way off focus.
Clearly the actual value ranges are likely to be different for different people, and perhaps even different for different targets, which is a really big problem. And perhaps equally problematic is the optimum (or even usable) Minimum Star Size is likely to be highly dependent on how far out of focus the initial position is.
I must emphasize here that all these results are using my Stellarvue 102mm refractor which of course gives beautiful V curves and never gets into donut land like my RC and other obstructed scopes, so long as the range is not too large.
However, out of focus refactors also produce very large stars which produce the same difficulties for the AF routine as do obstructed scopes.
======AT PERFECT FOCUS======= (arrived at using step = 50, MinStarSize = 2)
This table shows star count and HRF for Mininum Star Sizes from 2 through 14.
This image is at the perfect focus position established with the nice prior run (above) with good V curve, using step=50, so the stars never got big enough to enter the problem zone.
Min Star
Size____SCnt__HFR
_2…300___1.80
_4…300___1.88
_6…300___1.90
_8…108___2.32
10…_29___2.93
12…_13___3.64
14…__3___5.89
These results are partly what one would expect. Increasing the min star size would progressively eliminate the smaller stars, and this image contains thousands of small stars with an image FOV of 1.8 degrees. The true HFR for this image is around 1.8 to 1.9. I have not noticed any bogus stars from hot pixels, although that is probably why going from 2 to 4 increases the HFR from 1.80 to 1.88. Certainly an insignificant hot pixel issue. This is why on most of my runs I have just used min star size of 2, since I never see a significant number of bogus stars.
The real problem this points out is that the most accurate results come from using SMALL star sizes when close to focus, but as the following table shows, the current AF routine progressively quits finding stars the further out of focus you get.
Therefore, to get any usable results when way out of focus, you must use LARGE minimum star sizes.
The requirements for getting good results both in focus and out of focus are therefore incompatible.
Conclusions for my personal setup:
Intuitively it makes sense that you would always use the smallest Minimum Star Size that does not make hot pixels into stars. The reason larger Minimum Star Sizes work for some configurations with the current routine is that it requires larger values to find any stars when fairly out of focus.
The following table shows results using 2.6.1.6 on my last AFPack_10 which ended way out of focus, having started from the prior position of perfect focus, shown above.
The step size was 80, which gets a lot more out of focus that the above good run with step size 50.
======FOLLOWING BAD RUN======= (my results for Minimum Star Size = 2, using step = 80)
Starting from the prior position of perfect focus.
Note these actual results when I ran this at MinStarSize=2 are very close to results in following table using MinStarSize=6.
This table shows the results for the final 14 images of the series for both MinStarSize = 6 and 12.
There were 4 images in the inital phase of the run that were closest to the starting perfect focus position, after which it erroneously concluded that better focus was to be found further out.
________-------6-------…------12------- <---- Minimum Star Size
Img#____SCnt__HFR…SCnt__HFR
0…__0______0…_10___16.79
_1…__0______0…12___14.83
2…1.50…_11___15.24
_3…__0______0…14___13.45
4…1.71…_15___13.44
_5…__3___3.93…_20___11.72
_6…_27___9.87…_29___10.00
_7…_28___9.73…_30____9.86
_8…_24___7.90…_45____8.30
_9…_86___6.44…_86____6.47
10…158___4.74…140____4.93
11…300___3.16…_57____4.17
12…300___2.15…_17____3.76
13…300___1.80…__9____4.25
This clearly demostrates that for out of focus images, small minimum star sizes are a complete bust, finding only 3 stars at MinStarSize = 5.
And as Ken pointed out, using MinStarSize = 12 give the following very good curve:
My recommedations for how to fix this:
In the next post I will present some additional ideas on how this might be accomplished. For now I have to get on to other stuff, having spent 3 hours putting all this together. (OK, so I’m slow, comes with age)
My feeling is that having Ken hard code the min star size or limit it to some maximum or minimum is going to make the AF routines stop working for some / lots of people. In my brief testing, I achieved good results with a min star size of 10. Leave it settable on a target by target basis and equipment by equipment basis. It will take very little experimenting for a user to figure out a good value for their environment.
One example of something I think the user will need to carefully tweak is the focuser step size used between data points. You are using step sizes of 80 or less. My focuser uses 1500 as the step size. I was initially testing with a step size of 300 and was not seeing good results. Then I made a huge change to 1000 and everything came to life. Moving to 1500 improved things a little more. Everyone will have to experiment with these values but I do think SGP will need to provide some guidance as to how to chose some starting points and how to debug the results.
As the min star size gets bigger, the calculated HFR will get bigger. It seems to me that we don’t care about the absolute HFR reading. The goal for the AF routine is to minimize it. Whether that minimum value is 3.5 or 0.5 doesn’t really matter and will be different for different cameras and scopes since I believe the HFR is pixels and not arc seconds.
Also, I don’t think SGP has changed its position that its AF routine is used to tweak / maintain a good focus; not perform raw focusing. So, having an image with a very large initial HFR is outside the scope of the code.
It appears that only a small number of us are testing the beta releases or at least making reports. Let’s get a lot more experience with it before asking Ken and Jared to make even more changes. Unfortunately my observatory is not predicted to have a clear night for at least a week 
Charlie
2.5.1.6 Worked well for me over two nights. Very good v curves with rounded bottoms. I was using a 10" RC f/8 running with AP .75x focal reducer at approximately 1700mm and f/7. Used HFR method. 10 tries at 30 steps. Robofocus 3.1 with Starlight Instruments FTF 3015B. Selection of stars was good. I believe the setting was 4 as the minimum star size.
Keep in mind that the min star size has nothing to do with HFR, it is a filter on the star detection phase of AF and is applied prior to HFR. It is also based on the star’s diameter right now.
Yes, 2 is a hard limit. Any star occupying a diameter of less than 2 pixels on a 1x1 image is likely noise… If it’s not we can’t measure it anyhow.
Thanks for the feedback. We are not 100% certain what the release will look like, but seeing where folks are confused (with no help file) is usually a good indicator of areas to revisit.
That may be true, but the intent of 2.5.1 is to refactor the star detection elements of AF… not to rewrite all of AF.
I have run a lot of your AF packs. While I see what you are saying, I don’t see this as an issue for your data.
You have written a lot of stuff here… I don’t have time to read it all right now, apologies if I’m skipping stuff.
Thanks for the feedback.
Charlie, I agree with almost all you say here.
Clearly we don’t want, and Ken won’t release a new version of the AF routine that would break it for large numbers of users.
This I don’t think is true. From the very beginning of the AF rewrite, one primary goal was to successfully do AF when obstructed scopes are well into donut range, which is way out of focus. What I have discovered is that refractors that are comparably out of focus have just as much trouble with the AF routine. Witness my entire prior post which only deals with my refractor. Since I use both at the same time, I have good experience with both types.
I hope that I got across at least one key point:
If the AF routine can detect lots of stars when it is way out of focus, there will be no need for a user settable Minimum Star Size, and the routine will do fabulously well clear into very out of focus images. And this works with the general structure of the code exactly as it is now. Just better star detection when out of focus. Some (I hope) good ideas on this to follow.
Alternatively, I think it only needs to deal with a single reasonably bright star to quickly determine (within 2 frames) the correct direction to go in for correct focus. That in and of itself I think is the major reason it has so much trouble dealing with the badly out of focus regions and never finds good focus (a least in my case).
It may sound like I am proposing to “rewrite all of AF” but that is not the case. The current structure is very close, I think, to being very robust, and working extremely well for all users, with all equipment, imaging all targets, and well into out of focus range.
It’s not quite there yet but with a little tweaking will be there.
My prior long post was very long on detailing specific data that illustrate the current problems, but did not detail any specific ways to solve the major problem: star detection when out of focus. And in this post, the need to know for sure if the routine is going in the right direction. Why continue moving out if there is an easy way to detect if that is the wrong direction?
Specific details on ways I think this can be done will follow when I can get them put together. And can be easily integrated into the current design, just more tweaking.
Not only do I have mostly bad weather for the next week, but my dome rotational position sensor failed 2 days ago so it will be more than a week before I am back in action.
A lot of discussion going on here but I can plainly say that I have never gotten my SCT to autofocus this easily. I installed 2.5.1.7 tonight and left the minimum star size at the default of 4. Camera is an Atik 383L+, scope is an 8" EdgeHD with 0.7 reducer. I almost never get a good U or V curve until now. 
I did increase my step size from usual 75 up 110. My first run of the night is pack 1 which started at least close to focus. I think this is a realistic expectation of the autofocus system in that you at least start somewhere close. It’s not that hard to just eyeball a couple of test exposures to be in the ball park. The new routine, at least for me with my SCT and camera and on this target, does a good job of taking it from there. Like I said, this is the easiest I have ever been able to autofocus the SCT.
Chris
Hello all,
I wish I had the opportunity to test along with you all but it’s impossible at the moment due to the shift I work.
Hey Ho !
I have been reading this thread with great interest due to owning a 10" Newt with a central obstruction and very much look forward to when I CAN get out and give it a bash myself.
One thing that did prick my ears up though was ref SGP and the fact that it’s not designed to do the whole focusing routine but to just maintain focus throughout a session.
I see the point but think that this is a missed opportunity, Every time someone, with their unique set of kit and camera, manually focuses with a baht mask and then runs the AF routine, the AF results at a given temperature will put the focuser into ‘X’ position, this will then change slightly as the session progresses with changes in temperature. The position of the focuser and the temperature will likely have a very predictable relationship. Why couldn’t SGP, at the completion of a successful AF run write/add the ambient Temp, possibly humidity too and resulting focuser position to an internal log file.
When someone sets up the next time a week later and the temp happens to be the same as logged data, at the press of a button SGP could send the focuser out to that last logged successful position at that temperature which may not be perfect but it should be close enough to get focus within the bounds for the new AF routing to work its magic without user intervention.
I always send my focuser all the way in after a session so I always begin with focuser at position zero. When I have been out in the past and used a Baht mask to get to focus I usually make a note of the focusers position, If I go out the next day or the next week I usually send the focuser out to this pre-recorded position which brings it very close to focus. SGP could do this for me.
Just think it’s worth a thought is all !
Great job I see so far, well done guy’s
Regards
Paul
Paul, I agree with you.
Logging success full focus and temp could lead to better temperature compensation and initial focus position in EQ profile.
It a good one for the features list.
Right now some additions to smart focus could be added for the out of focus conditions. The doughnuts would still have to been close enough for good detection.
