Hi! Siril already has a good solver built in, but that solver isn’t capable of blind solving. Granted, that’s a bit of an unusual use case in Siril (what are you even processing images of that you don’t know where it is?), but can be useful. I’ve been working on a new open source solver which is a much faster blind solver: GitHub - theatrus/seiza: Rust astronomical plate solver · GitHub and attached it to Siril.
As Siril right now only supports the local Astrometry dot net blind solver, I made a mode where Siril can think it loads the Astrometry solver, but instead gets a copy of Seiza running. The setup makes a fake environment for it to run with. It works, but it’s very much an alpha test, and is a “not great” integration. Basic instructions are in the README, but I realize there will be bugs.
Seiza, while written in Rust, has a PyO3/maturin wrapper python package you can use (look for seiza in PyPi) - docs are included in the readme as well. Long term, this might be a good integration point if there is interest here from the developers.
[origin and plugs]
I originally co-wrote Seiza (yes, this is AI assisted code generation, with a lot of guidance!) to power by personal (small!) astrophotography gallery with object annotations, and included transients for SN 2026qf: Image 1 - theatr.us - its grown to a few more places like folding into my NINA Target Scheduler advanced screener (github.com/theartus/psf-guard) and as a stand along web service you can just thwack images at live: https://seiza.fyi
Thanks for reaching out. Haven’t tried yet but looks promising. Currently working myself on siril internal solver to improve accuracy of distortion solutions and wide field solving.
Regarding direct integration into siril, i’m not sure it’s exactly the way we’re headed. We are actually trying to push external parties software to our python API. Nothing against external software, really, it’s just the maintenance burden for this integration in the core code is on us and quite tedious in C, while as a python script, it’s much more lightweight. Tbh, that’s already how i’m prototyping my changes to our own solver. I’ve just added a couple of new siril commands to make it easier, that will probably be part of next release siril.
Practically for your solver, i’m going to add a command addwcs which can load a wcs (FITS) file to the header of the currently loaded image. So the mechanism for your solver (or any other external solver) would be, in a python script:
get the stars from the image (doable through the API)
do your solving and write a wcs
if succesful, it should use addwcs to update the current image.
As you’re mentionning a python wrapper on your end, that should be fairly direct.
Once this command is exposed, i will probably remove astrometry.net from our code code and write a python script instead. I could keep you posted when that’s done? We could even share a common script, no need to have one script per solver.
Thanks for the note! No need for direct integration here - managing third party deps there is massively challenging long term.
The solver API is pretty extensible - it is a Python module, but the PyPi package wraps a chunk of native code which is the actual implementation (PyO3 makes this actually pretty trivial, its becoming a pretty common pattern for Python modules). I do build the trio of Win64/manylinux/applesilicon wheels, but nothing stops from shipping pure python code as well.
I can absolutely write a WCS for later ingest or share a script here. Let me know, and no rush!