I assume you mean the "startSovler" part?
I would say yes, somebody meant to write startSolver and goofed. I just took a peek, and it looks like it has been called that for more than 4 years. That is fairly easy to change, but I am not sure we need to do so because:
The good news is that all those astrometryparsers should not really be needed anymore because now all that options parsing is handled internally in StellarSolver to make the code simpler and cleaner. Not only that, the same options profiles will work for all the methods StellarSolver uses, ASTAP, internal solver, local astrometry, and online solver, instead of having many different options for the different methods of solving all in different places and some in configuration files that could be set incorrectly. Now it is just one set of options, all internal in KStars in the one place, so you can'f have a messed up file somewhere preventing your astrometry from working.
Read More...
J., I just sent this to Jasem.
Jim and Andrew, those are very very good ideas! I think both of those could make sense. We should definitely take a look.
I just made a change to the autodownsample function for the solver, to just be a little less aggressive because it was causing some failed solves since the stars were downsampled too much and were no longer starlike.
Read More...
Thank you very much Han,
We were having an issue about a week ago with star extraction. We only found out about the issue during the integration. KStars already used SEP as you know and StellarSolver used it as well in the same way so we figured there would be no problems with that. But then we wanted to make star extraction asynchronous in KStars and then We encountered some crashes and we found that SEP had some global variables that did not work well with running it in multiple places at once. It would have been the same problem whether we were using StellarSolver or KStars to run SEP, but before this, we only ran it synchronously in one place at a time. So this wasn’t actually caused by StellarSolver but it was revealed during our integration of it. So while I was working on integrating StellarSolver itself, Jasem worked on making SEP non global. After the did that we were able to parallelize SEP and added a significant speed boost. Now it works pretty well.
Thank you very much for the additional features though, we can try adding that as an option!
Read More...
I might be reading this wrong, because it is fairly late in the evening for me, but it looks to me like this crash occurred in KStars during guiding, after StellarSolver returned the star list, but before the method to find the guide stars completed? Perhaps the list was still needed and it got deleted in KStars too soon? I will send this to Jasem and see if he agrees.
Read More...
You really would want to use one of my two build scripts, pretty much the exact one you copied in your post
github.com/rlancaste/kstars-on-osx-craft
But as of right now I need to make some updates to it based on the introduction of StellarSolver.
Right now I’m really focused on getting the StellarSolver all ready for the 3.5.0 release. It is a truly huge change that should fix all of the plate solving issues on Mac and Windows while at the same time making blind solves incredibly fast. But it is a lot of work. I have been working on it since February and I’ve been doing the integration work this October.
I will update the build script soon, And with that release a preliminary DMG. But I am trying to get all this worked out first.
Read More...
Yes, he changed both KStars and sent me a pull request for Stellarsolver today to change the way the package is installed and found. Apparently this change will fix a windows build issue.
Read More...
Yes, I was thinking that, and the fact that the "load and slew" images could be JPEGs, PNGs, GIFs, and other images that don't have scale or position. They could also come from different equipment. The capture and solve should have the same info most of the time.
Read More...
So based on what I am hearing, different options might be working better for the "load and slew" type function vs the "capture and solve" function?
Maybe it would be good to have two different sets of combo boxes in the Align options, a set of selections on which ones to use for "load and slew" vs a set of selections to use for "capture and solve"?
I ran some tests on some Images Jasem sent me that were taken with "capture and solve" and I found that they solved better on the default profile, however, for blind solves and load and slew, the Small Scale solving profile worked better.
Read More...