Combination of parameters to solve_from_centroids for image that will solve the fastest

[windell747]

Aloha, I have an example image (google link below) and I would like to find a set of parameters that will solve the image the fastest. I have my own variable background subtraction and diffraction spike rejection algorithm (im happy to share) and it takes 0.5 seconds to compute a list of centroids from a monochrome png image, but I'm wondering if any of you are able to solve the attached picture natively without modification to the code and what parameters have you chosen to make it solve the fastest. My solver takes 1.5 seconds. I know that this is system dependent, but I wanted to just give an idea of the solve time.

Here are some givens: fov_estimate:=10.78 deg, fov_max_error=0.25, pattern_checking_stars=15, match_radius= 0.01 (left at default), match_threshold=1e-3(left at default)

Here are my thoughts (please correct me if im wrong about what I say): 1) A more accuracte fov_estimate shortens solving time. 2) Decreasing fov_max_error shortens solving time (providing that its a valid max error). 3) Decreasing pattern checking stars values decreases solve time since only 4 are needed, but more might be needed to get the probability of false positive lower. 4) Decreasing match_radius means less iterations on distortion and shorter solve time. (Thus having better optics means shorter time) 5) Decreasing match_threshold means a shorter match time. (Im assuming that the # of stars checked in pattern_checking_stars is increased until this threshold is met and the solver exits?

I may be incorrect about some of my statements above. I only mean to throw my assumptions out there. Please correct me if I'm off!

Here is the google link: https://drive.google.com/drive/folders/1GNJ93yn-rDqaa0cDSLCgazjSVZR1yXyx?usp=sharing

[smroid]

I don't see an attached image?

[windell747]

Sorry about that. They are too large to attach. 28MB each. I updated the OP with the link.

thanks, windell

[smroid]

https://github.com/smroid/cedar-solve is a fork of Tetra3 that I maintain. Together with cedar-detect, it was able to solve your image in less than 0.4s (175ms for centroiding and 159ms for plate solving, on a Raspberry Pi 4).

It looks like there might have been some camera shake in that image, as the stars are all doubled up. The cedar-detect algorithm doesn't like the double star images, it rejected most of them.

Also, it looks like the image is somewhat over-exposed. Try reducing the shutter time? That might also help with the shake issue.

I didn't do anything special to deal with the diffraction spots. If you reduce the exposure they should be less prominent.

[windell747]

Thank you very much! I'm very impressed! Could you please share with me the algorithm for cedar-solve? Are there papers written on it? From the context it sounds like it's a centroiding algorithm. There was wind shake on the camera since it has a large baffle and I was purposely trying to test cloud subtraction. What is your background subtraction algorithm? My centroiding code is able to group the double stars so maybe we can collaborate. The output image that I provided indicate the stars used for the solution.

On Wed, Oct 30, 2024, 7:07 PM Steven Rosenthal @.***> wrote:

https://github.com/smroid/cedar-solve is a fork of Tetra3 that I maintain. Together with cedar-detect, it was able to solve your image in less than 0.4s (175ms for centroiding and 159ms for plate solving, on a Raspberry Pi 4).

It looks like there might have been some camera shake in that image, as the stars are all doubled up. The cedar-detect algorithm doesn't like the double star images, it rejected most of them.

Also, it looks like the image is somewhat over-exposed. Try reducing the shutter time? That might also help with the shake issue.

I didn't do anything special to deal with the diffraction spots. If you reduce the exposure they should be less prominent.

— Reply to this email directly, view it on GitHub https://github.com/esa/tetra3/issues/34#issuecomment-2449019337, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHZ3GGRFLG5FITZFRDMTK3TZ6G3KNAVCNFSM6AAAAABQ5QGFNSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINBZGAYTSMZTG4 . You are receiving this because you authored the thread.Message ID: @.***>

[windell747]

Oh also, what were your arguments supplied to tetra3?

On Thu, Oct 31, 2024, 2:30 PM Windell Jones @.***> wrote:

Thank you very much! I'm very impressed! Could you please share with me the algorithm for cedar-solve? Are there papers written on it? From the context it sounds like it's a centroiding algorithm. There was wind shake on the camera since it has a large baffle and I was purposely trying to test cloud subtraction. What is your background subtraction algorithm? My centroiding code is able to group the double stars so maybe we can collaborate. The output image that I provided indicate the stars used for the solution.

On Wed, Oct 30, 2024, 7:07 PM Steven Rosenthal @.***> wrote:

https://github.com/smroid/cedar-solve is a fork of Tetra3 that I maintain. Together with cedar-detect, it was able to solve your image in less than 0.4s (175ms for centroiding and 159ms for plate solving, on a Raspberry Pi 4).

It looks like there might have been some camera shake in that image, as the stars are all doubled up. The cedar-detect algorithm doesn't like the double star images, it rejected most of them.

Also, it looks like the image is somewhat over-exposed. Try reducing the shutter time? That might also help with the shake issue.

I didn't do anything special to deal with the diffraction spots. If you reduce the exposure they should be less prominent.

— Reply to this email directly, view it on GitHub https://github.com/esa/tetra3/issues/34#issuecomment-2449019337, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHZ3GGRFLG5FITZFRDMTK3TZ6G3KNAVCNFSM6AAAAABQ5QGFNSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINBZGAYTSMZTG4 . You are receiving this because you authored the thread.Message ID: @.***>

[smroid]

No papers on Cedar-detect, but you can look at the code at https://github.com/smroid/cedar-detect/blob/main/src/algorithm.rs, it is pretty extensively commented.

Can you describe your imaging setup? What camera sensor, lens, and what exposure time for that image? What is causing the diffraction artifacts?

Regarding my tetra3 invocation-- it is at https://github.com/smroid/cedar-solve/blob/master/examples/test_tetra3.py, so:

fov_estimate: None match_radius: 0.01 match_threshold: 1e-4 pattern_checking_stars: no longer used in cedar-solve's fork of tetra3 match_max_error: 0.002

[windell747]

Thank you very much for the info! I will look at the algorithm.

The camera is a ASI294 monochrome camera coupled with a electronic focuser from Beiger Engineering, and a Sigma f/105 lens. Over the lens aperature is a 091 red filter to filter out sky scatter as much as possible. In front of the lens is an EMI mesh for RF attenuation and this is where the scatter is coming from. The computer is an SBC from VersaLogic called the Owl, it has a 2GHz Apollo Processor. Onboard storage is 8TB for full res images and a 512 MB card for downsampled images. Baffle in front is a 3ft long with 7 vanes. FOV is 10.7 x 8 deg.

On Thu, Oct 31, 2024 at 3:24 PM Steven Rosenthal @.***> wrote:

No papers on Cedar-detect, but you can look at the code at https://github.com/smroid/cedar-detect/blob/main/src/algorithm.rs, it is pretty extensively commented.

Can you describe your imaging setup? What camera sensor, lens, and what exposure time for that image?

Regarding my tetra3 invocation-- it is at https://github.com/smroid/cedar-solve/blob/master/examples/test_tetra3.py, so:

fov_estimate: None match_radius: 0.01 match_threshold: 1e-4 pattern_checking_stars: no longer used in cedar-solve's fork of tetra3 match_max_error: 0.002

— Reply to this email directly, view it on GitHub https://github.com/esa/tetra3/issues/34#issuecomment-2451119865, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHZ3GGXD3TZT5QCYOFFOKTTZ6LJ3JAVCNFSM6AAAAABQ5QGFNSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINJRGEYTSOBWGU . You are receiving this because you authored the thread.Message ID: @.***>

[smroid]

What was the exposure time for the image you posted?

[windell747]

Exposure time 100ms, focus was done manually instead of autofocus.

On Thu, Oct 31, 2024 at 3:58 PM Windell Jones @.***> wrote:

Thank you very much for the info! I will look at the algorithm.

The camera is a ASI294 monochrome camera coupled with a electronic focuser from Beiger Engineering, and a Sigma f/105 lens. Over the lens aperature is a 091 red filter to filter out sky scatter as much as possible. In front of the lens is an EMI mesh for RF attenuation and this is where the scatter is coming from. The computer is an SBC from VersaLogic called the Owl, it has a 2GHz Apollo Processor. Onboard storage is 8TB for full res images and a 512 MB card for downsampled images. Baffle in front is a 3ft long with 7 vanes. FOV is 10.7 x 8 deg.

On Thu, Oct 31, 2024 at 3:24 PM Steven Rosenthal @.***> wrote:

No papers on Cedar-detect, but you can look at the code at https://github.com/smroid/cedar-detect/blob/main/src/algorithm.rs, it is pretty extensively commented.

Can you describe your imaging setup? What camera sensor, lens, and what exposure time for that image?

Regarding my tetra3 invocation-- it is at https://github.com/smroid/cedar-solve/blob/master/examples/test_tetra3.py, so:

fov_estimate: None match_radius: 0.01 match_threshold: 1e-4 pattern_checking_stars: no longer used in cedar-solve's fork of tetra3 match_max_error: 0.002

— Reply to this email directly, view it on GitHub https://github.com/esa/tetra3/issues/34#issuecomment-2451119865, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHZ3GGXD3TZT5QCYOFFOKTTZ6LJ3JAVCNFSM6AAAAABQ5QGFNSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINJRGEYTSOBWGU . You are receiving this because you authored the thread.Message ID: @.***>