×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

Improving the Internal Guider

  • Posts: 1119
  • Thank you received: 182
The internal guider improved tremendously since Hy implemented the GPG and multistar algorithms recently. Thanks, Hy!
There is one thing still missing, though: The guider sometimes picks galaxy cores as guide stars, with disastrous results. I have now made that experience 3 nights in a row, trying to collect light from a light polluted city on M31.
The night starts out fine, the guider picks an actual star, but as M31 gets closer to the meridian and thus the SNR of its core increases, after the meridian flip the guider will now pick the galaxy core and guiding falls apart, thus rendering all images acquired after the flip useless.
That is clearly illustrated in these screenshots:





And here the guide log of that session.

File Attachment:

File Name: guide_log-...6-36.txt
File Size:1,538 KB


After discussing this problem with Hy I think there may be an easy solution.
What he told me is that at present the guider will pick the object with the highest SNR as the guide star, irrespective of the shape of the object. That is a problem with bright galaxy cores like M31.
I think this can be overcome by modifying how the guider picks the guide star.
Would it be feasible to first rank the objects by SNR (which is happening anyway at present), then limiting the group to objects with an SNR >10 (or 15, would be great to allow the user to choose the minimum SNR), then dividing the SNR values by the HFR. Since galaxy cores are not 1-dimensional, this will greatly reduce their priority ranking. For instance, the M31 core had an HFR of almost 7 with an SNR of 21. The next brightest star had an SNR of 20, but an HFR of only 1.5. It would thus have ranked far higher in the priority listing for guide stars and the M31 core would not have been picked.

Can anyone think of any special cases where this amended procedure for picking a guide star would lead to unwanted consequences?

Jo
Last edit: 3 years 6 months ago by Jose Corazon.
3 years 6 months ago #60277
Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 1957
  • Thank you received: 420
Jo,

I am not sure if everyone using the internal guider will always have guide stars (or other objects) available with SNR > 15 and perhaps not even 10. Think of people using OAG for example. Why not take the, say, top 15 or 20 objects instead and then perform the procedure that you proposed?


Wouter
3 years 6 months ago #60278

Please Log in or Create an account to join the conversation.

  • Posts: 1119
  • Thank you received: 182
That should be fine as well. Rank the top 10 objects by SNR, then apply the division by HFR and rerank.
3 years 6 months ago #60280

Please Log in or Create an account to join the conversation.

  • Posts: 179
  • Thank you received: 16
What is that module with the traces (first screenshot?)
3 years 6 months ago #60368

Please Log in or Create an account to join the conversation.

  • Posts: 1957
  • Thank you received: 420
It's the Analyze module that only is available at the moment in the nightly builds.
The following user(s) said Thank You: AirBourn
Last edit: 3 years 6 months ago by Wouter van Reeven.
3 years 6 months ago #60369

Please Log in or Create an account to join the conversation.

  • Posts: 1208
  • Thank you received: 559
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
The following user(s) said Thank You: Alfred, Wouter van Reeven, Jose Corazon
3 years 6 months ago #60396

Please Log in or Create an account to join the conversation.

  • Posts: 1119
  • Thank you received: 182
Hy,

The logs from that session can be downloaded here: www.dropbox.com/sh/n9wn41c9kbz99u3/AABPi...kOzbPud7FXsGvDa?dl=0

After our recent discussion about this, I tried guiding at 4s intervals to test your theory, but it made no difference. The guider selected the M31 core again every time.

It is well possible that the case I have described here is a special case that only applies to M31, as it has the brightest core of all galaxies in the local group. Galaxies further way are likely too dim and will always be outshone by closer stars in the same field.

So I suspect your algorithm works for > 99% of all celestial targets, except for M31 and possibly M42.

But really! Aren't we striving for perfection here!?!?

:-)
3 years 6 months ago #60403

Please Log in or Create an account to join the conversation.

  • Posts: 77
  • Thank you received: 16
Jo, Hy, et al,

By way of adding a data point, I imaged M31 on the night of 9-18-20 under some very good conditions (well, for the mid-west anyway). I was using KStars 3.5.0 Beta as compiled from Git some days ago with the new SEP Multi Star internal guiding routine. As a reference I am using an ASI 178MM camera as guider connected to a 45mmED @ 300mm focal length Borg scope. The SEP guide algorithm always chose actual stars and worked flawlessly throughout the session which included a meridian flip. In total I gathered 82 exposures at 4 minutes each totaling 5 hrs, 28 minutes. I have used the SEP guide algorithm several times recently and each time was successful.

Perhaps it may be related to sampling size of the guide camera/scope system. For example, my camera has 2.40 um pixels coupled to the 300mm focal length guide scope which gives 1.65 "/pixel sampling @ 1x1 binning. It looks like from your screen shot you have an ASI 120MM coupled to a very short 120mm focal length scope. 3.75um pixels coupled to the 120mm focal length scope would yield 6.45"/pixel @ 1x1 binning.

This is just a thought on the sampling size and would of course require some real world testing with multiple data sets to come to any conclusion. As Hy points out there may be a fix possible in the software and/or math involved.
The following user(s) said Thank You: Jose Corazon
Last edit: 3 years 6 months ago by Midwest Astronomer.
3 years 6 months ago #60407

Please Log in or Create an account to join the conversation.

  • Posts: 1208
  • Thank you received: 559
FWIW, I looked at Jo's log, and it's true that it selected the core of M31 as a guide star, which probably isn't the best idea.
Not sure why that would impact guiding so much, though, but makes sense to improve that.
I realized there was a simple fix--OK perhaps not as automatic as we'd like, but workable for now.

I sent him a patch he can compile/test which adds a guider option that sets the maximum allowable
HFR for a guide star. His M31 "guide star" had a HFR around 5, which is way larger than I think makes sense.
The code I wrote allowed for guide stars to have an HFR of 10, because of some feedback I previously got, but making this user settable
I think makes sense. Honestly, I would default it to 3, not 10, and let those who want to use high HFR guide stars set the option themselves.

We'll see if Jo's happy with this fix, and if so, perhaps propose adding it to the main code.
Hy
The following user(s) said Thank You: Alfred, Jose Corazon
3 years 6 months ago #60410

Please Log in or Create an account to join the conversation.

  • Posts: 1119
  • Thank you received: 182
Will test as soon as the clouds clear up here.

I realize, this may be a special case and only be relevant when guiding on a few "weird" objects, like M31, but nonetheless the flexibility to select guide stars by HFR may be helpful for other cases as well that one cannot predict at the moment.

So thanks again for making these changes.

Jo
3 years 6 months ago #60440

Please Log in or Create an account to join the conversation.

  • Posts: 1119
  • Thank you received: 182


Thanks, LinuxPal!

This is a good point and for sure important for why HFR control of the guide star could be immensely helpful to fix the problem. The pixel sampling size would definitely impact on guide star selection.
3 years 6 months ago #60441

Please Log in or Create an account to join the conversation.

  • Posts: 1119
  • Thank you received: 182


I have tested Hy's new code now two nights in a row and the problem with the guider picking the core of M31 has gone away. I also tested last night on the Wizard Nebula with excellent results. RMS with the CEM25P and the ZWO 120 mm FL guide scope (with ASI120MM-S attached) is now down to ~0.75. I don't see how anything better can be expected from such a short FL guide scope.

IMO the ability to limit the max HFR for guide star picking is crucial for optimizing guiding with different focal length guide scopes. I hope this makes it into the main code soon.

Thanks again, Hy!

Jo
3 years 6 months ago #60649

Please Log in or Create an account to join the conversation.

Time to create page: 0.389 seconds