Celestial navigation

[Sharaf Z. Muhanna]

Hi Dustin,

I’m new to the astronomy field, and after obtaining the RA and DEC from an image, I’m unsure how to compute the latitude and longitude from them. Is it possible to use Astrometry.net for this, or would you recommend a different approach?
I would appreciate any guidance or recommendations you can share.  

Thanks 

[Dustin Lang]

Hi,

You can try searching this group for previous posts on the topic.  I think it has been covered before.

To go from RA,Dec to lat/long, you need the time and probably the alt/az of the image.  Nothing in the Astrometry.net package deals with time -- you would need to use something else, perhaps astropy or some other software, to do that.

cheers,

dustin

--
You received this message because you are subscribed to the Google Groups "astrometry" group.
To unsubscribe from this group and stop receiving emails from it, send an email to astrometry+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/astrometry/9e422448-7d26-4f0f-b771-4c19f50f1c58n%40googlegroups.com.

[Shen Ming]

If you're using a telescope, I think you need write the telescope pointing info (altaz) and time into the same fits header.

If you're doing some integrated navigation with IMU-like modules, please refer to this paper:

Autonomous positioning utilizing star sensor and inclinometer - ScienceDirect

[Sharaf Z. Muhanna]

Hi Dustin,

I’m using the API to calculate the RA/DEC for about 3,000 images, but the process is very slow. How can I use your solution to speed up the calculations? Do you have any recommendations?

[Sharaf Z. Muhanna]

Hi bubu
I am using camera

On Thursday, December 4, 2025 at 12:48:52 AM UTC bubu...@gmail.com wrote:

[Dustin Lang]

Hi Sharaf,

Can you send a link to an example of the images you are solving?  We can probably recommend settings to speed things up.

cheers,

dustin

To view this discussion visit https://groups.google.com/d/msgid/astrometry/998bd9cf-6858-44c2-b663-b7da38fd2659n%40googlegroups.com.

[Bryan]

When you say 'very slow.'  how long is a single image taking to solve?

Are you using the online version of astrometry.net?  Installing it locally and using that allows more options in setting the tuning parameters and is MUCH faster.

Bryan

[Sharaf Z. Muhanna]

[Sharaf Z. Muhanna]

it take around 5 minutes for each image and I have 3,000 images

[Eric SIBERT]

Dustin was asking you for a link to the online solving like:

https://nova.astrometry.net/user_images/14239354#original

Looking at your pictures, they don't seem to be real sky pictures. It
may disturb the solver, especially when trying to order stars by
magnitude. What kind of treatment did you applied?


Eric


"Sharaf Z. Muhanna" <muhann...@gmail.com> a écrit :

> On Monday, December 8, 2025 at 2:31:00 PM UTC dstn...@gmail.com wrote:
>
>> Hi Sharaf,
>>
>> Can you send a link to an example of the images you are solving? We can
>> probably recommend settings to speed things up.
>>
>> cheers,
>> dustin
>>
>>
>> On Mon, Dec 8, 2025 at 7:28 AM Sharaf Z. Muhanna <muhann...@gmail.com>
>> wrote:
>>
>>> Hi Dustin,
>>>
>>> I’m using the API to calculate the RA/DEC for about 3,000 images, but the
>>> process is very slow. How can I use your solution to speed up the
>>> calculations? Do you have any recommendations?
>>> On Thursday, December 4, 2025 at 12:48:52 AM UTC bubu...@gmail.com wrote:
>>>
>>>> If you're using a telescope, I think you need write the telescope
>>>> pointing info (altaz) and time into the same fits header.
>>>>
>>>> If you're doing some integrated navigation with IMU-like modules, please
>>>> refer to this paper:
>>>> Autonomous positioning utilizing star sensor and inclinometer -
>>>> ScienceDirect

>>>> <https://www.sciencedirect.com/science/article/abs/pii/S0263224118308005>

>>>>>> <https://groups.google.com/d/msgid/astrometry/9e422448-7d26-4f0f-b771-4c19f50f1c58n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>>> .

>>>>>>
>>>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "astrometry" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to astrometry+...@googlegroups.com.
>>>
>> To view this discussion visit

>>> https://groups.google.com/d/msgid/astrometry/998bd9cf-6858-44c2-b663-b7da38fd2659n%40googlegroups.com
>>> <https://groups.google.com/d/msgid/astrometry/998bd9cf-6858-44c2-b663-b7da38fd2659n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .

>>>
>>
>
> --
> You received this message because you are subscribed to the Google
> Groups "astrometry" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to astrometry+...@googlegroups.com.
> To view this discussion visit

> https://groups.google.com/d/msgid/astrometry/61aa2e89-bfaf-417c-bd50-606bc518983cn%40googlegroups.com.

[Dustin Lang]

Hi,

These are very wide-field, so if you set the "--scale-units degwidth --scale-lower 30" it should run a bit faster.

Or, for these wide-field images, you will not need very many index files to work well -- the "4100-series" should work great -- https://data.astrometry.net/4100/ .  There are some instructions on how to use Docker to run locally, at  https://github.com/dstndstn/astrometry.net

cheers,

dustin

[Sharaf Z. Muhanna]

  I built the real-world simulation, and I captured these images from it  

[Sharaf Z. Muhanna]

  The field of view for my images is 50 degrees. The issue now is that I need to obtain the RA/DEC for all 3,000 images, but the API key request takes time and the website’s server has crashed.  

[Astro Keith]

I would suggest using Tetra3 instead. With large fields of view it should solve in fraction of a second.

You would need to build a local copy and generate a suitable index database file (the utility is built in)

But your images do look very strange - do they actually represent real sky? I cannot identify a single asterism or constellation.

[Sharaf Mohanna]

I have a project where I estimate an Earth location (latitude and longitude) from star images. I started with a simulation and built a Unity environment that generates a realistic sky with correct star motion over time. The simulator also provides ground-truth latitude and longitude.

In this setup, I use a moving camera with a 50° vertical FOV and 73.74° horizontal FOV. I developed an astronomy-based pipeline that uses the astrometry.net 4100 index series to solve each image and extract the RA/DEC. Then, using RA/DEC together with the UTC timestamp, I estimate the camera’s latitude and longitude.

Main solve-field settings:

• --downsample 2

• --scale-units degwidth with --scale-low 75 and --scale-high 110

• --objs 200

• --cpulimit 180

After processing around 640 sky images and comparing the estimates with the ground truth, I obtained an error of about RMSE = 72,999.03 m (as shown in the plot). I also attached some sample simulation images.

I’d appreciate advice on improving accuracy. Should I reduce the FOV, or would you recommend using a different index/catalog? Which parameters or steps in my pipeline are most likely causing the large error, and what changes would you suggest to reduce it?

Finally, I can share the CSV output from my algorithm, which includes the extracted RA/DEC, the estimated latitude/longitude, and the corresponding ground-truth values.

On Monday, December 8, 2025 at 3:47:47 PM UTC dstn...@gmail.com wrote:

[Dustin Lang]

Adding

--crpix-center

will probably help.

How strong is the distortion in this lens?  It might help to build a really good model of it and use the --predistort option.

cheers,

dustin

--
You received this message because you are subscribed to the Google Groups "astrometry" group.
To unsubscribe from this group and stop receiving emails from it, send an email to astrometry+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/astrometry/59e467a0-c2bd-470e-bb2c-8fa5d491e7ebn%40googlegroups.com.

[CaptAndy Sir]

how do you estimate star altitudes?  error of a degree can be 60mn

[Sharaf Mohanna]

Hi Dustin,

Thanks for your response and sorry in advance, I’m still new to Astrometry.net and I’m not fully confident I’m using it correctly, so I’d really appreciate your guidance.

As I mentioned, I installed Astrometry.net locally and I have about 637 images that I need to solve offline. I’m using the 4100-series index files (the ones you recommended): https://data.astrometry.net/4100/.

I have a script to run solve-field. My camera FOV is about 50° vertical and 95° horizontal, and I’m currently using these arguments:

SOLVE_ARGS = [
    "--overwrite",
    "--dir", SOLVED_DIR,
    "--downsample", "2",
    "--scale-units", "degwidth",
    "--scale-low", "75",
    "--scale-high", "110",
    "--backend-config", BACKEND_CFG,
    "--objs", "200",
    "--no-plots",
    "--cpulimit", "180",
]

My issue is that the local solutions sometimes differ from the Astrometry.net website output for the same image, the websit more accurate. Since I use the solved RA/Dec to compute longitude/latitude, even a small RA/Dec difference can lead to a very bad location result.

Could you please advise on:

1. How can I make the local solve output match the website output as closely as possible?

   • Are there any specific flags, index files, or solver settings that the website uses that I should replicate locally?

2. I’m extracting RA/Dec from the local astrometry output using my own code.

   • Could you please check my approach and tell me if I’m doing it correctly?

   • I attached the code I’m using to compute RA/Dec — if you already have a reference script that does the same thing reliably, I’d really appreciate it if you could share it.

3. My camera is always aligned toward the zenith, but I’m capturing images on a boat so the camera orientation changes due to ocean waves.

   • Does the camera orientation (roll/pitch) affect the RA/Dec output, or should RA/Dec remain correct as long as the field is solved?

Thanks again for your help, I really appreciate it.
Best regards,

[Dustin Lang]

Hi,

- can you please give an example where you think the website result is different than your local result.

- why do you think it is more accurate -- how are you deciding that?

- what settings are you using with the website?

- it would probably help to add "--crpix-center" -- on the website, use the "CRPIX Center" checkbox in Advanced Settings.

- your RA,Dec center code looks fine. (as long as astropy is correctly using the SIP coefficients - I think it does).  The "wcsinfo" program in the Astrometry.net code can be used to print a bunch of information.

cheers,

dustin

To view this discussion visit https://groups.google.com/d/msgid/astrometry/b05e5f97-ef4e-4a7f-980e-4a00dfffeadcn%40googlegroups.com.

[Sharaf Mohanna]

Hi Dustin,

Thanks for your help.

Website settings
I used the default Astrometry.net website settings to solve for RA/Dec and didn’t change any parameters.
I’ve attached a screenshot of the settings page just for clarity.

Why I think the local result than differant 
I reached this conclusion by directly comparing the RA/Dec centre values from the website with those from my local Astrometry.net pipeline for the same images. As you can see in the attached table, there are noticeable differences between the two results for several images.

For example:

• skybox_62.png shows a large difference in both RA and Dec between the website and local solutions.

• skybox_72.png fails on the website, but it is solved successfully when I run it locally.

• skybox_248.png and skybox_605.png also show clear differences in Dec between the two approaches.

I’ve attached the comparison images for your consideration.

Best regards,

[Dustin Lang]

Hi,

On the web site you should definitely set the "Very wide field" option.  That will easily give an answer for #72.

https://nova.astrometry.net/user_images/14564105#annotated

The web site finds that solution in index-4118.fits

I don't know why you are not getting a solution in your local solve of 72.  I just tried it with the 4100-series index files and I get a solution:

solve-field --scale-units degwidth --scale-low 75 --scale-high 110 ~/Downloads2/skybox_72.png --config ~/data/INDEXES/4100/cfg --crpix-center --downsample 2 -v --objs 200 --continue

Maybe turn on the "-v" verbose option and send the log that it prints out.

Synthetic images like these should be very easy to solve.

cheers,

dustin

To view this discussion visit https://groups.google.com/d/msgid/astrometry/ecb6a69b-a5f9-4771-872e-675cf635ce67n%40googlegroups.com.

[Sharaf Mohanna]

Did you get the same output for the 72 image when you use the local and the website?

Also my camera fixed on the boat during the simulation and move forword over the ocean waves and choppy condition.

Since the boat is moving and continuosly changing its oriantation and camera angle do you think this effects on RA and DEC outputs?

[Dustin Lang]

When I remove the "--objs 200" then I get exactly the same result as the web site.  (I think the web site does "--objs 1000")

You are doing the simulation so you should know what the RA,Dec pointing of your simulated camera is....?

If the Altitude changes (ie, not pointing straight up) then clearly your RA,Dec is going to change.

If only the Azimuth (rotation angle) changes, then the RA,Dec center should not change.

cheers,

dustin

[Sharaf Mohanna]

I ran the solver locally using the 4100-series index files and obtained a valid solution with the following command:

solve-field --scale-units degwidth --scale-low 75 --scale-high 110 ~/Desktop/image_72_test/skybox_72.png --config ~/astrometry-index/backend_4100.cfg --crpix-center --downsample 2 -v --continue

I then extracted the RA and Dec from the resulting .new file using this Python code:

"python3 << EOF
from astropy.io import fits
from astropy.wcs import WCS

# Read the .new file for image 72
with fits.open('/home/sharaf/Desktop/image_72_test/skybox_72.new') as hdul:
    w = WCS(hdul[0].header)

    # Image center in pixels (1920x1080 image)
    x_center = (1920 + 1) / 2.0  # 960.5
    y_center = (1080 + 1) / 2.0  # 540.5

    # Convert pixel coordinates to RA/Dec
    ra, dec = w.wcs_pix2world([[x_center, y_center]], 1)[0]

    print(f"Skybox 72 - RA center: {ra:.6f} degrees")
    print(f"Skybox 72 - Dec center: {dec:.6f} degrees")
EOF
"

This gives:

• RA: 357.538207°

• Dec: 0.500619°

However, when solving the same image using the Astrometry.net website, I obtain:

• Center (RA, Dec): (357.481°, 0.561°)
  https://nova.astrometry.net/user_images/14567294#annotated

• 
  I get exactly the same result as the web site
  

• maybe I am doing something wrong please I need your help

[Dustin Lang]

Set the "CRPIX in Center" option on the web site.

That's only about a 1-pixel difference.

cheers,

dustin

[CaptAndy Sir]

so, is it stabelized and point zenith, or does it roll and pitch with boat?  star altitudes from a ship are taken with a stablized (by the aiming of the observer) sextant.  even large ships can often have significant (for ra dec calculations) roll.

1. My camera is always aligned toward the zenith, but I’m capturing images on a boat so the camera orientation changes due to ocean waves.

   • Does the camera orientation (roll/pitch) affect the RA/Dec output, or should RA/Dec remain correct as long as the field is solved?

[Dustin Lang]

Hi Sharaf,

(maybe you want to forward your message to me to the list, for context)

The radius of the Earth is about 6000 km.  So if you look at two points on the surface that are 100 meters apart, the angle from the center of the Earth to those two points is

(100 m / 6_000_000 m)  radians

or about

0.001 degrees

or about

3 arcseconds

The images you are using have pixels that are about 200 arcseconds in size.  So you would need to get the RA,Dec center to about 0.01 pixels.  That is going to be _extremely_ difficult.

cheers,

dustin

[Sharaf Mohanna]

yes camera always algined with zenith I do not want to use  sextant only I want to use camera
thanks 

  "so, is it stabelized and point zenith, or does it roll and pitch with boat?  star altitudes from a ship are taken with a stablized (by the aiming of the observer) sextant.  even large ships can often have significant (for ra dec calculations) roll."

[Sharaf Mohanna]

Hi Dustin,

Thank you very much for your explanation and continued support, it was very helpful.

I would really appreciate your advice on how best to improve the accuracy of my algorithm and simulation. Based on your comment, my understanding is that the current limitation is mainly due to the angular resolution (arcseconds per pixel).what you recommend me to do? Would you recommend narrowing the camera field of view in the simulation to improve accuracy? This is something I can easily change in simulation( Unity).

You previously mentioned:

“How strong is the distortion in this lens? It might help to build a really good model of it and use the --predistort option.”

After investigating my Unity setup, I found that lens distortion is disabled in the simulation. I have attached an example image from the simulation for clarification.

Following your earlier guidance, I added the --crpix-center option and removed the --objs 200 constraint from my pipeline. This significantly improved the results: the main geolocation error distribution is now around 1–1.5 km, compared to about 30 km previously. I have attached a figure showing the 2D horizontal position error.

As you can see, there is still a consistent bias in the estimated position. I believe this may be correctable, and I would greatly value your opinion on the likely source of this bias.

Thank you again for your time and guidance.

Best regards,
Sharaf

[Dustin Lang]

Hi Sharaf,

Which direction is the bias in?

I don't know what your simulation looks like, but if you are ever interested in using this in the real world, you will discover the world of geodesy;

For example, I just learned from this page that the local gravity direction can deviate from the ellipsoid by an arcminute!

https://en.wikipedia.org/wiki/Vertical_deflection

and

https://en.wikipedia.org/wiki/Physical_geodesy

There's a good figure here on that - https://kartoweb.itc.nl/geometrics/Coordinate%20systems/body.htm

As for your accuracy problems, it seems pretty obvious that going to a narrower field of view is going to make this problem easier!

cheers,

dustin

To view this discussion visit https://groups.google.com/d/msgid/astrometry/046b5233-bcc3-428f-af9c-da18181dd7bdn%40googlegroups.com.

[Astro Keith]

Been following this thread with interest!

A burning question is - how will you stabilise the camera to point at the zenith? (or know where the zenith is in your image?)

[Sharaf Mohanna]

by using gimbal

[Sharaf Mohanna]

Hello  dustin,

thank you for your support 
when I used the simulation to test my algrithm I got bias in longtitude around 1.6 km as you can see in the attached image, between the estimated latitude from my anlgrithm and ground truth

I think this bias come from the time when I calculate the longtitud from the RA in my algrithm 
what do you think?

[Dustin Lang]

It looks like the width of the red dots is wider than the block box.  Are you including a cos(Dec) term in your RA computation?

To view this discussion visit https://groups.google.com/d/msgid/astrometry/37de2137-ed25-4dbc-8755-d2fd1cbdb7fdn%40googlegroups.com.

[Sharaf Mohanna]

Hi dustin,
I am not including the cos(Dec) term in my RA computation to calculate the longitude.

I calculate the longitude by using this formula: lon_est = RA - GST

Do you think I have to use cos(Dec) like this: lon_est = (RA - GST) / cos(Dec)

because the longitude lines get closer together when I move toward the pole?

[Dustin Lang]

No, but you are plotting something in METERs, so I think it is possible that you have made an error in converting Lat,Long into meters.

To view this discussion visit https://groups.google.com/d/msgid/astrometry/a6d65afa-d13c-4af3-b2c4-9dde70f5b54en%40googlegroups.com.

[Sharaf Mohanna]

Thank you for your support. Our discussions have helped me a lot in developing my algorithm during the simulation stage.

I am now working on testing it in the real world. If I have any questions, I will be happy to ask you.

Astronomical navigation is a very useful tool.
Thanks again for your help.

[Sharaf Mohanna]

Hi Dustin,

Could you please provide any documents that explain how astrometry works as an algorithm? I’m currently using astrometry in my project and need to present it, including how it detects stars and how it performs under cloudy conditions.

If you have any useful resources, I would really appreciate you sharing them with me.
thanks

[Sharaf Mohanna]

I am using also using web astrometry to calculate the center RA and Dec of the image I got faild from these images why that happen do you think ?
and when I use the local astrometry with this parameters 

" 
SOLVE_ARGS = [
    "--overwrite",
    "--dir", SOLVED_DIR,
    "--downsample", "2",
    "--scale-units", "degwidth",
    "--scale-low", "75",
    "--scale-high", "110",

    "--config", BACKEND_CFG,
    "--crpix-center",
    "-v",
    "--continue",

    "--no-plots",
    "--cpulimit", "180",
]"

I got bad result from the local how can I handel this do you think?

[Dustin Lang]

Hi,

Here's the paper: https://arxiv.org/abs/0910.2233

To view this discussion visit https://groups.google.com/d/msgid/astrometry/193191b3-5c8e-484f-b0a1-1401b49cd88en%40googlegroups.com.

[Sharaf Mohanna]

Hello Bubu,

I reviewed your comments, and I think you raised a very important point.

I have completed the simulation tests for my camera-based star navigation algorithm. In the current version of the algorithm, I assume that the camera is always perfectly aligned with the local zenith. Based on this assumption, after determining the right ascension (RA) and declination (DEC) from the captured star image and using the corresponding observation time, I estimate the position on Earth using:
lat​=DEC
long​=RA−GST

However, I am now working on the hardware implementation, where the camera is mounted on a gimbal. I realised that, in practice, I cannot guarantee that the camera will always point exactly toward the zenith. Even a small tilt or misalignment could introduce a significant error in the estimated latitude and longitude.

For this reason, I think the attached paper, “Autonomous Positioning Utilizing Star Sensor and Inclinometer,” could be very relevant to this problem. The paper combines a star sensor with a dual-axis inclinometer to determine the local vertical direction and account for the sensor's tilt. It also considers the fixed misalignment between the star sensor and the inclinometer and introduces a calibration method to compensate for this systematic error.

My idea is to use the inclinometer measurements to determine the camera's deviation from the local zenith and then use this information to correct the star-based navigation solution. This would remove the need to assume that the camera is perfectly aligned with the zenith.

Do you have any experience with this type of approach, or would you recommend another method for compensating for the camera's deviation from the zenith?

On Thursday, December 4, 2025 at 12:48:52 AM UTC bubu...@gmail.com wrote:

If you're using a telescope, I think you need write the telescope pointing info (altaz) and time into the same fits header.

If you're doing some integrated navigation with IMU-like modules, please refer to this paper:

Autonomous positioning utilizing star sensor and inclinometer - ScienceDirect

在2025年12月3日星期三 UTC+8 23:37:23<dstn...@gmail.com> 写道：

Hi,

You can try searching this group for previous posts on the topic.  I think it has been covered before.

To go from RA,Dec to lat/long, you need the time and probably the alt/az of the image.  Nothing in the Astrometry.net package deals with time -- you would need to use something else, perhaps astropy or some other software, to do that.

cheers,

dustin

On Tue, Dec 2, 2025 at 8:04 PM Sharaf Z. Muhanna <muhann...@gmail.com> wrote:

Hi Dustin,

I’m new to the astronomy field, and after obtaining the RA and DEC from an image, I’m unsure how to compute the latitude and longitude from them. Is it possible to use Astrometry.net for this, or would you recommend a different approach?
I would appreciate any guidance or recommendations you can share.  

Thanks 

--
You received this message because you are subscribed to the Google Groups "astrometry" group.
To unsubscribe from this group and stop receiving emails from it, send an email to astrometry+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/astrometry/9e422448-7d26-4f0f-b771-4c19f50f1c58n%40googlegroups.com.

[Sharaf Mohanna]

Hello Dustin
I’m currently working on the hardware setup and wanted to get your thoughts on lens calibration.

Do you think I need to build a distortion model for my lens? Would applying a lens distortion model improve the accuracy of the astrometry output when using the system in real-world conditions?

My current camera setup is:

• Sony Alpha A7R IV
• Sony FE 85mm f/1.8 prime lens

https://www.wexphotovideo.com/sony-a7r-iva-digital-camera-body-3005721/
https://www.wexphotovideo.com/sony-fe-85mm-f18-prime-lens-1619468/

On Monday, January 26, 2026 at 5:31:29 PM UTC dstn...@gmail.com wrote:

Adding

--crpix-center

will probably help.

How strong is the distortion in this lens?  It might help to build a really good model of it and use the --predistort option.

cheers,

dustin

On Mon, Jan 26, 2026 at 11:41 AM Sharaf Mohanna <muhann...@gmail.com> wrote:

I have a project where I estimate an Earth location (latitude and longitude) from star images. I started with a simulation and built a Unity environment that generates a realistic sky with correct star motion over time. The simulator also provides ground-truth latitude and longitude.

In this setup, I use a moving camera with a 50° vertical FOV and 73.74° horizontal FOV. I developed an astronomy-based pipeline that uses the astrometry.net 4100 index series to solve each image and extract the RA/DEC. Then, using RA/DEC together with the UTC timestamp, I estimate the camera’s latitude and longitude.

Main solve-field settings:

• --downsample 2

• --scale-units degwidth with --scale-low 75 and --scale-high 110

• --objs 200

• --cpulimit 180

After processing around 640 sky images and comparing the estimates with the ground truth, I obtained an error of about RMSE = 72,999.03 m (as shown in the plot). I also attached some sample simulation images.

I’d appreciate advice on improving accuracy. Should I reduce the FOV, or would you recommend using a different index/catalog? Which parameters or steps in my pipeline are most likely causing the large error, and what changes would you suggest to reduce it?

Finally, I can share the CSV output from my algorithm, which includes the extracted RA/DEC, the estimated latitude/longitude, and the corresponding ground-truth values.

On Monday, December 8, 2025 at 3:47:47 PM UTC dstn...@gmail.com wrote:

Hi,

These are very wide-field, so if you set the "--scale-units degwidth --scale-lower 30" it should run a bit faster.

Or, for these wide-field images, you will not need very many index files to work well -- the "4100-series" should work great -- https://data.astrometry.net/4100/ .  There are some instructions on how to use Docker to run locally, at  https://github.com/dstndstn/astrometry.net

cheers,

dustin

--
You received this message because you are subscribed to the Google Groups "astrometry" group.
To unsubscribe from this group and stop receiving emails from it, send an email to astrometry+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/astrometry/59e467a0-c2bd-470e-bb2c-8fa5d491e7ebn%40googlegroups.com.

[Dustin Lang]

Hi Sharaf,

I'm not going to guess - this is something you should test.  For astrometry.net, if the distortion is mild, then it should still be able to "lock on" to the right matches between stars and produce a good solution.  For your application, I think you mostly care about the center pointing of the image, rather than getting the full distortion solution over the whole image correct -- that's an easier problem.

solve-field has the "--predistort" option.  This takes a SIP WCS file as input, and it corrects for that distortion pattern, runs the solver, and then re-applies that distortion pattern.  If you have a good image with your camera setup, where solve-field produces a good distortion solution, you could use the SIP WCS file it produces for future runs with the --predistort option.

cheers,

dustin

To view this discussion visit https://groups.google.com/d/msgid/astrometry/ec6cefd8-3f2d-4895-9aa7-e08a9b133511n%40googlegroups.com.