Yes, that's exactly what we're looking at. For some reason certain solvers show lots of error, around 800-2000, while others only show 50 or so. You can see it in the screenshot of the thread I linked. We're trying to uncover why this is happening with certain solvers. So I was just curious if you could report the error in the table results so we can see if any of the built in solvers for KStars show this issue.

Sure, I can add that

Rob,

I was just shocked at how hot the CPU got. I don't normally see that widget while platesolving as part of a session. Of course, heat builds up a bit more with multiple trials back to back than it would in normal service where the shortest time between solves would be the slew and settle time when slewing to target after solving.

I can look at the multiple options. I just wanted to get you the default results. I can take that on in another session (which I may do on the desktop with liquid cooling instead of the NUC).

Ok I implemented this along with a couple of other changes. If you are using the Linux version you can rebuild after a git pull. If you are using Windows or Mac, I will need to rebuild it in a new version release first

I added a check for the amount of RAM on the system before allowing it to proceed to use astrometry with the inParallel option. Please see if this can resolve this problem.

Rob,

I ran several additional targets, typically running all solvers through all options. The typical order would be default, downsample2, small sized stars, mid sized stars and big sized stars. The csv file is attached. Any missing options should be assumed to be failed solves (although there could be the odd missed option).

The last image was run through the solvers 5 times for the default options. The results indicate that the single runs should be reasonably representative of the time required.

These were run on my PixInsight desktop, Intel i7-9700K, 64 GB RAM, liquid cooled.

Rob, you have done a fantastic job by making Astrometry.net working without external programs.

I briefly have played with the Windows executable. I noted that the solving time of the internal solver and ASTAP are very comparable. Furthermore it work very well for very ultra short exposures. As a last test I tried large offset in the header position. For that I changed the declination in the FITS header. There seems a maximum search field limit of 15 degrees in place. For a 15 degrees error in the header the internal solver takes about 22 seconds to solve. ASTAP will solve in 6 seconds. I would be nice to be able to test it for larger offsets/errors.

Two of my test files:
ufile.io/ow361q1p

Not so important, but I could not get the classic Astrometry.net working ("All sky plate solver" for MS Windows). The slash versus back slash is understandable but the .exe extension seems wrong:

Default settings:
C:/Users/h/AppData/Local/cygwin_ansvr/etc/astrometry/backend.cfg
C:/Users/h/AppData/Local/cygwin_ansvr/lib/astrometry/bin/solve-field.exe
C:/Users/h/AppData/Local/cygwin_ansvr/lib/astrometry/bin/wcsinfo.exe


p.s. I suggest you select a more neutral name for the application. Especially for users which share a computer.


Han
author of the ASTAP program

One more question. Can the solve speed be influenced by the number of stars extracted? For ASTAP you can limit the maximum number of stars extracted. Normally it's default limited to 500. For star rich images reducing it has a dramatic effect on the solve speed but reduces the reliability.

Han

It definitely speeds things up, you can see that if you use the settings of the sextractor part, e.g., limit max and min area. This reduces the number of stars found, and makes things much faster. The question is how do you limit the number of stars? If you first detect all and then only take (e.g.) the N brightest, the work/time had already been wasted. Stopping after N might end in an uneven distribution. How do you do it in ASTAP?

In ASTAP the brightest detected stars are separated on SNR value. It builds a SNR histogram making an quick extracting of the specified amount of the brightest stars relative easy. It's also essential because it tries to build the smallest quads (I call it tetrahedrons) possible and the database and image quads should be identical. This will only be the case if for both the image and database the same amount of brightest stars are selected.

There is fundamental difference between Astrometry.net and ASTAP with respect to the index and database. The ASTAP database contains only the star positions and the unused magnitude. The star database is sorted on magnitude so extracting the 500 brightest star easy. The Astrometry.net indexes contains already build quads.

I experimented with the Sexysolver Library tester "Cut Bright" and "Sat. Limit" settings but quickly the solving fails. If I set "Cut bright" at 50%, it detects half amount of stars but solving fails. Is this selection working correctly? For proper separation an accurate star flux measurement is required.


Note that for developing and debugging ASTAP the image viewer was essential. It allows in debug mode to plot the extracted stars and database stars.

Han

Using the Sextractor, I can see the star are marked with red circles. Aha, so I have to select Cut Dim. Yes that makes a great speed difference.

Would a selection on a number of stars rather then % not be more efficient? For short exposures you don't want to throw away stars but for star rich images you want. So I would like to set a limiting number of stars.

With the setting CutDim=85% equals 500 stars of the original 3600, the solving speed is three times faster for large offsets.

Han

There should be an option to filter out hot pixels. By a minimum HFD expressed in either in pixels or arcseconds. Here two two test files:

ufile.io/toia92ls


Han