lock replied to the topic 'Request for a new FITS keyword' in the forum. 4 months ago

Following the add, I've opened a MR in kstars: invent.kde.org/education/kstars/-/merge_requests/37

Read More...

lock replied to the topic 'Request for a new FITS keyword' in the forum. 5 months ago

Thank you Patrick for the clarification.
And thanks Jasem for the quick fix.

Read More...

lock replied to the topic 'Request for a new FITS keyword' in the forum. 5 months ago

Hello,

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.

Cyril

Read More...

lock created a new topic ' Request for a new FITS keyword' in the forum. 5 months ago

Hello,
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,
Cyril

Read More...

lock replied to the topic 'Bug in fitsdata.cpp' in the forum. 9 months ago

Probably an error ...
Sorry for that.

Read More...

lock replied to the topic 'Bug in fitsdata.cpp' in the forum. 9 months ago

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?

Many thanks,
Cheers,

Read More...

lock replied to the topic 'Bug in fitsdata.cpp' in the forum. 9 months ago

@hy:

OK, my tests shows (am I wrong?) that:

<code>
case DC1394_COLOR_FILTER_GRBG:
debayerParams.filter = DC1394_COLOR_FILTER_GBRG
</code>

Would be the fine transformation.

Read More...

lock replied to the topic 'Bug in fitsdata.cpp' in the forum. 9 months ago

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;
        }


Read More...