×

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: 333
  • Thank you received: 92
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

3 years 4 months ago #63078

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

  • Posts: 76
  • Thank you received: 5
I’ve been using the nightly build for the last couple of days. This would appear to include the new stellar solver update. Someone asked above if this does contain the most current release. I don’t think it’s been confirmed but it would appear so. This has been working well for me on the simulators. Clouds have prevented any real world testing for the last couple of days.

binary-factory.kde.org/job/KStars_Nightly_win64/
3 years 4 months ago #63081

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

  • Posts: 2876
  • Thank you received: 809
Han I will have to check that, it might be my recipe or it might be an issue with Craft. I believe on Windows it should be called StellarSolverTester.exe. I will test that later today and see if there was some sort of packaging issue. I would like to make sure the Tester's Mac Windows and Linux versions are all working great and easy to use and distribute.

But the good news is that it is fully integrated into KStars and the release should be happening in the next couple of days. Sorry it hasn't happened yet, I am the one holding it up, but I found a couple of extremely critical but unrelated bugs in the Mac version that I am sorting out. The KStars startup wizard wasn't working and for any new users that is critical!
3 years 4 months ago #63086

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

  • Posts: 2876
  • Thank you received: 809

Sorry, the 3.5.0 release of KStars has been held up a little. I'm working out some issues for Macs at the moment and I will have that done hopefully later today. To release a stable version we should make sure its stable :-). Right now the beta crashes on Mac if you run the startup wizard. I have the fix already implemented, but I will need to package it up and try it again later today.
The following user(s) said Thank You: Starman99
3 years 4 months ago #63087

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

  • Posts: 2876
  • Thank you received: 809
Han, you were absolutely right. Apparently I had made a mistake in an update I was making to the craft recipe for building the tester on windows. I updated it and rebuilt it. Then I updated the release with the correct binaries Please try it again.
3 years 4 months ago #63095

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

  • Posts: 333
  • Thank you received: 92
Ron,

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

Han
Last edit: 3 years 4 months ago by han.
3 years 4 months ago #63132

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

  • Posts: 114
  • Thank you received: 17
Rob,
I just updated my Raspberry Pi to the latest KSARS using the AstroPi3 script with the new StellarSolver. During testing with the simulators I kept getting failed to solve errors. I eventually realised that the reason for the failure was I had only downloaded the relevant index files for my 80mm x 500mm FL imaging setup, the default simulator scope setup at 120mm x 900mm FL would not solve as the relevant index files were not present. On the Astronomy.net solver it would flash a warning that the index files were missing. Would it be possible to add the warning message to StellarSolver? It may help out newcomers to resolve any setup issues.

I must say once I had changed the simulator telescope settings to match those of my imaging setup, it worked flawlessly on both GSC and uploaded images, very nice work indeed.

Many Thanks

Alan
3 years 4 months ago #63149

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

  • Posts: 106
  • Thank you received: 4
@El Corazon
you pointed me in the right direction.
Finally I used Synaptic to install libraw-dev while downgrading the libraw package.
Powered by

GNU / Linux
Git
KDE neon
KStars | EKOS | INDI

and some cheap hardware
3 years 4 months ago #63152

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

  • Posts: 2876
  • Thank you received: 809
Hi Alan,

So the message you are referring to was actually a function of KStars, not astrometry.net. Yes we could make it print that message again saying that you don't have the right indexes, but actually I didn't like that message because it was often incorrect. It would just say you don't have such and such index files even though you didn't need them for your image scale and I got tired of seeing that message. It is actually hard to say which index files you actually need to solve a particular field size. Yes, the index files are definitely meant for certain scales, and we could just do a table lookup based upon the scale size you/Kstars indicate the image should be and to just search for the index files with sky marks that size and the ones a little larger and a little smaller than your scale. But one issue you might encounter is that sometimes the index files that are significantly larger or smaller than your scale are the ones that actually solve the image. So it can be hard to say exactly which ones should be included. I did write an algorithm in the index file downloader a few years ago that attempts this. Maybe we could use similar code here. I mean I guess it is just a warning so you could ignore if it is wrong. We can look into it.

Thanks,

Rob
The following user(s) said Thank You: Alan Archer
3 years 4 months ago #63188

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

  • Posts: 114
  • Thank you received: 17
Rob,
Yes I see that, I have seen the message when I did have all the relevant indexes installed. Also what you have said explains why I found if I was slightly over generous when downloading the index files with Astronomy.net, the solving speeds actually improved. On a good night a first solve of 15 to 20 seconds and subsequent solves in 8 to 12 seconds. I wonder if the message could be made more of a basic / some type of prompt to check the installed index files, rather than just fail. It would act as a guide or starting point to sorting the issue of a failed solve.

By the way, we had the first clear night here for a few weeks last night and the new StellarSolver in KSTARS worked great right from the off, not a single failed solve during the session.

Many thanks

Alan
3 years 4 months ago #63198

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

  • Posts: 1119
  • Thank you received: 182


Rob,

The parallel solving speeds up the solver significantly (about 4-5 fold under my conditions). It now solves routinely in under 1 s on my Pi4/8Gb, but it takes up to 5 seconds otherwise. However, for this to work I need to restrict the astrometry files the Solver loads into RAM to a minimum. Since I am using a wide-field scope at 250 mm focal length, that is feasible on a Pi4. However, when I select all the astrometry files needed to solve on any of my scopes, including an 8" RC, then the file size exceeds the RAM available and solving slows down dramatically.
At the moment, I am managing this by manually moving the astrometry files that are not needed for my short focal length into a subfolder from which they are not loaded. I then can manually move them back when I am putting a larger scope on the mount.

What I am wondering is whether it would be possible for the Solver to just load those files it ANTICIPATES it needs for parallel solving BASED ON FOV into RAM and ignore the rest for first pass. Only when solving is unsuccessful, it would then include the remainder of the astrometry files for sequential solving.

That way, it would not be necessary for the observer to make that decision and then, if solving fails, having to move back larger astrometry files into the folder on which the Solver is looking for them.

I would think it should be possible to do that in an automated fashion?

Thoughts?

Jo
3 years 4 months ago #63206

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

  • Posts: 2876
  • Thank you received: 809
Jo,

This is certainly a good idea for the future, but right now unfortunately it might be kind of hard to implement. As I mentioned, it is slightly hard to say exactly which index file will solve any particular image. You can say that certain index files tend to work pretty well with a certain setup for sure, but you never know with certainty which exact one will solve it. So then the question would be, how would we determine which indexes to load? Do we load just the ones closest toe the scale we think it is? How much bigger or smaller do we go? Should that be somehow user configurable?

Also I would want to make sure that whichever way we do this for the internal solver, it will also work for the local solver as well. Right now, both the internal and external solvers are configured to just load all the indexes the given folder list. It is certainly possible to load just specific files for both the internal and external methods, but that would require a significant change to the code. Right now the only options are "load all the indexes" or don't do it and load them sequentially. I have considered a third option to have it automatically determine which one to do. This would be like a fourth option?

Another problem is that I'm not 100% sure that the RAM calculation that I have in there is perfect yet. It is supposed to shut off the "load all indexes in memory" option if there is not enough RAM. Before we would play with loading only certain indexes, I would want to be certain that that calculation works.
3 years 4 months ago #63242

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

Time to create page: 1.109 seconds