han replied to the topic 'ASTAP/KStars issue (with workaround)' in the forum. 1 month ago

Hello Hy,

Why there would be a difference in execution speed, I can only guess. Maybe FOV setting is lower.  It will still solve if the FOV is 20 to 30 % too low but less reliable and reduces the speed. As you already mentioned, ASTAP requires the image height in degrees. If it is unknown you could execute it with "-fov 0"  which is equivalent to auto and it will try all FOV's between 10 degrees and 0.4 degree but I'm not sure if that is possible with EKOS.  The program SharpCap uses this option in case solving fails, but I think it is better reserved for once during installation or images with no FOV specified.

ASTAP can be used as star extractor using the the option -extract , see www.hnsky.org/astap.htm#astap_command_line   You only have to specify the minimum star SNR  For solving specify minimum snr  as 10. (-extract 10). The output is a csv text file.

Note ASTAP is now also available as a command line executable version for headless setups.

Han

Read More...

han replied to the topic 'ASTAP/KStars issue (with workaround)' in the forum. 1 month ago

Maybe this is something for Rob, @ rlancaste

Han

Read More...

You can just download the Debian package for armhf (32bit) and arm64 (64 bit). No compilation required. If you want to compile, install Lazarus and load astap_linux.lpi then compile.

Binaries
64 bit:
sourceforge.net/projects/astap-program/f...p_arm64.deb/download

32 bit:
sourceforge.net/projects/astap-program/f...p_armhf.deb/download


You can associate it to .fits or for quick scrolling you have this option:



Han

Read More...

Binning prior to the file exchange with ASTAP will be the fastest solution. Saving and loading a binned image is much faster then with the original size.

Read More...

Yes that looks okay to me. You delegate all binning to ASTAP. However I assume you get a shorter execution time if the binning is done is Ekos so the file size is smaller from the beginning. So if possible it is faster to bin earlier in Ekos avoiding disk read/write time.

Han

Read More...

Hello Rob,

Looks all good and complete for messages. Just add -z 0 to the command line as a safeguard/override against ASTAP internal settings.



p.s. I'm working on a new database format for ASTAP splitting it in smaller sections to speed up solving. At the moment no idea how effective that will be. It will have no effect the interface. An other option is using multiple processors but at the moment no desire to go that way.

Han

Read More...

Hello Rob,

See my remarks:

rlancaste wrote: Hi Hank,
1. So I was thinking that both SEP and local Sextractor were working pretty well with ASTAP, are you saying that the built in star extraction should be preferred with ASTAP, or are you saying that the other methods don't work with ASTAP.


In august I decided to remove the .XYLS input. I was not so happy with the "cleanness" of the code and the internal ASTAP extractor performs very similar, so I removed the option to use sextractor as indicated here:
www.indilib.org/forum/general/6845-new-i...html?start=288#58378

rlancaste wrote: Hi Hank,
2. I am not sure what you mean by "part of the log is missing". Are you saying the log information is not getting into the Ekos log at the bottom of the Align Module or are you saying that it isn't appearing in a log file?
Of the ASTAP log only the first line is reported in Astrometrylog.txt. The next line line "using


Of the ASTAP log only the first line is reported in Astrometrylog.txt. The next line lines "using G17..." are not reported in AstrometryLog.txt. See red marked part of the log.

rlancaste wrote: Hi Hank,
3. The search radius can easily be set in the Options Profile, along with many other options. The default for all the profiles is 15 degrees, but can easily be changed by the user.

Good, I missed that.

rlancaste wrote: Hi Hank,
4. For downsampling, currently I have it using the downsample option selected by the user in the options profile. There is also an auto downsample option. So you are saying here that if the user has the auto downsample option selected, then we should still pass the z parameter with a "0", since currently we only pass the parameter if they have something other than 1 selected. Or am I misunderstanding this?

The downsampling can be set in Ekos. That is good no change required. Adding the extra option : "-z 0" prevents that ASTAP does a second additional binning. It is the safest option for the case the user accessed ASTAP directly and forced a binning=2x2 in the ASTAP settings.

rlancaste wrote: Hi Hank,
5. We can definitely process the warnings, that should not be too hard. I will be sure to do that. But are you meaning that the information should be displayed in the log at the bottom of the Align module or in a separate log file?
For the idea of displaying information as discussed in #2 and #5, we do have options in KStars for the user to be able to decide whether they want to display the information in a separate log file, if they want everything to be displayed at the bottom in the Align module, and if they want to save all that to a combined log file. I am just asking to clarify what you meant about what you said.

The ASTAP warning(s) are useful since it warns the user of incorrect pixel-scale/focal length which could result in a poorer performance. The ASTAP log contains all warnings and error messages. That is probably the easiest solution. Alternatively you could read the program exit code for ERROR or the keywords WARNING or ERROR of the ini file or the WARNING keyword of the .wcs file.

I would prefer to have at least the warning implemented so either read the full log or read the string behind the "WARNING =" keyword in the .wcs file are the easiest way to implement.

Cheers, Han

Read More...

Hello Rob,

I played with Ekos & Stellar solver and it all worked for me in simulation. Thanks for the work.

I have a few remarks about using ASTAP (as a backup solver) in the menu.

1) The sextractor can be activated using the ASTAP option. It doesn't do anything useful for the local ASTAP solver. So I would suggest to inhibit the options if ASTAP is selected or force the correct "source extraction method"="Build in method for solver" .



2) A part of the ASTAP solver log is missing. Maybe by purpose.


3) It seems not possible to adjust the search radius. This is fixed at 15 degrees. I would suggest to make it adjustable.

4) The be sure that the best down-sampling is taken, I would suggest to add in the command-line "-z 0" to force auto selection of the down-sampling

5) Warnings and errors of ASTAP seems not being processed. Warning are in the .wcs file as warning= keyword. Errors and warning are in the .ini output file behind the warning ='' and error ='' keywords. Or alternatively just report the full log with warnings and errors included
See www.hnsky.org/astap.htm#astap_command_line

Han

Read More...

Ron,

Thanks. It got the new test program running in Windows. Looks all okay. Solves all in a few seconds. The default option and "all stars" seems most reliable.

Han

Read More...

Hello Rob,

Thanks for the update. I wanted to test the Windows version 1.5 but failed to find the correct executable. There are 121 executable files but none with a name like Stellarsolver.exe or something similar. How to run this tester?

Han

rlancaste wrote: We haven't made any updates in several days, StellarSolver is now working very well in KStars, and things mostly seem stable. So I made a StellarSolver Release! It has been awhile, the last release was in May, but I took a break for a few months, and then this fall we were working very hard on the integration into KStars and making lots of changes, so I didn't want to make a new release until everything seemed pretty good. Here it is with the Tester built on Mac and Windows:

github.com/rlancaste/stellarsolver/releases/tag/1.5



Read More...

The just released ASTAP solver 0.9.449 (development version) is faster for small fields-of-view. This was achieved by creating an own star database cache and reusing the star data if possible. Improvement for small fields (<0.5 degrees) is 35 to 40% and a few degrees offset or more. For larger fields-of-view the improvement is less.

Released as development version at:
www.hnsky.org/astap_amd64.deb


Performance on some test images with a large position offset:
FOV=4.6 degrees, offset 50 degrees. Image solved in 2.6 seconds
FOV=0.48 degrees, offset 22 degrees. Image solved in 34 seconds
FOV=0.23 degrees, offset 6 degrees. Image solved in 20.5 seconds

Mac and Raspbian Pi versions will be released in a few days after more testing. Feedback is welcome

Han

Read More...

Extracting very faint stars is not easy, but important for solving. I think ASTAP performs very simular as Sextractor. Having SEP internally will be from programmers point of view a superior solution but see how ASTAP performs :)

Read More...

rlancaste wrote: _________
Source Extraction: to find the stars in your image in order to solve. In StellarSolver, I have the option for 3 different methods:

- Internal SEP: this requires no external programs, it is the same SEP star extraction algorithm we have used in KStars for Focus and Guiding for awhile now. It is essentially a library version of the method below (though there are some differences which is why they give slightly different results). It is entirely internal to the program, so there are no files saved to disk for the extraction which is great for Raspberry Pis etc.

- External Sextractor: this does require an external program, SExtractor, or the Source Extractor. This is their official standalone program. The drawback is you would need to have sextractor installed and it does save a bunch of files to disk in order to do its operations.

- BuiltIn Sextractor: This uses whatever method of source extraction the solver uses by default. StellarSolver uses SEP, just like the Internal SEP setting. Local astrometry.net uses its own source extraction method which uses a bunch of external resources including python, netpbm and other packages. (All those external dependences caused me huge amounts of headaches years ago when I ported kstars to Mac computers) And finally ASTAP has its own internal source extractor which is pretty good.

Note: Either Internal SEP or External Sextractor should be superior to the built in version of the programs. SExtractor is REALLY good at extracting stars, and that greatly speeds up solving, but it has a LOT of options that we need to perfect.

______________________________________

Rob


If there are still problems with star extraction you could consider the ASTAP v0.9.442 extraction option . For an other problem I have added the option to write the extracted stars to a comma separated csv file:

-extract snr_minimum

The snr_minimum is the minimum star snr value required. Default at 30 but for solving snr=10 should be used. The output file has the same name as the image but with extension .csv and is containing the following comma separated data as below:

It is a development version compiled for Linux and Windows. Mac and Raspberry Pi are outstanding.

Han


Read More...