×

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: 152
  • Thank you received: 20
Welcome!
Caught a typo - those TSX settings work with both my cadiotrope (corrected dall-kirkham) and refractor (FSQ106).
3 years 5 months ago #61864

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

  • Posts: 2876
  • Thank you received: 809
I corrected a couple of things today. I finally got rid of those pesky messages that were being printed out to the console by the internal astrometry. I also corrected an issue with scale if you aren't using arc seconds per pix for the units. I also improved the logic for what happens when the solvers complete, which might make it stabler when it is doing a lot of operations. Please let me know if these changes help.

I think this might solve some issues where it failed to solve due to the scale
3 years 5 months ago #61872

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

  • Posts: 2876
  • Thank you received: 809

Replied by Rob Lancaster on topic I

I will next take a good look at the parameters that folks have shared recently as well as what was hard coded in kstars to see if we can improve the profiles more.
3 years 5 months ago #61873

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

  • Posts: 152
  • Thank you received: 20
Rob,

Is it possible the system parameters can be discovered through training on a set of data from the optics/camera in use? Perhaps make a tool that consumes a set of data and establishes a custom profile?

- Greg
3 years 5 months ago #61874

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

  • Posts: 219
  • Thank you received: 41
Hi Rob,

I've tried again the focalmm scale mode with the stacked image I've sent some days ago. It doesn't crash now, but it can't solve yet the image

The value for the arcsec/pixel seems wrong to me. For the 600mm focal length on my telescope and 5.70 microns per pixel, the image scale is 1.975 arcsec/pixel well outside the searched range
3 years 5 months ago #61875

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

  • Posts: 2876
  • Thank you received: 809
HI, is that this image?



I got it to solve with a blind solve. Did you say that it has focal mm info in it, or did you enter the scale in focal mm yourself to test it? As far as I can tell there is no position or scale information in the file.

I can definitely check the scale mm calculation. Usually images don't come with that scale information, they are usually in arc seconds per pix. So it probably hasn't been tested much yet.
3 years 5 months ago #61877
Attachments:

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

  • Posts: 2876
  • Thank you received: 809
I just investigated a little bit. The focal mm scale is not as simple as just entering your focal length.

So from what I found in a google search, that parameter is supposed to be:

"35-mm (width-based) equivalent focal length"

The calculation in astrometry.net code for converting this to arc seconds per pixel is pretty much this:

(Arc Sec Per Pix High) = rad2arcsec(atan(36 / (2 * (SCALE LOW)))) / (IMAGE WIDTH);
(Arc Sec Per Pix Low) = rad2arcsec(atan(36 / (2 * (SCALE HIGH)))) / (IMAGE WIDTH);

There is also a note in there that "35 mm" film is 36 mm wide.

So based on this information, if we have an image with a certain width, to enter the scale information for your image in order to solve it, we may need to know how wide your sensor is in MM so that we can figure out how that compares to 36mm. Then we can multiply your actual focal length by that scale factor to estimate what the scale should be.
3 years 5 months ago #61878

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

  • Posts: 2876
  • Thank you received: 809
So I did find in the fits header for your image that it was a canon 40D, which has a factor of 1.6. So I thought if we multiply 600mm x 1.6, we get 960mm. But then I tried that, it didn't work. So then I tried dividing it 600mm / 1.6 and I got 375. When I entered a scale range with focal mm surrounding this number, it solved.

So yes I think this is how we are supposed to use focal mm. But I don't know why I had to divide the focal length by 1.6 instead of multiplying. Maybe I'm just tired, but it seems backwards to me.

But anyway, we don't use focal mm typically in KStars and I have yet to see an image with that in the FITS header. So it's not urgent. Anybody have any ideas why it's this way?
3 years 5 months ago #61881

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

  • Posts: 219
  • Thank you received: 41
Yes, this one. I've never succeeded on it with a blind solve. I've tried again today with the same parameters that I can see on your screenshot and a fresh compilation from master

For the focalmm parameter, I thought that it was something you were using to convert from one range to the others. It seems that it's an astrometry parameter (with a very odd reference to full frame cameras), so I'll not use it for now :)
Last edit: 3 years 5 months ago by Rafa Barberá.
3 years 5 months ago #61886

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

  • Posts: 535
  • Thank you received: 109
@rlancaste @knro

Hi Rob, the latest merge to master is not playing well with the copr build. Realizing you may still be working on this, here is a link to the output if it helps: download.copr.fedorainfracloud.org/resul.../builder-live.log.gz

Jim
3 years 5 months ago #61969

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

  • Posts: 106
  • Thank you received: 4
I pulled the changes at 18:30 (UTC+2) from github.

I was not able to install stellarsolver by using the installStellarSolverLibrary.sh script because <QtConcurrent> was not found, which was introduced into the source code two days ago.
Instead I had to follow Ron's build-instructions found on his github page:

cd build
cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=RelWithDebInfo -DBUILD_TESTER=ON ../stellarsolver/
make -j $(expr $(nproc) + 2)
sudo make install

My files are solved blazingly fast.
Kstars still crashes if I try to solve M65 with downsampling.

By the way: what is the purpose of kstars new extractor branch?
Powered by

GNU / Linux
Git
KDE neon
KStars | EKOS | INDI

and some cheap hardware
3 years 5 months ago #61974

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

  • Posts: 2876
  • Thank you received: 809
"For the focalmm parameter, I thought that it was something you were using to convert from one range to the others. It seems that it's an astrometry parameter (with a very odd reference to full frame cameras), so I'll not use it for now"

It works just like the other scale units. Astrometry supports scales in several units degree width, arc minute width, arc seconds per pixel, and focal mm. KStars doesn't support the focal MM option, but astrometry does, so I thought stellarsolver should as well. I have yet to see any images though that have a scale in those units recorded in them, so I can't really test it to see if it works. The others. I can test easily because KStars and other programs use them all the time. Maybe someday someone will tell us if it works. Or maybe it is really falling into disuse so it doesn't matter anyway.
3 years 5 months ago #61975

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

Time to create page: 2.200 seconds