Hi Rob,

Now, it didn't crash, but it didn't works. I've stoped it after more that 10 minutes trying a blind solve. Then I tried to guide it adding limits to the focal length and then crashed. Also, as you have merged this branch (instead of squashing the changes into a single commit) it's almost imposible to revert the app to a point before the change. I've trapped my self into a corner : I can't revert to the oficial 3.4.3 because there is a problem with the OnStep driver and I can't go to the current nightly because the Solver is not working on the RP4 build.

rbarberac,

I thought you had ran that image in the StellarSolver tester program before and that’s what I thought you were going to test for a good comparison to see if it is fixed. Could you try that? The issue with the image you sent was that it was a float image and the SEP code in StellarSolver handled it slightly differently than the other types. I just corrected it so it does them all the same way. It solved fairly quickly.

It sounds like this time you tried it in kstars. You said it didn’t work, can you provide details of how you tried it? Did you try different ways ?

I didn’t make any kstars changes for this image, so if there was a similar or related bug somewhere in kstars I haven’t corrected it.

But I would need more details to know first if the issue is solved in StellarSolver or not for your image. And then second if there is some sort of issue in kstars, what might it be related to?

Thanks for your help,

Rob

I think the point rbarberac was getting at is we use kstars/ekos as the tool for our imaging and Stellarsolver is now the "way" in kstars so that's how we test it.

@rbarberac go back in time in git to just befor Jasem did the "big" Stellarsolver check-in and down load a zip of those files. Make a ~/Stable directory and
build/install from that if you are doing actual work. It's how I unpainted myself from the same corner as you find yourself.

Hi jackbak,

Sorry, in my post I was addressing the first part of rbarberac's post, not the second part. As for the second part, I definitely apologize if the integration of StellarSolver into the main KStars repo before it was totally ready has caused anybody any issues. I agree that we weren’t really ready to put all this in KStars master right away, especially because people rely on the master branch of the repo for nightly builds, and we needed to test it thoroughly before putting it in master. I was hoping for more of a testing time period where people could test this on my fork or maybe in a different branch in the main repo and we could have a nice discussion about how to improve it before putting it in the official KStars Master repo. But, let's not be too hard on Jasem for that, he is a great guy and works incredibly hard to support KStars and INDI and us. It has caused a little more pressure on me to fix all these problems and get it all integrated, and maybe that was a good thing, because I had mostly finished StellarSolver back in June, and I was not integrating it into KStars very fast at all. This has pretty much lit a fire under me to get it done. We already did complain to him about putting it in the main repo so quickly, but it really has worked to get things up and running. So instead of focusing on that, now that its done, let's work really hard to polish everything up and get it ready for release. Please keep testing and I will keep trying to perfect things with StellarSolver and its integration with KStars for the release. And again I am sorry if the integration has caused anybody any issues because it wasn’t ready yet.

Thanks,
Rob

No, I was not being critical, sorry if it came off that way. I DO appreciate all the work everyone puts in. I mostly wanted to help rbarberac out of his corner.

Thanks all!
Jack

For my part, I'am fine.
“The only constant in life is change”
-Heraclitus
I apologize, could not resist.
Rob, thanks for your nice write-up. This should help in finetuning the settings. But could you please put somewhere in your code a qInfo() or cout to show the number of stars found after star extraction? This would help the user to make an educated guess which change of the settings went into the right direction; I hope.
If you run kstars from the console or within vscode pp there is some kind of feedback:
log-odds ratio 6.44164 (627.432), 0 match, 0 conflict, 0 distractors, 48 index.
RA,Dec = (278.296,32.34), pixel scale 0.690121 arcsec/pix.
Could you please explain what is the important part and how the user can influence these values.
And, perhaps, could you ingeniously put in some code to narrow down the search region?

I also went back to the last commit before the big change ( 7120f95a1485936df38cc4f16b1e1f5c5e3f5dc0 ) and compiled a separate installation from there. All I needed to do when building from source was to change the one line 'git checkout master' to 'git checkout 7120f95a1485936df38cc4f16b1e1f5c5e3f5dc0'.

Rob, please correct me if that is the right procedure. Kstars compiled and started fine after that, so I assume this should do it. However, I have not tested this yet. Somehow, I feel compelled to bend that rambunctious Stellar Solver to my will. But for the time being, Stellar Solver seems to be winning at least half of the time...

After a few initial crashes caused by the Solver, kstars ran fine through the night. Stellar solver seems to be very picky when it comes to what frames it likes to solve when using 'Load and Slew'. Eventually I found one that worked (from the previous night, they should all have been the same) and it did not crash during after flip realignment, so I had a very productive night with the latest pull from last night.

Jo

Actually it should print the number of stars found both before and after filtering when the source extraction is done, if you have the correct logging turned on. I can check, but maybe it f you are using parallel solvers that doesn't print. I know it does if you have "Alignment" logging turned on in the Ekos log options and if you solve using FastSolving or another profile that doesn't use a parallel algorithm.

And please ignore all the log odds messages that print. its part of the calculations that astrometry is doing internally. I would like to totally disable that unless the user wants logging turned on. I believe that is supposed to print if you have logging set to Log MSG, Log VERB, or Log ALL but it still seems to print even if you have it set to log NONE. I haven't yet figured out how to turn it off because even if you set the log level to none in astrometry. it still prints. I may have to make another change in the astrometry code to get that to go away. I was considering that a less critical problem to attack but I do want to fix it.

Also, I wouldn't recommend setting logging for Astrometry to Log ALL, unless you turn on my option to save it to a file. There is just WAY too much information. I think I will add some sort of warning to KStars to prevent users from doing this.

El Corazon,

Please note that there was an issue with loading float FiTS images and doing SEP on them which I fixed yesterday, so if that was the issue, you should update StellarSolver. If you have an image that it didn't solve using the updated KStars and StellarSolver today using load and slew, please send it to me so I can check.

Thanks,

Rob

Hi Rob,

Sorry for my delay, I live on Europe (Spain), and I can not expend too much time during working day. I'll test it throughly latter today.

Yes, yes, I'm testing exclusively with StellarSolverTester. I've opened the file and press start without any other change. Latter I've found that it was trying yo use the profile 5 (I've stopped it after waiting for 10min). Then I've tried with profile 5 and I've seen different process end without finding a match. I've stoped it after 4 minutes. Then I've tried to put limits on focalmm (550 to 650 for a 600mm real focal length) and it crashed very quick.

About the first problem, the crash when I press the solve button, yes, it now solved.

Thank you very much for all your effort!

Rafa

Nobody is being hard with nobody. At least not me. I'm aware that I've put myself on this problem not Jasem or you, Rob, don't worry.

In my case I've get a perfect storm scenario: a bug on OnStep driver that don't let me use the official build, a new platform (I've recently changed from macOS to RP4) and my insane curiosity about code

Rafa

Jo, thanks for your help. I was aware on how to go back on git, this was the reason I've told Rob that perhaps, this kind of changes will be best applied as a squashed commit. Because as its currently merged, if you go back in time, you will not recover exactly the same repo. I hope, that as you have found in your compilation, the leftovers doesn't interfere too much with the rest.

But I'm starting to put my feet on thin ice, because I that I'm not working actively on the project, should not be talking about its dynamics... sorry, it's a professional deformation

Ok, let's go to help stabilising the product. Rob if you need any other test, or do you think that I can try something, please, don't hesitate to ask me

Rafa