Thank you for sharing!
Interesting: The only difference between your and my settings is the flag "Use Scale" in the third screen. In my options, this flag is set. If I clear the flag, Kstars chrashes to desktop everytime when I load my fits-file. If I set the flag, it does not crash, but solves for ever...

I uploaded this fits-file to dropbox, I hope this link works:

www.dropbox.com/s/mpjpkqka3aqyf3b/Light_006.fits?dl=0

Maybe you want to try if you can solve that image by using "Load & Slew".

Downloaded your fits file and set up a simulator with 135mm lens and Canon 6D parameters...... no success at solving I'm afraid .... just solver running continuously. Ran out of patience before letting it time out.

Thank you for that cross check!

Now I know that it makes no sense to reinstall astroberry or anything like that. The problem seems to be the fits-file itself or or the large scale of the combination of 135mm lens with full frame sensor!

Compared to my previous version of kstars this one seems to suppress any debugging information of the alignment module, even if verbose mode is selected. That makes it hard to figure out the problem...

I am considering to use a local ASTAP or Astrometry installation instead of StellarSolver. Although StellarSolver should be based on Astrometry, solving my image on online Astrometry is no problem.

Hi Ben!

I thought I'd give the puzzle a try. I set up a simulator configuration with the specs for the Canon EOS 6D (I'm not a Canon shooter so apologies if I got some of this wrong). I originally set things up with the sensor specs for the Mark II assuming a 4x3 aspect ratio and the Solver solved the image. When I looked at the FITS header for the file you provided it appears that you are actually using the original 6D which has different pixel dimensions of course. When I input those specification, the solver failed each time. It never took longer than 30 to 60 seconds to fail - I didn't seem to have the problem of it running without stopping. I'm not sure what the INDI control panel shows for your camera but, based on your reported FOV, mine was pretty close (after I put in the 'correct' sensor data into the simulator) at 906.0' x 606.0'.

Can't explain why it seemed to work when I had the wrong sensor spec in the simulator. The solution the Solver achieved was very close to the information in the file's FITS header. I'm using 3.6.3 FWIW.

Good luck!

I just took a loot at your file.

The reason it fails to solve is because the position information in your file is way off. In your file it says the coordinates are:

RA 23:58:43
DEC 89:52:24.6

I did a blind solve (uncheck the "use position" option and it solved almost instantly. The coordinates are:

RA: 03:43:08.552
DEC: +23:59:15.135

Also note that I would have used my LargeScale option because the scale looks really large in your image, the solver agreed, it said:
942.405 x 630.679 arcminutes

But that being said, you did have a reasonable scale in the fits file. It said 7.9 - 11.99 arc seconds per pixel and the solver said it was actually 10.4" per pixel. So unchecking use scale would have had no effect, since the scale was fine.

So I would use the large scale solving option, and either correct your coordinates or uncheck "use position"

Thanks,

Rob

Rob - your post got me to try this again. This time I did it with the right sensor data to begin with and I got a solution in under 3 seconds (I can't explain why it failed with these settings when I tried it earlier). But, my answer was very different from yours. Then, to simulate what you did, I unchecked "Use Position" and I got an answer very similar to yours.

In a strange outcome, I selected "Use Position" again and Solver failed almost immediately. Then I again unselected "Use Position" and I got an answer right away.

Do you have any guidance on when to select "Use Position"? From the tool tip, it indicates that selecting it should speed up the solver although it seems to create some challenges of its own.

Thanks!

The important point is that certain settings, like which profile to use, or whether to use position, or whether to use scale, can certainly speed up the solver, they also come at a cost. If you tell it to use the scale or position, but the scale or position you give it is really incorrect (outside the range of error your profile considers acceptable) then it will not solve at all. So if you find it is not solving, then unselecting or changing those parameters can allow it to solve. My suggestion is to use the profile that tends to work best for you, and to leave the scale and position options turned on. But if it does fail to solve, uncheck them and try again.

If I had to take a guess based on the RA and DEC in the file you posted, what you may have done was that the scope thought it was pointing north, but then you moved it to the target without a slew command perhaps, so it thought was still pointing north but really it was not. This is just a guess. As a rule I turn on my mount in the home position, then I slew to a bright star, then I plate solve, then I go to my target and plate solve again.

I followed Rob’s advice on your behalf Ben. I unchecked “use position” - and the solver completed after 41.11 seconds!

Thank you for putting so much work into my problem! I really appreciate your results!

Unfortunately I cannot reproduce them, because KStars keeps crashing if I disable "Use Scale" or "Use Position". I think you found the problem in my file, but it seems that I have another problem with my installation. Are all of you running KStars 3.6.3? For me, 3.6.0 is the latest version it wants to upgrade to.

The reason for the wrong coordinates in the file is, that I made this image with a Star Adventurer setup without goto. So as you suggested I moved manually to this position while Kstars was pointing to another position.

Ok, just right now it solved instantely using "LargeScaleSolving" and "Use position" disabled! After that it crashed again, but now I have the first solved image today!

I really do not know why, but when I use the options you recommended and additionally switch the solving method to "Local Astrometry" it seems to work without crashes!
So this seems to work for me:



Thank you very much for the help!