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?
OK, my tests shows (am I wrong?) that:
debayerParams.filter = DC1394_COLOR_FILTER_GBRG
Would be the fine transformation.
I think you switched bayer pattern, I would write:
case DC1394_COLOR_FILTER_RGGB: debayerParams.filter = DC1394_COLOR_FILTER_GBRG; break; case DC1394_COLOR_FILTER_GBRG: debayerParams.filter = DC1394_COLOR_FILTER_RGGB; break; case DC1394_COLOR_FILTER_GRBG: debayerParams.filter = DC1394_COLOR_FILTER_BGGR; break; case DC1394_COLOR_FILTER_BGGR: debayerParams.filter = DC1394_COLOR_FILTER_GRBG; break; }