×

INDI Library v1.9.8 Released (29 Sep 2022)

Bi-monthly INDI Library released with new drivers and bug fixes.

Announcing StellarSolver 2.0

  • Posts: 2826
  • Thank you received: 791
Jussi, please check that this helps the detected crash in KStars if INDI gets disconnected while running Watney or ASTAP.  I believe what was happening was that StellarSolver was logging that it was aborting when it was getting deleted, but KStars hadn't disconnected it from the object it had been logging to, but the object it was logging to had already been deleted, so it was logging to a non-existent object.  There really is no need for any logging if it is getting deleted, so I think this is a good solution.

github.com/rlancaste/stellarsolver/commi...b7d6d1f78792a6e27089

 
The following user(s) said Thank You: Jussi Saarivirta
9 months 9 hours ago #81108

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

  • Posts: 11
  • Thank you received: 1
Right, so the crashes are solved. I haven't really found anything after that. Just very, very minor details: in KStars, the tooltip for both Watney solver and ASTAP solver reads 'Astrometry.net solve-field binary'
8 months 3 weeks ago #81188

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

  • Posts: 2826
  • Thank you received: 791
Wait, I could swear I fixed that a couple of days ago. Note this change here:  github.com/KDE/kstars/commit/961575df986...4c4b0f403b84c9c2ce1d
Are you using the latest KStars from GIT master?  

github.com/KDE/kstars
or
invent.kde.org/education/kstars
8 months 3 weeks ago #81201

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

  • Posts: 11
  • Thank you received: 1
Oh you're probably right! My bad... I must have forgot to pull before I started testing.
8 months 3 weeks ago #81202

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

  • Posts: 1279
  • Thank you received: 222

Replied by Andrew on topic Announcing StellarSolver 2.0

With regards to detecting out of focus donut stars. I had thoughts about whether it would be more robust if two star detection passes with different algorithms could be employed. One algorithm tailored to large FWHM donut star shape; then switch to a reliable point like star algorithm such as gaussian when donuts are not detected.
INDI/KStars on Raspberry Pi 4, 4gb
Raspbian Buster with AstroPi3 script configuration
Skywatcher HEQ5 Pro Mount
Canon 600D Camera
Orion SSAG/ASI120mm @280mm Guide Scope
PHD2
Waveshare Stepper Motor Board - DIY Focuser
Adafruit GPS Module
Generic Bluetooth Joystick.
Startech 7 port powered USB Hub.
8 months 3 weeks ago #81227

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

  • Posts: 2826
  • Thank you received: 791
Yes, this is along the lines of what I am thinking about for the focus module.  One parameter that really makes a difference is the convolution filter used by SEP, particularly the FWHM of the shape used.  I made that a setting and its very easy to change.  I was thinking of changing that number based on feedback from the last successful star extraction and information about whether KStars expects that the star will get bigger or smaller.  As we get farther from focus, we would increase the FWHM, and as we get closer, we would decrease it.  Another similar parameter to play with is the min area parameter.
8 months 3 weeks ago #81237

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

  • Posts: 1279
  • Thank you received: 222

Replied by Andrew on topic Announcing StellarSolver 2.0

I am having issues compiling KStars. It appears to be related to Stellarsolver 2.0 changes to kstars/ekos/align/remoteastrometryparser.h line 56.
I have a thread for my issue here. www.indilib.org/forum/development/11639-...ng-kstars.html#82431
Please have a look. Thank you.
In file included from /home/pi/AstroRoot/kstars-build/kstars/KStarsLib_autogen/YBWGFWFLDP/moc_remoteastrometryparser.cpp:9,
                 from /home/pi/AstroRoot/kstars-build/kstars/KStarsLib_autogen/mocs_compilation.cpp:45:
/home/pi/AstroRoot/kstars/kstars/ekos/align/remoteastrometryparser.h:56:20: error: 'Parity' in namespace 'FITSImage' does not name a type
         FITSImage::Parity parity = FITSImage::BOTH;
                    ^~~~~~
make[2]: *** [kstars/CMakeFiles/KStarsLib.dir/build.make:848: kstars/CMakeFiles/KStarsLib.dir/KStarsLib_autogen/mocs_compilation.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:1575: kstars/CMakeFiles/KStarsLib.dir/all] Error 2
make: *** [Makefile:141: all] Error 2
INDI/KStars on Raspberry Pi 4, 4gb
Raspbian Buster with AstroPi3 script configuration
Skywatcher HEQ5 Pro Mount
Canon 600D Camera
Orion SSAG/ASI120mm @280mm Guide Scope
PHD2
Waveshare Stepper Motor Board - DIY Focuser
Adafruit GPS Module
Generic Bluetooth Joystick.
Startech 7 port powered USB Hub.
Last edit: 7 months 1 week ago by Andrew.
7 months 1 week ago #82468

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

  • Posts: 2826
  • Thank you received: 791
Yes, this is KStars taking advantage of a newer feature now in StellarSolver. You need to update and install the latest version StellarSolver and you will then have that feature.
7 months 1 week ago #82469

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

  • Posts: 1279
  • Thank you received: 222

Replied by Andrew on topic Announcing StellarSolver 2.0

It was compiled in the process with the AstroPi3 build script. I believed it built version 2.0. But I don't know how to verify that.
INDI/KStars on Raspberry Pi 4, 4gb
Raspbian Buster with AstroPi3 script configuration
Skywatcher HEQ5 Pro Mount
Canon 600D Camera
Orion SSAG/ASI120mm @280mm Guide Scope
PHD2
Waveshare Stepper Motor Board - DIY Focuser
Adafruit GPS Module
Generic Bluetooth Joystick.
Startech 7 port powered USB Hub.
7 months 1 week ago #82472

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

  • Posts: 1279
  • Thank you received: 222

Replied by Andrew on topic Announcing StellarSolver 2.0

When github.com/rlancaste/stellarsolver.git is used, does it pull version 2.0? Or do I need something to pull that release tag?
INDI/KStars on Raspberry Pi 4, 4gb
Raspbian Buster with AstroPi3 script configuration
Skywatcher HEQ5 Pro Mount
Canon 600D Camera
Orion SSAG/ASI120mm @280mm Guide Scope
PHD2
Waveshare Stepper Motor Board - DIY Focuser
Adafruit GPS Module
Generic Bluetooth Joystick.
Startech 7 port powered USB Hub.
7 months 1 week ago #82473

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

  • Posts: 1279
  • Thank you received: 222

Replied by Andrew on topic Announcing StellarSolver 2.0

Although your build script should have taken care of it, I've just compiled Stellarsolver all on its own. If KStars complete's its build after this, I'll bring this issue to the AstroPi3 script thread. At this moment, it appears to be going well.

Edit: It all compiled successfully this time. Thank you.
INDI/KStars on Raspberry Pi 4, 4gb
Raspbian Buster with AstroPi3 script configuration
Skywatcher HEQ5 Pro Mount
Canon 600D Camera
Orion SSAG/ASI120mm @280mm Guide Scope
PHD2
Waveshare Stepper Motor Board - DIY Focuser
Adafruit GPS Module
Generic Bluetooth Joystick.
Startech 7 port powered USB Hub.
Last edit: 7 months 1 week ago by Andrew.
7 months 1 week ago #82475

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

  • Posts: 219
  • Thank you received: 40
Since the introduction of Stellarsolver, all the star related operations are delegated to this library. Now I'm facing an autofocusing problem and I think that I can try to track back a fix for it into Stellarsolver... but I'm nor sure, so, here I'm asking for advice.

First, the problem. I've a fast newtonian (150/600, so f4) that has a very shallow CFZ. I've put a coma corrector on it (TS-Optics GPU). And this corrector is introducing chromatic aberration. I'm using a OSC (the ASI533MC), so the images that I capture has the bayer matrix pattern over it. Now, when I use the autofocus module with the ZWO EAF it works fine... only for the red pixels.

I suspect that Stellarsolve is using only R channel to compute HFR and then the autofocus algorithm is focusing on the red extreme of the spectrum. The problem here is that the chromatic aberration shift the focus and I end with a G channel slightly unfocused and a B channel completly unfocused.

You can see the problem if you look at the three channels (show in order RGB)



They are extracted from one single shot. The one chosen by the autofocus module seems to be the first one (R). You can see, that forgiving about the remaining miss-collimation, the R channel has an acceptable focus that deteriorate to G and it's almost completely unusable on B.

My proposal is to change the channel used on OSC images for all the quick computation to G. This way if you have chromatic aberration you will have a perfect focus on G (where you have half of the pixels) and then, then same amount of error for R and B, but overal the image will be on better focus.
7 months 1 week ago #82599
Attachments:

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

Time to create page: 0.489 seconds