rlancaste wrote: Thank you for doing some testing!

You are very welcome. It's the least I can do to help out. If only I knew C++... Another year perhaps.

I am confused by your first issue: "BTW - when testing with the simulators I left the Solver Action as "Nothing" but the slew still occurred". I think this is a miscommunication in the interface. If you clicked the "Load and Slew" button then it is always supposed to slew to the target. The selections for the Solver action are only applicable if you click "Capture and Solve"

Agreed that it is probably an interface communication issue. It would probably be better to have the button as "Capture & Solve", "Load & Solve" with the Solver Action section giving options "Slew To Target", "Solve Only", and maybe a checkbox for "Sync" in cases where people want the slew and sync to happen. Probably outside of the scope of this topic though - I was sharing as an FYI.

" after the unwanted slew, the Load and Slew button was now greyed out." So was this after it arrived at its target after the slew you mentioned? The buttons should be disabled while it is slewing, but after it gets there they should re-enable. If not, that could be a KStars bug.

Correct - The slew occurred and failed (because I'm using sims and don't have images set up I guess). The Load and Slew button stays greyed out - only the Capture button can be activated.

" image has some problems including mystery stars". Do you mean that it detected noise as stars? This is certainly possible depending on your selected options profile. We are trying to develop better options, but they aren't quite perfected yet. Did you only try the one profile or did you try any others?

Nope - that first image has some "mystery stars" in them that are not present in other images of the same object. My guess is this is a residual bulk image problem that came with switching the camera's mode? Not sure though. I guess the point is that the solver performed well in spite of these mystery stars. I was surprised it didn't confuse the solver.

"However, this one of the same field does not solve. The main differences I can determine is the median signal of this frame is higher than the other two and the image is rotated 180deg from the others." I downloaded this file and it solved quickly. Which profile are you using to solve?

I'm using whatever default was selected when I built the software with SS included the first time. Looks to be 4-ParallelSmallScale. I find it interesting that some of the images of the same object with similar characteristics solve, but some do not. Maybe these images are right at the edge of some threshold.

" Interesting that it says it needs 19.7GB of RAM. Is that true?" So the way astrometry's "load all indexes in parallel" option is supposed to work is that it loads all your index files into memory simultaneously, at least according to their documentation. This of course will make it much much faster than loading each index file one after the next. But if you have bigger index files than available RAM, this could be serious problem. I am not sure that it always will use that much RAM and if you have SWAP files or ZRAM, that could certainly prevent any crashes that could occur from taking up all the RAM, but I don't want to risk crashes, so in the code right now I calculate how much RAM there is and how big the indexes are and report that and disable the option if it is too much. We can play around with that to see if it really does take that much, but for now, I'm being cautious.

Gotcha. Happens to be I have 32G in this PC and I had forgotten about that detail. It's working, and it's fast enough that by the time I switch back to the Ekos window after loading an image that it's already solved. I'll have to try this out on lower memory systems soon.

Thanks again for your work on this!

Greg

Read More...