The explanation is quite easy. Some RGB images have a CTYPE3 = 'RGB' keyword (for Aladin compatibility). It implies the existence of WCS axis 3.
The missing keywords for axis 3 (e.g. CD3_3) assume their default values. The default value for CD3_3 is 0.0, leading to a singular matrix.
The Cdfix value tests for it and fix. In consequence there is no problem using it. And this is also the reason why we need to extend the size of the tab.
Hello there. I've opened a MR about an issue I found with the fitsviewer and the ability to detect and parse wcs information.
This is here: invent.kde.org/education/kstars/-/merge_requests/150
If someone wants to review and/or speak with me about it. That would me my pleasure.
Following the add, I've opened a MR in kstars:
Thank you Patrick for the clarification.
And thanks Jasem for the quick fix.
I'm really glad to read these enthusiastic answers.
Jasem, of course there is no rush. It has been introduced in Siril this week and will only be available for the 1.0.0 release.
But I have to say I'm really happy you want to do that. It will be easier for everyone.
I'm one of the developer of Siril software.
We recently wrote a short document explaining why we've had added a new FITS keyword and why we would like that every FITS data producers do the same.
The document: free-astro.org/index.php?title=Siril:FITS_orientation
In addition to this (we will add this to the doc soon), from ui.adsabs.harvard.edu/abs/2002A%26A...395.1061G/abstract :
5.1. Image display conventions
It is very helpful to adopt a convention for the display of images transferred via the FITS format. Many of the current image processing systems have converged upon such a convention. Therefore, we recommend that FITS writers order the pixels so that the first pixel in the FITS file (for each image plane) be the one that would be displayed in the lower-left corner (with the first axis increasing to the right and the second axis increasing upwards) by the imaging system of the FITS writer. This convention is clearly helpful in the absence of a description of the world coordinates. It does not preclude a program from looking at the axis descriptions and overriding this convention, or preclude the user from requesting a different display. This convention also does not excuse FITS writers from providing complete and correct descriptions of the image coordinates, allowing the user to determine the meaning of the image. The ordering of the image for display is simply a convention of convenience, whereas the coordinates of the pixels are part of the physics of the observation.
Do you think it would be possible to introduce this in the EKOS/INDI ecosystem?
My best regards,
Probably an error ...
Sorry for that.
No problem Hy, I think you're right. Also, the header of my file is probably wrong too. But, I'm happy because it helps to fix wrong code.
Last remark, maybe it would be better to apply same fix for yoffset? In order to avoid junk row?