×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

New Internal Solver for Mac, Windows, and Linux -- Testing/ Experiments needed

  • Posts: 185
  • Thank you received: 28
Han,

I ran your files with the FastSolving option (generally the better performer) and had the following results:
Deneb_α_Cyg_200s_20191130_175725.fits -- Couldn't open either.  I did open and save as fits and jpeg in PixInsight but couldn't open the resulting files in SexySolverTester 1.2 (really strange since everything from my files loaded)
 
M13 dec min 30 degrees.fit -- FastSolving aborted.  I don't have an explanation, but a smaller FOV of M13 from my files solved in 0.552s
 
m42_20180918_055007_0_ixdaex_l_cal.fit -- solved in 6.15s
 
NGC_2359_Light_L_900_secs_2020-01-29T23-05-32_007 location removed.fits -- solved in 1.243s
 
Apogee F16M IC443_444-010-R solved.fit -- solved in 8.92s
 
IC1318_200s_20191130_183555.fits -- solved in 0.821s

Rob,

I had some issues with SexySolverTester 1.2 aborting silently on loading of files in some cases.
Last edit: 3 years 10 months ago by Richard Beck.
3 years 10 months ago #53960

Please Log in or Create an account to join the conversation.

  • Posts: 2876
  • Thank you received: 809

Thank you very much for the continued testing, you are most helpful. This is exactly what I want to do now, figure out any issues and solve them.

An issue that I think you had in trying to solve these images is that you used the default options. The thing is that I am trying to develop different options profiles to be used for different purposes. This library is effective for both Sextraction and Solving, but the desirable option settings for each task are very different. For source extraction to get information about the sources in your image, you want different settings for focusing, for guiding, for getting data about galaxies, or for astrometry. In general the goal would be to maximize the sources detected and get reliable magnitudes, flux, etc. For solving, you don't care so much about all that, you just want to keep the stars in the image that will speed up the solver and get an accurate position. You don't even care that the magnitudes are accurate, so long as you can sort the stars and get rid of the ones you don't need.

For solving images, the profiles that I have been honing for that purpose would be the following:

FastSolving - never does multiple threads, but optimized for solving otherwise
ParallelSolve - Will do multiple threads automatically when appropriate, may parallelize on different scales or depths, or not at all as needed.
ParallelSmallScale - Just like the one above, but limited to image widths of 0.1 to 10 degrees to speed it up even more.
ParallelLargeScale - Just like the two above, but limited to image widths of 1 to 180 degrees to speed it up

You should NOT use the default options for solving.

I had a go with your images, and while some of them solved very well with the appropriate profiles, as you pointed out, there were some issues. For the file that would not open, I found that it was the alpha character in the filename. I will have to take a look at this to see why it doesn't open. I am mostly using the KStars image opening, stretching, and displaying algorithms, since this library is intended to go back into KStars first and foremost, so if there is a problem here, it probably exists there too. I will check it out. The M15 image would not solve with my profiles, I will look into that, I'm not sure why yet. The NGC 2359 image sometimes was causing a crash when opening. I think the crash is related to the KStars stretch algorithm recently developed by Hy Murveit. I will check with him to see why it might crash. But when it actually did open, it solved well just like the others.

So after I changed the alpha character in the one filename and ran all the images with the internal solver with the profiles I have developed for solving, they all solved in less than 10 seconds with. the exception of M15. I will keep playing with that image.
3 years 10 months ago #53970
Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 2876
  • Thank you received: 809

Hi Han,

So the search radius is set in the profile parameters. The user can change the radius by using a different profile with a different radius, making a new profile with the desired radius, or by using the options in the edit profile tab and not using one of the saved profiles at all. You can use whatever radius you want.

I'm confused by your statement about the fov. I recently added the option for fov to the ASTAP command, and it is based upon the scale information in the image just like in astrometry.net. So if you have the scale information in your image, it attempts to use that whenever you have "use scale" selected. If you don't want to use the scale, you don't have to. This isn't saved in the profile. It is definitely not always set to 1.7478 degrees. I expected that if the scale information is saved in the fits file, then setting the fov based on this information would speed up the solve. Is that not correct? If you load a jpeg image, it doesn't have the scaling information in it, so it should not even send the fov parameter to ASTAP at all. Did it try to set the fov when you loaded a jpeg?

Here is an example below of me loading a fits image, leaving the "use_scale" checkbox checked and solving.
Then unchecking the box and solving again.
Note that I removed the parts of the log about the actual solution since that isn't relevant.
You will note that the -fov option appears in the first command, but not in the second.

Is this not the correct way to use the -fov option? Maybe I don't understand it.



+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Configuring external ASTAP solver
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Starting external ASTAP Solver...
Command: /Applications/ASTAP.app/Contents/MacOS/astap -o /private/var/folders/_t/ntxs0hp56b31tsp0_9t3rttm0000gn/T/externalSextractorSolver_341496650.ini -speed auto -f /private/var/folders/_t/ntxs0hp56b31tsp0_9t3rttm0000gn/T/externalSextractorSolver_341496650.fits -wcs -fov 0.953564 -ra 3.78231 -spd 114.116 -r 15
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Configuring external ASTAP solver
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Starting external ASTAP Solver...
Command: /Applications/ASTAP.app/Contents/MacOS/astap -o /private/var/folders/_t/ntxs0hp56b31tsp0_9t3rttm0000gn/T/externalSextractorSolver_341849597.ini -speed auto -f /private/var/folders/_t/ntxs0hp56b31tsp0_9t3rttm0000gn/T/externalSextractorSolver_341849597.fits -wcs -ra 3.78231 -spd 114.116 -r 15
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
3 years 10 months ago #53971
Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 2876
  • Thank you received: 809

Hi Han,



That is correct, The combo boxes and parameters are currently totally separate. The combo box for selecting the SExtractor is not used when you click solve. As of right now, the left set of options is to be used when you click the "Sextract" button and the right set of options will be used if you hit the "Solve" button. The option for using Internal SEP or External SExtractor along with solving is currently in the Solving Combo Box. As of right now the solving options include the following:

SexySolver (which uses Internal SEP, External Solver)
External SExtractor with external solver
Internal SEP with external solver
"Classic Astrometry" (which uses its own source extraction)
ASTAP (which uses its own source extraction)
Online solver (which uses its own source extraction)
Internal SEP with Online solver

Based on your message what I think you were expecting was that I had made two combo boxes that are both used while solving, one where you select the source extraction method and one where you select the solving method. I originally had planned to do this, and when I first made this program, that is exactly what I did, however I had run into problems because not all of the combinations were implemented or supported. As you know, ASTAP did not accept Sextractor input at all at the time I made it. So I couldn't have the user select one of the Sextractors on the left and ASTAP on the right, it wouldn't work. I also haven't implemented all the possibilities because some might not make sense. All of the external sextractor options will not work on Windows unless we can install SExtractor on windows. Really the option that I currently have implemented to use the external sextractor in solving is the second option in the list, the rest all either use the internal SEP version or use the program's built in source extraction. The reason I implemented in in that one place is for comparison purposes.
Last edit: 3 years 10 months ago by Rob Lancaster.
3 years 10 months ago #53972
Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 2876
  • Thank you received: 809
For INT SEP, EXT ASTAP, I will work on that later tonight. I will add the option to the code and set it up to export a file that could then be solved by ASTAP. I will include a warning that this function is not yet implemented in ASTAP, but it will try to do it anyway. That way you can try it out and test your new version of ASTAP so that you can see if it works. I will try to follow the guidelines you have set for how you would like to receive the file as input.
3 years 10 months ago #53973

Please Log in or Create an account to join the conversation.

  • Posts: 185
  • Thank you received: 28
Rob,

I ran the examples you mentioned above. Changing "α" to "alpha" in the filename took care of the file loading. With that change and using FastSolving, all images but Han K's M13 solved for me. Neither SexySolver or ASTAP solved the M13 image. I also ran one of my own images of M13 which was solved by SexySolver but not ASTAP. The results of these runs are in a LibreOffice spreadsheet (zipped for the forum).

File Attachment:

File Name: SexySolver...data.zip
File Size:16 KB


After one abort, I ran gdb and obtained the attached backtrace. Hopefully, this helps.

File Attachment:

File Name: SexySolver...race.txt
File Size:4 KB
3 years 10 months ago #53974
Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 2876
  • Thank you received: 809
Han, I solved the last image that you sent that wouldn't solve. It turns out that the position information saved in the file was incorrect. Once I unchecked the box to use position, it solved in less than one second with the ParallelSmallScale profile (my favorite one now)

3 years 10 months ago #53975
Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 2876
  • Thank you received: 809
I think the issue was the DEC coordinate, I think the RA one was pretty close at 16.69 that isn't too far from 16:42. But the dec should not be 16.45, that is way off from 36
3 years 10 months ago #53976

Please Log in or Create an account to join the conversation.

  • Posts: 2876
  • Thank you received: 809
Thank you very much for all the testing Richard Beck!!
3 years 10 months ago #53978

Please Log in or Create an account to join the conversation.

  • Posts: 185
  • Thank you received: 28
I'm happy to help, Rob. I duplicated your results for Han's M13, but it took my machine 1.08s to solve it ;-).
3 years 10 months ago #53980

Please Log in or Create an account to join the conversation.

  • Posts: 333
  • Thank you received: 92

I was also a little confused. Yes it changes but the scale calculation looks wrong. The give scale command is -FOV 1.7478 but the reals height is 79 arcmins equals -fov 1.32 degrees. See log below

Try this file
ufile.io/oevgwgzg

Starting external ASTAP Solver...
Command: C:/Program Files/astap/astap.exe -o C:/Users/h/AppData/Local/Temp/externalSextractorSolver_123.ini -speed auto -f C:/Users/h/AppData/Local/Temp/externalSextractorSolver_123.fits -wcs -fov 1.7478 -ra 12.7164 -spd 122.305 -r 15
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Field center: (RA,Dec) = (190.839, 32.3604) deg.
Field center: (RA H:M:S, Dec D:M:S) = (12:43:21.451, +32:21:37.603).
Field is: (-336.165, -200.323) deg from search coords.
Field size: -104.547 x -79.0393
Field rotation angle: up is 0.00386029 degrees E of N
Pixel Scale: -2.69452"

ASTAP has three priorities for image scale:

- Highest priority commandline command -fov ..
- Second priority the data from fits header
- Lowest priority the default image scale or last image scale.
3 years 10 months ago #53986

Please Log in or Create an account to join the conversation.

  • Posts: 333
  • Thank you received: 92

Yes the dec was decreased by 30 degrees by purpose. I forgot that outside 15 degrees or so there is not search.

I think my problem for M13 that Üse scale"was checked."and at the wrong value. If I uncheck the scale I get this:
<em>+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Starting Internal SexySolver Astrometry.net based Engine. . .
Solver was aborted, timed out, or failed, so no solution was found
Child solver: 4 did not solve or was aborted
Set odds ratio to solve to 1e+09 (log = 20.7233)

Scale range: 5.97222 to 20.8889 degrees wide

Image width 1164 pixels; arcsec per pixel range 18.4708 64.6048</em>

So how did the solver select 5.97222 to 20.8889 degrees wide. An undefined variable??? Later it works as normal. Then if I enter a scale 1 to 4 arcsec/pixel but it starts actually with the scale range: 2 to 8 arcsec/pixel ???? Later it works correctly. Very confusing.


The problem with the M42 images is that it doesn't recognises the position from keywords CRVAL1, CRVAL2.

For the last image NGC2359, I think my indexes where not sufficient for this very small scale image. I just added some more and it solves after 102 sec default or parallel in 21 seconds. Still a long time. ASTAP does it in little less then 3 seconds.

Han
Last edit: 3 years 10 months ago by han.
3 years 10 months ago #53987

Please Log in or Create an account to join the conversation.

Time to create page: 0.793 seconds