×

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: 388
  • Thank you received: 17
It behaves the same downloading it from your website, well actually not as it sends me to Sourceforge.
Ron
Last edit: 3 years 9 months ago by Ronald Scotti.
3 years 9 months ago #54900

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

  • Posts: 388
  • Thank you received: 17
The window version downloads and runs ok as the new version. But I have not loaded the indices on windows.
Ron
3 years 9 months ago #54901

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

  • Posts: 333
  • Thank you received: 92

Hello Ron,
The file name is astap_armhf.deb It's for the 32 bit (Raspbian) operating system. I normally just use the operating system installer. Using the file manager, right mouse click on the file and then select "Package install". I checked the file on SourceForge but it installs normally. I have packed it again and uploaded it but it will make no difference

sudo apt install ./astap_armhf.deb

should also work.

Han
3 years 9 months ago #54903

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

  • Posts: 388
  • Thank you received: 17
Somehow missed the './' before the file name in the notes from my previous installation.
I think I was able to unpackage it using tar and running the pre/post install programs and unpackaging data.tar.xz. But it was messy and I now have it in a subdirectory of Downloads. So I will try your procedure again.

thanks,
Ron
3 years 9 months ago #54904

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

  • Posts: 388
  • Thank you received: 17
Han,
the package install worked and it was too easy!

thanks,
Ron
3 years 9 months ago #54905

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

  • Posts: 333
  • Thank you received: 92
This morning I did some accuracy testing.

I Included also PlateSolve2 and Pinpoint. The solved positions of the solvers do all match with a fraction of a pixel. Small difference could be explained by the different catalogs used. Only one significant error in the option Ïnt sep Ext. ASTAP. This is exactly one pixel in x, y and I could trace it back to a mistake I made in converting the Source extractor table fits position [1..] to my arrays [0..] I have corrected in the ASTAP source for next issue.

But one other thing is not fully correct. The pixel scale indicated by SexySolver and Classic Astronomy seems too high. The value also doesn't match with the field width. Take the solution of Classic Astrometry:

Image dimensions 2328 x1760 pixels
Pixel scale as measured 2.70354"
Field width as measured 1.742 degrees => pixel scale should be 1.742 * 3600/2328 = 2.6938", so the indicated pixel scale of 2.70354"seems 0.36% too high. The same too high value is presented if I upload the image to nova.astrometry.net/user_images/3710187#original nova.astrometry.net . However if I calculate from the Astrometry.net solution the pixelscale as sqrt(sqr(cd1_1)+sqr(cd2_1)) I get 2.694395"

Han




Image involved:
nova.astrometry.net/user_images/3710187#original
Last edit: 3 years 9 months ago by han.
3 years 9 months ago #54918
Attachments:

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

  • Posts: 333
  • Thank you received: 92
Here an image near the celestial pole. The orientation is wrong:

nova.astrometry.net/user_images/3710784#original


3 years 9 months ago #54924
Attachments:

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

  • Posts: 2876
  • Thank you received: 809
3 years 9 months ago #54926

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

  • Posts: 333
  • Thank you received: 92
Hello Rob,

The problem most likely is the reference point. Astrometry.net doesn't always take the center pixel as reference. For example this image:

nova.astrometry.net/user_images/3711435#annotated

The online version and Sexysolver takes as reference pixel CRPIX1= 3342, CRPIX2=1697. Then you get an orientation of 134 degrees.

ASTAP always uses the image center as reference pixel. In this case CRPIX1= 2328.5, CRPIX2= 1760.5. This gives an orientation of -179.1 degrees

Both solutions are correct. The orientation changes very quickly due to the nearby celestial pole. (I had to fix an error in ASTAP, so you need 0.9.370 for this)

Best is to force Astrometry.net with option:

--crpix-center
Set the WCS reference point to the image center

Han



Astrometry.net solution. Look to annotation of NP and Polaris and angle & CD1_1, CD2_1 in header


ASTAP solution. Look to annotation of NP and Polaris and angle & CD1_1, CD2_1
Last edit: 3 years 9 months ago by han.
3 years 9 months ago #54932
Attachments:

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

  • Posts: 388
  • Thank you received: 17
I downloaded that NCP image, but I am not getting it to solve in ASTAP. What settings did you use? I have 0.3 FOV, 20 ,10,0.5,G18 no calibration?

thanks,
Ron
3 years 9 months ago #54939

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

  • Posts: 333
  • Thank you received: 92
The last image PolarAlign_213425_1..... Just load it in ASTAP 0.9.370 (Mac, Linux)
Last edit: 3 years 9 months ago by han.
3 years 9 months ago #54943
Attachments:

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

  • Posts: 1009
  • Thank you received: 133
In doubt also check what you use for position, as that also distinguishes between position of the reference pixel, and position of the center pixel. Had been fooled by that, too...
3 years 9 months ago #54985

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

Time to create page: 2.197 seconds