Jo's description of guide-star selection is close, but not exactly what's done.
If you're curious, and can follow some C++, you can see what's done here:
invent.kde.org/education/kstars/-/blob/m...e/guidestars.cpp#L74
To be more exact, the guide star selected is "something like" this:
- Detect stars from the guide image, sorting by SNR, and keeping the top 10 in the list whose HFRs are less than 10
- Reorder the list a bit,
-- discouraging stars within 35 pixels of the edge a lot,
-- discouraging stars with SNRs > 100 a little
-- encouraging stars with 40 <= SNR < 100 a little
-- discouraging stars with close neighbors (from the original star detection list) a little
- The top scoring star is the guide star, the rest are used in the SEP MultiStar scheme as neighbors.
For sure, this is a heuristic that seems to work OK, but can be fragile.
I'd be happy to come up with something more principled, or at least something proven over more data, but I don't have a dataset with lots of guide images where I can test out different heuristics.
I think one the issues Jo's facing, for example, is that he likes to guide at quick periods (e.g. 1/2 second or 1s exposures) which reduces the SNR, and then my (arbitrary) "high" SNR value (100), which are meant to discourage galaxies, should likely be much lower for him.
Jo--It's possible that if you tried guiding with 3s or whatever periods, it might work better for you?
Of course, we could also add other star width constraints, but as you see, it already has a <10 HFR constraint, so SEP is detecting something that's part of the core of andromeda, I guess, as a star.
My solutions would be:
- After Rob's StellarSolver comes out, we can try and improve star detection,
- I should make an appeal for people to send me guide images at some point. Perhaps if I can collect a diverse set of those, I could come up with better heuristics (though if star detection was improved, this might be moot).
Hy