I’m looking to add plate solving to my image capture app. Everything seems straightforward when using mono cameras (I just add the WCS headers, plus the inferred FOCALLEN ).
But when I have a OSC camera, I will typically need to downscale and debayer to find the point sources (I’m using the python sep library) and then calling solve-field with their coordinates. That intermediate image is thrown away. That means my WCS info is no longer correct for the raw fits file that siril would see (because I’m downscaling for performance).
Can I at least help speed up siril’s plate solving by including the FOCALLEN and RA/DEC position CRVAL1 / CRVAL2 or are the WCS headers an “all or nothing” thing?
to potentially answer my own question: if I just match the x/y pixel position of my star centroids (when working on a debayered image) with the bayered original I think the WCS headers should “just work”. My debayering is optimised for performance (not image quality) and downscales the image so I need to take that into account.
But I’m not sure if Siril knows how to handle WCS info on a bayered fits file, will it do the right thing?
Don’t try to adapt the focal length to the fact it’s undebayered or you want to downscale, Siril will adapt the values based on the options you’ve passed.
Thanks @cissou8 , but the parameters is not what I’m asking about. I mean which fits headers will it use? I do not believe these are documented. I can provide pixel scale or calculate a focal length, but it is a little harder to include the full WCS solution for every image.
I’m not sure I understand then. Do you mean in siril or to use solve-field?
In Siril, you don’t need to have all the WCS info included in the header (it’s easier but not mandatory). That’s what’s written in the documentation: If WCS or other image metadata is erroneous or missing, arguments must be passed. I was trying to answer your question:
are the WCS headers an “all or nothing” thing?
If you pass arguments, they will override the corresponding headers
If you absolutely want to fill the header yourself, it uses FOCALLEN and XPIXSZ and XBINNING (the later depending on your preferences) to compute the sampling. And RA/DEC (in decimal degrees) to compute the center of the field of view. They all correspond to the different arguments of the platesolve command.
here’s a use case: say I want to do a photometric calibration. If I click on the button it opens up the menu and pre-populates the focal length from somewhere (I don’t know where). If I had added FOCALLEN headers to my fits files during capture, will it appear here?
Then going further than this, what else is passed to solve and/or the calibration menu if it exists in the header?
If it’s pulling out FOCALLEN (both in the menu and in the platesolve command), that’s good news and I’ll look to include that.
You mentioned it also uses RA / DEC is that the exact fits header it will use? I wasn’t aware of those headers, in wcsinfo this would be ra_center and dec_center, I can probably include those.
Platesolve uses all the cards i’ve listed above. I’m not sure what you mean by “calibration”. If it’s Siril calibration tab, it does not use any of this.
Well, it can also use CRVAL1 and CRVAL2. But as those wcs keys are pretty much useless without the rest of the mandatory wcs keys, acquisition software don’t write them using this syntax, they just write RA and DEC. I strongly advise you against RA_CENTER and DEC_CENTER, as the FITS standard limits the length of keys to 8 characters (well you can go past this, but don’t expect other software to implement the looser version with the HIERARCH syntax).
You can find a list of keywords used by siril there: FITS — Siril 1.4.1 documentation
