Do find_transform() input lists have a limit on co-ordinate sizes?

[Short-bus]

Hi,

Hopefully someone can shine a light on this one for me.
I've been using astroalign.find_transform() for a while with general success, but sometimes it fails to find a solution.
Erroring out with
List of matching triangles exhausted before an acceptable transformation was found

I noticed it happening with a couple of images that were closely aligned already, and began to wonder why it didn't like them.
I'm comparing a calculated set of star locations with the locations captured in an image.

This example set of star locations fails...

    latestlist = [[3015, 2914], [3190, 2782], [2544, 2619], [1390, 2547], [1958, 2364], [1561, 2319], [1862, 2262], [2851, 2078], [2350, 1869], [273, 1686], [2344, 1360], [3693, 1315], [3744, 1254], [1831, 1121], [3451, 897], [1220, 837], [1903, 787], [2979, 773], [2606, 536], [1255, 445], [510, 392], [3112, 391], [1918, 337], [3219, 229], [146, 207]]
    targetlist = [[3048, 2894], [3225, 2754], [2564, 2592], [1381, 2527], [1962, 2332], [1554, 2288], [1861, 2226], [2874, 2027], [2359, 1815], [232, 1641], [2348, 1286], [3728, 1228], [3780, 1164], [1819, 1041], [3476, 796], [1193, 752], [1891, 693], [2993, 671], [2609, 428], [1224, 346], [463, 298], [3126, 274], [1903, 228], [90, 111], [3234, 107]]
	transform, (LSL, TSL) = astroalign.find_transform(source=latestlist,target=targetlist)
	
	List of matching triangles exhausted before an acceptable transformation was found

If I divide all the values in those two lists by 10, it works.

    latestlist = [[301.5, 291.4], [319.0, 278.2], [254.4, 261.9], [139.0, 254.7], [195.8, 236.4], [156.1, 231.9], [186.2, 226.2], [285.1, 207.8], [235.0, 186.9], [27.3, 168.6], [234.4, 136.0], [369.3, 131.5], [374.4, 125.4], [183.1, 112.1], [345.1, 89.7], [122.0, 83.7], [190.3, 78.7], [297.9, 77.3], [260.6, 53.6], [125.5, 44.5], [51.0, 39.2], [311.2, 39.1], [191.8, 33.7], [321.9, 22.9], [14.6, 20.7]]
    targetlist = [[304.8, 289.4], [322.5, 275.4], [256.4, 259.2], [138.1, 252.7], [196.2, 233.2], [155.4, 228.8], [186.1, 222.6], [287.4, 202.7], [235.9, 181.5], [23.2, 164.1], [234.8, 128.6], [372.8, 122.8], [378.0, 116.4], [181.9, 104.1], [347.6, 79.6], [119.3, 75.2], [189.1, 69.3], [299.3, 67.1], [260.9, 42.8], [122.4, 34.6], [46.3, 29.8], [312.6, 27.4], [190.3, 22.8], [9.0, 11.1], [323.4, 10.7]]
	transform, (LSL, TSL) = astroalign.find_transform(source=latestlist,target=targetlist)
	
	success !

Is there a limit to coordinate sizes? Or something I should do to allow the original values to be solved?

For my purposes I can probably live with scaling the values down, solving and scaling the transform back up, but it feels like I'm missing something...

Running astroalign 2.4.2 on Raspbian GNU/Linux 10 (buster)

Thanks in advance for any insights!

[martinberoiz]

Hi,

Thanks for question. Yes, I believe that choosing a list of x, y pairs can affect the result. The length itself is not the problem, but the opportunity for more false positives is.

It is advisable that you don't use too many reference star positions, usually a dozen or so common bright spots should be enough. If you use more, you risk confusing the algorithm because it will have a higher chance to pick similar (false) asterisms, simply because there are more reference stars. When you pass an image, astroalign will pick the stars according to their brightness, and I would suggest you do the same when passing x, y pair lists.

Also as you can see here the list is capped at max_control_points that by default is set to 50.

Having said that... the algorithm will finally decide if there's a match if it can fit at least 10 triangle pairs between the images. Your example seems like it should work and it makes me curious as why it doesn't 🤔. I will need to run this line by line to check where it's not working exactly. I will do some experiments and come back if I find more.

[Short-bus]

Thanks Martin, that's really useful info. So when max_control_points is applied it expects that the points are already ranked by brightness. Currently I'm treating all 'stars' with equal priority, that now sounds unwise. I will adjust my routines to rank them.
I'm still puzzled why the scale of the individual x and y coordinates impacts the solution. It didn't seem to be the number of stars, but the actual scale of the x and y values for each star which created the variation. But don't lose precious time researching that. I think I can adapt my solution to cope with it, and I may have just got lucky with my observations that night (it's an infinite universe after all :) )
I must admit I've treated the astroalign library as a miracle black-box so far, it's worked so nicely I haven't needed to dig deeper!