CroatianMeteorNetwork
Replace FFT with a Nearest Neighbor Ransac approach
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.
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.
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.
@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)"
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.
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?
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.
I was trying a simple sudo apt update on buster and got some sort of end-of-life message. I didn’t investigate further. On Dec 11, 2025, at 3:21 PM, Mark McIntyre @.***> wrote:markmac99 left a comment (CroatianMeteorNetwork/RMS#762) 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.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>
It turns out FFTalign was making the pointing worse in every case. Within ~0.9° of tolerance, the 10 px latching logic would snap the pointing back to where it belongs, but outside that window, FFT would amplify the error.
I replaced it with a nearest-neighbor approach using RANSAC-like outlier rejection (NNalign). This method can recover pointing that has drifted up to 2–3°. It can also reliably creates match pairs between detected and catalog stars. Combined with the accurate initial pointing from astrometry.net, this means fully automated platepar creation is now possible.
No additional packages required (no imreg_dft, scikit-image, or anything else.)
See demo: https://youtu.be/q-ODjRWmUpI
Combined with the accurate initial pointing from astrometry.net, this means fully automated platepar creation is now possible.
Sounds interesting. I have never been able to get the astrometry.net process to platesolve an RMS image though!
The astrometry.net online service is hit or miss, but the local install of the astrometry package (linux only) works great.
Oh shoot, it never occurred to me that it could be a problem. Please do go ahead
I've pushed a fix which allows for direct submission to nova.astrometry.net in the case where imgur isn't available for commercial or legal reasons. To get this working I had to update the astrometry client as the method of submitting files has changed. I also changed SkyFit2 to always use the x/y star points if available. This seems to work really well with the new NN code.
It's pretty awesome, yup! A few minor tweaks are needed, e.g. if the fit is good after the 5odd step, the asymmetry correction should be turned on and it should finish the fit with the odd7 model. It also needs a bit more stringent outlier rejection procedure for both astrometry and photometry. Once these are done, that's it.