Peter: I put in a change to add a menu option in the View menu to toggle on/off image overlays. That comes with a keyboard shortcut, shift-control-o, so that should make it very easy to enable/disable it.
invent.kde.org/education/kstars/-/merge_requests/978

All: FWIW, I also fixed a bug yesterday, so anyone testing should probably upgrade to the latest version.
invent.kde.org/education/kstars/-/merge_requests/977

Hy

Cool feature to use instead of DSS overlay. It would be a nice feature if it could open files and autostretch them as there is better chance of platesolving such images. Also does it support FITS files and if so can it make use of the metadata?

I tested with one picture (attached) in the overlay folder. No FITS info was provided so it ran a "blind solve". After 30s it timed out. Unfortunately the process only terminated on one core with 12 or so cores remaining 100% busy. I had to terminate the process manually.

I had success on other images with the "singlethreadsolving" option activated. Some imaged solved OK, others timed out but when that happened, the single process was terminated correctly.

Alfred,

Thanks for testing. FWIW, I just tried your image.

With the default blind solve, I also timed out after 30s -- though all processes ended (I used the Default profile which should have multiple threads solving). I don't know why the processes weren't terminated after timeout. That was a bug that was in the previous release, but should be fixed if you're testing image overlays. Perhaps it would have terminated after a little longer wait? I don't know the internals of the Qt threading abort mechanism.

I then manually entered the rough coordinates for NGC 7000 in the table for your image: RA=21h, DEC=44 30, and it solved for me in ~10s, again using the default profile.
Solver success in 9.7s: RA 314.55 DEC 44.52 Scale 11.29 Angle 151.15
See image below.

Note, it never gets any header info from the image file--I'm assuming that users will be putting "finished images" into the overlays which as far as I know won't have this kind of info--so it will always blind solve unless you enter the RA and DEC into the table, and/or put a scale in the table or in the "Default a-s/px" box. I do recommend you put a default scale in, and manually add coordinates for any images you have trouble solving.

Hy

@astromuni It doesn't stretch, I envision people using finished images, which would be already stretched. What use case are you talking about?

It uses QImage doc.qt.io/qt-6/qimage.html to read the image files, so it would support whatever formats that supports. I'd say .jpg is your best bet.

I overlaid a bunch of stuff.
From 950mm to 135mm.
All solved fine but I did enter coordinates for each and used 2-SingleThread.
My large 3x3 Sadr mosaic didn't solve so I had to overlay each panel separately.

Really like this new feature : )

In my experience the final images dont work too well when you attempt to platesolve; especially ones that have been compressed using a lossy algorithm like jpg. Hence was thinking that users could upload pre-stretched images and apply an autostretch (I know it may not be as pretty).

Hy, I can confirm that most of the time image overlays work wonderfully, I'm a great fan of the feature. I just wanted to point out that there CAN be problems uncer certain circumstances. I repeated the test and had a screenrecorder running. Video is attached. I used the default settings and the solver timed out after 30s with several cores running at 100% for an extended period of time. I remember the same problem had occurred with the "capture and solve" button in the Align tab years ago. If I remember correctly, Jasem somehow fixed it.

I think I found the related thread...
indilib.org/forum/ekos/5095-solver-oddities.html?start=12

Alfred,

I see from your video that the solver's computations were not aborted after the timeout, but I cannot reproduce that on my Ubuntu 22.04 system -- that is, the plate-solve threads are properly terminated after timeout for me.

I think it is likely that this has something to do with how Qt kills threads in your environment, and am not sure what to say about it. Luckily, at least for image overlays, it is not an ongoing thing (that is, mostly you plate solve one day, and then use the information in the weeks/months ahead). If you want to investigate further, as I see from the other thread you can compile and run kstars, you can do as follows:

1) make sure kstars is sending stellarsolver the abort command:
Perhaps before line 199 add
fprintf(stderr, "Calling abort\n");
invent.kde.org/education/kstars/-/blob/m...solverutils.cpp#L199

and before or after line 55 add:
if (m_StellarSolver.get()) {
fprintf(stderr, "sending stellarSolver the abort message\n");
else
fprintf(stderr, "StellarSolver doesn't exist so can't abort it.\n");

invent.kde.org/education/kstars/-/blob/m.../solverutils.cpp#L55

then you'd run KStars from the command line, and look at that terminal when the timeout happens and check to see if you're getting those printouts.

2) If you wanted to go further into stellarsolver, you'd need to compile stellarsolver and install the compiled stellarsolver, perhaps making these changes:

At the start of StellarSolver::abort() add a printout:
fprintf(stderr, "aborting stellarsolver\n");
github.com/rlancaste/stellarsolver/blob/...ellarsolver.cpp#L638

and at the start and end of the function abortandwait() add

fprintf(stderr, "starting abortandwait()\n");

fprint(stderr, "abortandwait is done\n");

github.com/rlancaste/stellarsolver/blob/...ellarsolver.cpp#L647

Perhaps those things can give us some clues.
Hy

Hy,

I added a "}" in your code before the else command and started kstars from console. The output is this:

Calling abort
sending stellarSolver the abort message

so everything looks OK to me here.

With the modified Stellarsolver I get this:

Calling abort
aborting stellarsolver
sending stellarSolver the abort message

Both "abortandwait" messages do not show.

Ah, I had changed "fprint" to "fprintf" in the stellarsolver code, hope this was correct. It would otherwise give me an error.

Thanks Alfred, and sorry for the slopping typing.

So, we've concluded that
- KStars is sending the abort() message to stellarsolver.
- StellarSolver is calling its abort() method.

Now that I look at the code, I guess we didn't see the abortandwait() printouts because they only get called in the destructor, and that only will get called the next time you try to solve (then this solver is destroyed and a new solver is created). But that's no issue as it should have done the aborting when the abort() method was called.

I will ask Rob to see if he has any StellarSolver ideas.
Hy