Is there a way for this solver to output the amount of error when plate solving? I'm running into an issue with MountWizard4, that uses the KStars solver, ASTAP, Cloudmakers, or external Astrometry, and for some reason certain solvers produce a large amount of error when solving. ( see issue here ). This amount of error, leads to poor mount models where most of the points are unusable.

RDBeck,

Thanks for testing again, nice variety of different images! That's a good verification that it works. Looks like you always used the defaults, did you want to try playing with some settings? In terms of how hot the CPU gets, I don't know that there is anything we can do about that. Plate solving is an intensive operation and will tax the CPU a bit.

Lead_weight,

I assume you mean how far off the final plate solved result image center is from the initial RA and DEC from the search parameters? Right now it doesn't do that, but that might be useful since many programs use that info.

Thanks,

Rob

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