Rob,

I ran a bunch of trials between your last two changes. I haven't analyzed the results, but it seems the "FastSolving" profile is nearly optimum for both the internal sexysolver and astrometry.net.


I didn't run ASTAP solutions because an early run on blind solves (with jpegs) ASTAP failed. There was a message about atk-bridge missing; however, it was installed and I got the same message after installing the -dev package. A "locate atk-bridge" gives the following:

That sounds good, because in my last change, I modified the Parallel solving profiles so that they will automatically do multithreaded solves if it thinks it would help, but if not, then it will default back to the fast solving options. Basically it is a multithreaded algorithm auto setting. So now maybe those will be better all around, because there are times when they REALLY help the performance, but other times when they don't.

Were you able to reproduce the crash you reported earlier?

Whatever the default logging was, SexySolverTester would crash. Turning off logging or changing to verbose logging took care of it.

Ok, I think I can solve it. I will look into it. I think it is an issue only on Linux. Neither windows or Mac had an issue, but sometimes I saw the same issue on another Linux system. It is related to initialization of the logger.

Thanks for testing!

Han, I think I fixed most of these things today. #1 I think I fixed by improving the options profile and making the interface clearer. #3 I think I fixed this for the external solvers.

For #2 though, I am confused since I think it does give a warning?



It should be noted that this message prints because my SexySolver algorithm determined it could not run Sextractor since it doesn't exist. It did not try to run the command, but instead returned an error and printed this message. Is this not the warning you are looking for?

One more question Han.

Is there a version of ASTAP released somewhere so that I can try implementing INT SEP EXT ASTAP?

So I released a new version based on my fixes to all the great feedback that I got today.

github.com/rlancaste/sexysolver-tester/releases/tag/1.2

I tested the new version 1.2. I tried only the internal extractor and solver using the default settings. Here are six problem files:

ufile.io/pjj8pgom

It can't solve three files. Two take too long and one file can't be opened.

Sometimes the program crashes after problem file. Didn't investigate further.

Aborting the internal solver takes too long for impatient users.

Han

I know it is only a test program but for the record:

The command line to solve using ASTAP is not correct:

Command: C:/astap.fpc/astap.exe -o C:/Users/h/AppData/Local/Temp/externalSextractorSolver_12197.ini -speed auto -f C:/Users/h/AppData/Local/Temp/externalSextractorSolver_12197.fits -wcs -fov 1.7478 -ra 19.9789 -spd 110.525 -r 15

The fov is always forced at 1.7478 degrees. Better is to remove -fov parameter for FITS files and to set it to auto for jpeg/png files by: -fov 0 It would also be nice to allow setting the search radius which is now fixed at 15 degrees by -r 15

Cheers, Han

Not complete yet. I uploaded ASTAP version 0.9.362g for Linux and Windows (at www.hnsky.org only) which can read and display FITS files extensions like XYLS or AXY. Just as text with tab separated. I played briefly with a spreadsheet but that took an other 500 kbyte to the executable, so I skipped that. The export XYLS has been removed. I briefly played with creating AXY files and that worked using nova.astrometry.net but removed it.

So back to your question. Importing INT SEP file to display only should be no problem. I haven't implemented solving of such files. If your program can produce a FITS table file with the X and Y position of 500 brightest objects I could work on the code to solve it. No other columns are required. See screenshot below. ( For AXY or XYLS files you have to type *.* before it sees them)



Multiple ASTAP executables can work in parallel if you divide the working area. E.g for blind:

South part of sky
c:\astap.fpc\astap.exe -f c:\astap.fpc\test_files\parallel_running\m16.fits -ra 0 -spd 0 -fov 90

North part of sky
c:\astap.fpc\astap.exe -f c:\astap.fpc\test_files\parallel_running\m16.fits -ra 0 -spd 180 -fov 90

In principle it would be possible to coordinate the programs since they have a simple server to communicate. An other option would be to introduce threads. The question if that brings any real benefit. 99% of all solves is withing 10 degrees offset and done in seconds.

Han