Sorry one more note, I would not recommend normally solving blindly. While StellarSolver is much better at doing that than astrometry on its own could do, it does that by running a bunch of parallel threads. That is really great when you need it since it solves super fast, but when you don't need to solve blindly, it is a waste of resources (RAM and CPU) I think. As you observed, when you do that, there is more risk of all the memory getting used up and crashing. It shouldn't happen, but I think if you do it all the time, the likelihood increases.

Oh, that could certainly be it too! Yes the /tmp directory often gets deleted I think. Yeah, we could make the default someplace else.

Originally my thought was that we should make it in /tmp and have the same file name each time so that if the user doesn't really want the log, that it doesn't eat up the whole system hard driver if they accidentally had the feature turned on. If they do need they log, they can copy it out of temp before it gets deleted or overwritten.

Yes,, in Logs the EKOS alignment box is checked in both profiles. Last curious fact: If I run the sim profile and do an align (do nothing) solve, it solves the sim image and opens and writes to that file (which I have now located in the /home/astroberry directory). If I then run the equipment profile (loading only camera and mount) and do a solve on a (white) blank image, the solve fails and the file disappears!

Ron

curious-er and curious-er : If I do a load and slew from a previous image in the equipment profile, it does write the file, but in that file it says it is doing a 'blind solve' even though I have use_position and scale checked. It seems the file starts out by loading or checking a large number of the index files, I don't know why it would not do that for a totally white image as in the above condition of capture and solve, but do nothing.

Anyway, I think I know how to get it to write that log file in the future - maybe.

thanks,

Ron

Yes, if you try to solve an image with astrometry, the first thing it does is load the index files if you have it selected to load them in parallel. If you don't, it will not do that and will check them one after the other.

One confusing thing about astrometry.net is that the solver is called "blind" and is called that even if it is informed. It probably is not doing a blind solve actually.

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

Hi Hank,

Thanks for checking it out! My responses are below

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.

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?

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.



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?



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.

Hello Rob,

See my remarks:

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


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.
Good, I missed that.
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.

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

|

Thank You, Han!

Ok Han, I just made a StellarSolver commit to correct these couple of things. No changes to KStars were necessary.

1. If the user requested ASTAP with any other star extraction method except the built in one, StellarSolver prints a warning message and automatically changes it to the built in ASTAP star extractor.

2. I added support for reading, saving, and displaying the contents of the log file from ASTAP. I set it up so that if they select anything other than log_none for logging options, it will turn on the log option for ASTAP. If they selected log to file, it will then go straight to the log file they specified just like astrometry.net does. (So basically I just copy the log file from the temp directory where ASTAP put it to wherever they specify it should go.) Or if they did not select log to file, the log file will be read and displayed in the running log at the bottom of the window. (of course it should be noted, that alignment logging must be turned on in KStars to get any messages from a solver)

3. I added several lines to the code that reads the ini file from ASTAP. Now it searches for the WARNING and ERROR keywords in the file. If it finds them, it will display them in the log at the bottom of the window. This is done regardless of the logging options that I explained in 2. (of course it should be noted, that alignment logging must be turned on in KStars to get any messages from a solver)

I think these will fix your concerns. Did I miss anything?

Thanks,

Rob

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