RANSAC implementation v2

[cgarling]

Closes #3. This is an alternate approach which I think should work better than #28 as that implementation did some things wrong (see #28 (comment)).

[codecov]

Codecov Report

❌ Patch coverage is 98.86364% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 99.30%. Comparing base (c256d9b) to head (8462648).

Files with missing lines	Patch %	Lines
src/register.jl	98.55%	1 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##              main      #35      +/-   ##
===========================================
- Coverage   100.00%   99.30%   -0.70%     
===========================================
  Files            5        4       -1     
  Lines           68      143      +75     
===========================================
+ Hits            68      142      +74     
- Misses           0        1       +1     

Flag	Coverage Δ
unittests	99.30% <98.86%> (-0.70%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[cgarling]

In fact I think using k_nearest in _build_correspondences is still wrong; if anything I think it would enter into triangle_invariants as an option to restrict the number of triangles created (i.e., only making triangles out of the nearest k neighbors of each star, rather than every combination). So it's a way to restrict the total number of triangles created, which may be useful for images that contain a lot of stars. Once the triangles are created, they should be paired 1-1 between the to- and from-frames on the basis of asterism similarity (so NearestNeighbors.nn, not knn). I have removed references to k_nearest in d70e381 because I think my implementation was wrong. We can add it into triangle_invariants in another later PR if we wish.

[icweaver]

Thanks for the fix, Chris. Will keep the inverse transform as requested

[RainerHeintzmann]

I ran a test over the dataset which previously gave trouble using a line like this:

    @time res_all = [align_frame(img_from, img_to)[1]  for img_from in eachslice(gray, dims=3)]

and it seems that the alignment was good. I did not do any quantitative comparison, but there was no fail.
It took 30 sec for 30 images of 1024x1024.

But I think you can merge the ransac-2 code.

[icweaver]

Thanks, Chris! Just left a very brief suggestion/question for the point_map bit

I also finished merging your ransac.jl notebook into the original docs/notebook.jl Pluto notebook + cleaned up a few visualization things. Here's an html preview: https://pluto.land/n/8p4z2gqc

I haven't done a deep dive on the tests, but the initial passing tests makes me inclined to just save extra exploration of this + maybe how we generate test star fields for a separate PR

[cgarling]

@icweaver should we actually be returning fwd_tfm here for consistency? That would give the from -> to transformation which is what we give in point_map so the two would match in convention. Really tfm is only needed for the warp call since it requires the to -> from transformation.

I noticed in your pluto notebook you have to take the inverse of the returned tfm in order to compare to the original transformation matrix which feels like one extra step maybe you shouldn't have to take.

[icweaver]

Agreed, this was bothering me a bit too. Making the switch in the notebook and src/warp.jl is straightforward enough, but it seems like some care will need to be taken to update the tests. Happy to make the change, just wanted to make sure I was understanding the implications first before making any substantial changes to your tests

[icweaver]

I guess just sprinkling some inv should be enough