That is too bad. The HFR routine does not work for sure but the, I guess old pinpoint related routine, is working great for some reason. I guess I finally tweaked the settings correctly. Apologies. The HFR routine does not work for sure. I abandoned it and played more attention to the Pinpoint related routine and hence the success.
I really have no idea what this is or why it’s happening. I cannot reproduce it. I followed the instructions above and my slider works immediately in real time. Not sure what’s different… what I can say is that I don’t think it’s super critical to the process of refining AF. It’s most important that the actual AF routine respects that number… Not saying I’m giving up on that part just that we need to look at other aspects first… like the image you provided above. If you want, you can make that FITS image available and we can take a look at why the AF routine is skipping so many stars.
Hello,
if this can help, I encountered exactly the same problem that chasmiller46 here, sometime stars are well detected and sometime not.
Strangely, one of the image I used is also ncg3628, and I got exactly the same result as chasmiller46.
Some stars that appear to be in the good size range, are not detected.
Thanks.
Pascal
some complement to my last comment, on ncg3628, in some subs, stars are well detected in other not, depending of the filter I used … my green subs have the worst star detection (the best is with the luminance, where dozens of star was detected, only two or three with the green filter subs), may be because these subs are more noisy that the others. Noise and/or background level seemed to play a role her… may be.
Thanks.
Pascal
Ken:
The image with the undetected stars is in a drop box:
I did some more testing of the HFR routines and made careful notes of the exact sequence of events that I used. What I found was that sometimes the HFR routines worked correctly other times the exact same sequence resulted in the HFR routines failing completely. Whether the HFR routine worked or failed seemed completely arbitrary.
As a commercial software developer, I have seen this same behavior in my own code. It can be caused by an uninitialized variable used by the HFR routine. Sometimes when SGP is started, that variable gets a random value that is compatible with the HFR routine and it works. The next time, that variable gets a garbage value that causes the HFR routine to fail. Just thinking out loud…
Charlie
Thanks. I’ll take a look.
Also… your stars are not being selected because they are not close enough to our definition of a circle:
We need to find a way to use transforms (like Circular Hough Transform) to have some “play” when detecting circle shapes.
I thought that non round stars might be the issue. The seeing was only 2/5 while imaging this target and the PHD2 Guiding graph was showing bigger deviations than usual. However, I suspect these types of stars are pretty common.
Charlie
OK - i think that’s why some of my images have very few stars detected - they are not round enough. i can’t tell whether this is due to drift or collimation. if i make the step size small enough then the stars never really become super-donuty, SGP seems OK with them. however for the attached image, the stars are pretty clearly donuts and only one is detected by SGP. note that it detects a bunch of hot pixels if the min star size is less than 4. if set to 4 i get exactly one star, which might be round enough due to drift undoing field curvature.
Would it be possible to use an algorithm that doesn’t care about the shape at all? Something that measures the area of the blob? Something we did at work for particle analysis was the equivalent circle diameter, the size of a circle that has the same area as a particle.
Chris
I am not sure, but I think so… either way we have no choice… expecting circles is a bit Utopian.
- When colimation is not perfect and we move away from focus, we get disfigured shapes (all kinds really), but mostly strong semi-circles with some other odd shape on the other side. While I think it’s reasonable to expect good colimation during AF, expecting perfect circles is a path that will lead to pain and tears.
- When shooting at low (local) altitudes, atmospheric aberrations cause issues with circles.
Right now we seem to be having great success with “fast” central obstruction scopes… and less success with f/8 - f/10. Off to find the happy medium… we’ll see what we can come up with.
OK… well, I made a couple changes to our circle definition that are not too hard (basically, threw it away). The good news is that it is much better at finding stars that are not perfectly round. The bad is that this increase in star detection sensitivity also open the door for some amount of false positive detection (which I hope we can refine without more user settings).
@chasmiller46 Here is the image you provided with the new detection routine:
@pfile Here is the image you provided (using the new detection routine):
Ken:
What you have been able to do is impressive. I am very encouraged by this progress.
Charlie
thanks, that is awesome… looking forward to the next beta.
I appreciate the encouragement. The validity of this statement may or may not be true.
One thing we need to keep in mind as the beta progresses is that by removing (loosening) the requirements for a circle, we have also agreed to live with less than perfect centroid detection. Detecting the centroid of a circle is easy… detecting the centroid of a “shape / blob” thing is less than perfect, a little more complex and really more of a “center of gravity” for the shape than an actual centroid.
This might have an effect on the way in which HFR is calculated (since it relies on the centroid being accurate). That said, I am of the opinion that this concession has more pros than cons and that it will still reflect a fairly accurate mean HFR (at least relative to the other frames in the run).
Beta release 2.5.1.3 has these changes if you’d like to experiment.
well, hopefully for tighter donuts the computation is still pretty accurate. IMHO the only issue with earlier versions of SGP was that big donuts were completely ignored, or portions of the donut were interpreted as a star with a small HFR, causing the ends of the V to get messed up and confuse the calculation. as long as the new algorithm avoids this and is able to compute some close-enough large HFR for donut stars, it seems to me that smart focus autofocus should work pretty well.
is there a way for a user to “replay” an AF pack in SGP or do i have to load each image and compute the HFR for each one?
Hello,
thank you for the new released version, better star detection with my previous undetectable stars, but still some strange things: detection circles are displayed with an offset and there are still several false detections.
I do not understand the detection behavior when I move the pixel number cursor, smaller pixel number should give the maximum star detection, but is not the case.
Thank you again for your work and your energy.
Pascal
Hello,
in real conditions this time … worse, no real star detection, no possibility to use AF. Increasing the exposure time does not solve the problem.
Thanks.
Pascal
While we appreciate your feedback there is literally nothing we do to help without AF packs (or at least saving and sending troublesome frames).
Hello Ken,
thank you, sorry I do not save my AF frame (now I activated this
option), you can take a look to this frame where the problem is clear,
with luminance the detection is better but I cannot try 300sec exposure
for the AF…
Thank you again.
Regards.
PascalM100_120sec_2x2_G_230638.zip (543.3 KB)
Uploading…