Solver inconsistently finding solution

[LonelySpaceman]

I'm trying to use tetra3 with photos that I've taken using a DSLR and 300mm lens. I've downloaded the Tycho Catalogue and generated a database with an FOV ranging from 4 to 6 degrees with a maximum star magnitude of 10.

When I pass an image into the solver, it will sometimes dutifully report back a correct solution as well as an FOV of 4.46 degrees, which is within the FOV range that I specified for the database I generated from Tycho. Other times, it's solution dictionary is just filled with None, which I can only assume means that the solver failed to find a solution.

I'm kind of at a loss trying to figure out why the solver is working for some of my images but not for others, I'm not changing any camera settings or database settings in between images, just what I'm pointing at in the sky. I'm a beginner at this, so I'm hoping there's just something simple that I'm missing.

[smroid]

Would it be possible to post your images? Especially ones that fail.

Also, can you give the parameters you used to generate the database, and also the parameters used when trying to solve an image?

[LonelySpaceman]

Of course! I've attached four test exposures that I've been using to try and debug this thing. Please note that these images were originally passed into the plate solver in raw format, I've converted them to JPG form to send them over GitHub. To generate the database, I used the .generate_database() method:

t3.generate_database(save_as='t3_fov4-6_mag10', max_fov=6, min_fov=4, star_max_magnitude=10, star catalog='tyc_main')

When trying to solve for the image, I use the .solve_from_image() method:

solution = t3.solve_from_image(img, fov_estimate=4.4, fov_max_error=0.1)

My lens settings are the same across all images, so I set fov_estimate and fov_max_error to match those settings. This configuration works for all the images I've attached except _MG_0006.jpg. I can't seem to figure out why this particular image makes the plate solver fail, especially because the solver on Astronomy.net seems to process it just fine.

[smroid]

In the non-solving image, your brightest stars are bloomed to the point that solve_from_image() by default rejects them. Try passing max_size=200 to solve_from_image() (default is 100).

Caveat-- I tried this not on Tetra3 but on a fork of Tetra3 I've developed. But the bloomed-bright-stars issue should be the same in both versions.

BTW, your images are yielding hundreds of detected stars. For Tetra3, you can shorten your exposure, as 20-50 detected stars should be plenty. Shortening the exposure will cause the brightest stars (which are favored for pattern matching) to bloom less and thus not be rejected by the default max_size=100 parameter.

Please let us know if any of this helps!

[LonelySpaceman]

This actually makes a lot of sense. The test subs that I've been passing into Tetra3 have had ~20-30 seconds of exposure time. I'm glad that I don't need to spend that long taking these subs for this to work! I'll play around with subs ~1-5 seconds exposure time next time I'm imaging.

I've just tried your solution setting max_size=200, but I can't get a solution from any of my images with this setting. Even stranger, if I manually set max_size=100 to match the default setting, I still can't get a solution from any of my images. I can only get a solution when I don't pass max_size as an argument into the method.

I think the solution will probably just be to take shorter exposures, but I will definitely be back if that doesn't work.

[gustavmpettersson]

Hi Mr Spaceman,

Thanks for helping each other. I believe the parameter Steven is talking about is called max_area in the main version. In general, because your images are very high resolution I'd also suggest starting with downsample=2 to bin it first.

Gustav

[smroid]

I apologize-- the parameter is indeed max_area.

+1 to the idea of downsampling, that will probably also eliminate the need to adjust the max_area setting.

[LonelySpaceman]

Gustav and smroid,

Thank you both so much for your help on this. I added downsample=2 and started playing around with the max_area values. I incremented max_area by 100 from the default 100 to 1000, but Tetra3 still couldn't find a solution for _MG_0006.jpg. It still works for all other test sub exposures for each value of max_area that I tried, though!

I should get a few hours of clear skies tonight. I'll test Tetra3 with shorter sub exposures and will report back my findings :)

[smroid]

Interesting. I'll investigate with Tetra3, not my fork.

[lcandell]

I'd be curious to see if removing or relaxing the 'fov_max_error=0.1' setting helps. The solver calculates an initial coarse FOV for each pattern and if it is outside of this error bound, it will skip over the pattern it is evaluating. If, for example, it calculates the FOV to be 4.5 instead of 4.46, it will eliminate that pattern from further consideration, since it is greater than 0.1 degrees from your estimate.

I've also found that the 'pattern_checking_stars' default of 8 leads to failed solves more often than one might expect. You might try setting this value higher (say 15). This will also lead to slightly slower solves.

Do you happen to recall which of the 4 images fails to solve? If I get a chance this weekend, I will play with it to see if there's something unusual.

Best of Luck.

[LonelySpaceman]

lcandell,

You are an absolute LEGEND. Removing the FOV estimate didn't change my results, but setting pattern_checking_stars=15 worked! The solver now finds a solution for _MG_0006.jpg, as well as my other test cases. Thanks so much for your help, as well as everyone else who's given me things to try. I feel like I've learned a lot. You all are rockstars.

Clear skies all!

[smroid]

Glad you got it sorted.

The fact that increasing pattern_checking_stars solved the problem is consistent with my fork of Tetra3 working on the problem image, as one of the fork's improvements is to eliminate the need for the pattern_checking_stars parameter.

I'm still building the 4-6 degree database for Tetra3, and will report back with any additional findings.

[smroid]

@LonelySpaceman, may I have permission to include your four images into my Tetra3 fork's collection of test images? Please let me know what attribution, if any, you would like me to include with your images.

[smroid]

I've confirmed Tetra3's behavior and have an explanation of why increasing the pattern_checking_stars value (from default 8) helps.

When building the pattern database, Tetra3 employs a strategy to ensure a (more or less) spatially uniform distribution of patterns. A side effect of the technique is that when bright stars are closely spaced, some of the bright stars are not incorporated into database patterns.

In the problem image, of the brightest 8 stars, some are not included in the pattern database. Thus there are no 4-star subsets of the brightest 8 that are in the pattern database. Increasing pattern_checking_stars to say 12 allows a 4-star subset to be found that's in the pattern database, at the expense of a longer solve time.

The fork of Tetra3 (https://github.com/smroid/cedar-solve) improves this in several ways:

1. When compiling the pattern database, cedar-solve uses a different spatial distribution method which retains most bright stars, such that the solve image's four brightest stars are usually matched in the pattern database.
2. The pattern_checking_stars argument is no longer needed-- cedar-solve automatically works its way down the 4-star combinations of the stars in brightness order.

The result of these improvements is that cedar-solve handles the problem image without difficulty, using the same amount of time as the other images.

Note also that cedar-solve's pattern database is able to provide robust solution coverage with about 15x fewer patterns in the database.

[LonelySpaceman]

@smroid,

Of course! Feel free to use these images! I'm glad that I could provide an interesting test case for your fork and gain a better understanding of how plate solvers like Tetra3 work their magic. Thanks so much for your help with all of this :)