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

 

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'

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

Oh you're probably right! My bad... I must have forgot to pull before I started testing.

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.

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.

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.

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.

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.

When github.com/rlancaste/stellarsolver.git is used, does it pull version 2.0? Or do I need something to pull that release tag?

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.

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.