Replace FFT with a Nearest Neighbor Ransac approach

[Cybis320]

Replace deprecated imreg_dft with scikit-image.

[markmac99]

I'll have to assume the maths is correct as its not an area i'm familiar with. I left a couple of comments in the review.

[Cybis320]

Ok, I think it works. It's slightly more accurate (although this a coarse tool so it doesn't matter) and it's slightly faster.

[dvida]

Would could also just use RANSAC to reduce complexity: https://scikit-image.org/docs/0.25.x/auto_examples/transform/plot_matching.html
Apparently there are also USAC and MAGSAC that's included in opencv (>v4.0) which are apparently better, but I never used them myself.

[Cybis320]

Would could also just use RANSAC to reduce complexity: https://scikit-image.org/docs/0.25.x/auto_examples/transform/plot_matching.html Apparently there are also USAC and MAGSAC that's included in opencv (>v4.0) which are apparently better, but I never used them myself.

Great suggestion!! It's so much better. 185x faster, perfectly accurate, and 180 less lines of code.

[markmac99]

@Cybis320 I commented this on the latest commit, but ImageIO version 2.33 isn't available for Python 3.7 which is the standard on Buster builds. The last version thats compatible with python 3.7 is 2.31.2. See https://pypi.org/project/ImageIO/#history for more.

  Could not find a version that satisfies the requirement imageio>=2.33 (from -r requirements.txt (line 16)) (from versions: 1.1-linux32, 1.1-linux64, 1.1-osx64, 1.1-win32, 1.1-win64, 1.2-linux32, 1.2-linux64, 1.2-osx64, 1.2-win32, 1.2-win64, 1.3-linux32, 1.3-linux64, 1.3-osx64, 1.3-win32, 1.3-win64, 0.2.1, 0.2.2, 0.2.3, 0.3.0, 0.3.1, 0.3.2, 0.4, 0.4.1, 0.5, 0.5.1, 1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 2.0.0, 2.0.1, 2.1.0, 2.1.1, 2.1.2, 2.2.0, 2.3.0, 2.4.0, 2.4.1, 2.5.0, 2.6.0, 2.6.1, 2.8.0, 2.9.0, 2.10.1, 2.10.2, 2.10.3, 2.10.4, 2.10.5, 2.11.0, 2.11.1, 2.12.0, 2.13.0, 2.13.1, 2.13.2, 2.13.3, 2.13.4, 2.13.5, 2.14.0, 2.14.1, 2.15.0, 2.16.0, 2.16.1, 2.16.2, 2.17.0, 2.18.0, 2.19.0, 2.19.1, 2.19.2, 2.19.3, 2.19.5, 2.20.0, 2.21.0, 2.21.1, 2.21.2, 2.21.3, 2.22.0, 2.22.1, 2.22.2, 2.22.3, 2.22.4, 2.23.0, 2.24.0, 2.25.0, 2.25.1, 2.26.0, 2.26.1, 2.27.0, 2.28.0, 2.28.1, 2.29.0, 2.30.0, 2.31.0, 2.31.1, 2.31.2)
No matching distribution found for imageio>=2.33 (from -r requirements.txt (line 16))
(testsk) pi@uk001l:~/source/testing/testsk $ python -V
Python 3.7.3
(testsk) pi@uk001l:~/source/testing/testsk $ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"

[markmac99]

Latest update resolves the imageio issue, however frustratingly we have a new problem on Python 3.7 - the latest build of bcrypt is only available as a tar.gz file, and to build it requires Rust which is not installed / available for Buster 32bit.

Building wheels for collected packages: bcrypt
  Building wheel for bcrypt (pyproject.toml) ... error
  error: subprocess-exited-with-error
 This package requires Rust >=1.64.0.

To work around that i think we need to install the last-good wheel version on python 3.7

bcrypt==3.2.0 ; python_version <='3.7'
bcrypt ; python_version >='3.8' 

in the requirements. Sigh.

[Cybis320]

Isn't that a paramiko dependency? We didn't touch that here or in prerelease. Are you running into issues with a new install on Buster?

[markmac99]

Quite possibly. I was testing by trying to install the requirements on Buster in a brand new virtualenv, so that i can identify any potential incompatabilities. Existing stations might be ok, as they'd have bcrypt 3.2.0 installed already. So, it should only be a problem if someone has a buster-based system and has to rebuild it to buster. Maybe we just make a note in the README file explaining the potential issue.

[g7gpr]

(vRMS) gmn@walnut:~/source/RMS$ sudo su au000g -c "cd ~/source/RMS; git log -1"
commit 1c454e7e03fb82c234b03811d8a87816fde995ea (HEAD -> feature-scikit-image, origin/feature-scikit-image)
Author: Luc Busquin <133058544+Cybis320@users.noreply.github.com>
Date:   Thu Jan 29 00:07:51 2026 +0100

    Change star name filter to magnitude instead of count
(vRMS) gmn@walnut:~/source/RMS$ sudo su au000e -c "cd ~/source/RMS; git log -1"
commit 8ec0c1eb05aa030294f8c73609c9c29860b2f204 (HEAD -> master, origin/master, origin/HEAD)
Merge: 12b44493 ab747f62
Author: Denis Vida <denis.vida@gmail.com>
Date:   Sun Jan 18 20:33:07 2026 -0500

    Merge pull request #797 from CroatianMeteorNetwork/markmac99-typo-fix
    
    Fix logger name typo in Logger.py

[g7gpr]

These are all 6mm lenses, but I think the results are clear enough!

For au000g, manually created platepar astrometry report

Automatically created platepar astrometry report

Manually created platepar photometry report

Automatically created platpar photometry report

[dvida]

Can you try doing it on the same image? Half a mag of difference in the photometric calibration should be investigated, unless the clouds interfered with the first fit.

[g7gpr]

Same commit, manual platepar vs automatic platepar?

[dvida]

Right, we want to see that the automated photometry fit compares well to the manual fit on the same data. There was previously a bug that caused issues with the automated photometry, I want to confirm that everything is 100% ok now.

[Cybis320]

These are all 6mm lenses, but I think the results are clear enough!

For au000g, manually created platepar astrometry report

Automatically created platepar astrometry report

Manually created platepar photometry report

Automatically created platpar photometry report

It looks like the manual photometry fit also fitted the vignetting coefficient vs the auto used the fixed value, so that goes some ways into explaining the difference.

[g7gpr]

I'm very time poor for the next few days, it seems like @Cybis320 is all over this. Can I leave this to @Cybis320 to look into?

Please do consider that the difference may be caused by poor platepar creation by the operator.

[dvida]

Centroiding somehow got messed up, I click on the fireball but the pick gets significantly offset. Any ideas?

[Cybis320]

Centroiding somehow got messed up, I click on the fireball but the pick gets significantly offset. Any ideas?

I'm not seeing the issue on my side. Could you post a full screenshot with the distortion params?

[dvida]

The distortion params should't affect the centroids as that is only done in the x/y space. I'll try to take a look on my end.

[Cybis320]

I tried to replicate on a Mac and Ubuntu with and without display scaling, in manual reduction mode or not, the centroids are always perfect. Are you measuring FF files or something else?

[dvida]

On master, using an FF file in the manual reduction mode. I found a meteor segment.
I intentionally made the aperture large and clicked off the bright segment, the centroid snaps in the right place no matter where I click:

On the new branch:

[Cybis320]

Right, I see the behavior you describe from master using this branch even with a wide aperture. I really want to reproduce though.

[Cybis320]

And you seeing the same on regular stars or just on meteors - is it a moving object issue somehow?

[dvida]

You can take any FF file with a meteor to test. I only noticed it in manual reduction, haven't tried it in stars. This was perhaps not noticed because most often star centroids snap to the extracted positions (green circles).

[Cybis320]

Ok, found the issue when in manual reduction in frame picking mode and picking fast moving objects. It should be fixed now.

[dvida]

It works, thanks!