Replies: 5 comments 4 replies
-
Hi Leo, Looking at the transformation outputs, it seems the rotation angle is about the same, but the translation vector is off by about 10 pixels. I can see the disparity, can you send me (just) a couple of images and a notebook where you notice the problem? I can take a look this weekend and diagnose the problem better. One thing you can try in the meantime is to restrict the number of sources it uses to find the transformation ( aligned_image, footprint = aa.register(source_image, target_image, max_control_points=10) |
Beta Was this translation helpful? Give feedback.
-
Thank you for your quick response Martin! I wouldn't want to make you work on the week-ends though. Here is the script and the 2 images used in the example. (quiet heavy, I couldn't load more here, but it should be enough). To reproduce the problem, just run the script a few times. If like me, the transformations should not be exactly the same than in the example. |
Beta Was this translation helpful? Give feedback.
-
So, I've tried a new way. This doesn't solve the issue sadly. The idea is to use |
Beta Was this translation helpful? Give feedback.
-
Hi Leo, I haven't had time to look into this issue yet. I'm caught trying to find the time to finish a new release that deals with masking. When I finish that one, I'll take a look at this issue. Thanks for keep digging on this! I can't remember now from the top of my head, but since there's an O(N^2) part of the algorithm, astroalign will restrict the number of sources it works with. Also, more stars may just crowd the invariant space and confuse the algorithm. You'd have the best luck with a few (O(10)) bright stars that appear on both frames. |
Beta Was this translation helpful? Give feedback.
-
So as promised, I messed around today, but couldn't find a satisfying solution. I think I'll wait for you to take a look, as I don't have time or knowledge to dig into astroalign code. Here is a brief summary of what I did: So from what I understand, the algorithm tries to find the best fit, which seems logical. But by doing so, it restricts to nearby stars that match well, and forget that the image is much bigger, causing misalignment on the other side. Maybe a solution would be to add the option to give a higher priority in using spread out stars, and only then searching for the best fit with those? Or accepting a worst fit when given few stars (maybe just with a warning) ? Not sure if and how this is doable though... |
Beta Was this translation helpful? Give feedback.
-
Hello,
I'm discovering astroalign. It seems great for my purpose, which is to align star fields, and would avoid having to use a proprietary software. However, I have troubles understanding the behavior of the
find_transform
function.When I run my script several times on the two same fits images, it does not return the same transformation matrix! And the differences are not negligible. (I also tried to convert the fits data to "<f4" as proposed here: #73)
Here are 2 examples with images. As you can see, the second call to the function is way worst than the first. How is that possible? It does not select the same stars, even though the
detection_sigma
is set to 5.Is there a solution? Running it multiple times and taking the average improves the reproducibility a bit, but it feels like a dirty fix and still leads to large differences.
I might miss the obvious, but couldn't find any solutions online.
Thanks for your help!
Transformation 1:
Transformation 2:
Beta Was this translation helpful? Give feedback.
All reactions