FITS missing COLORTYP, causes DSS to fail

[Séverin Beauvais]

Found in NINA 2.0 BETA001.

Lights and flats were taken using a ZWO OSC camera. The saved FITS were read into Deep Sky Stacker for processing, along with darks taken previously with SharpCap Pro. DSS would not process the images, saying the pictures are not compatible due to misc parameters. The only thing I can see different between the images is the FITS headers: the darks taken with SCP have an additional COLORTYP field, while the lights taken with NINA do not. I believe this is causing DSS to misinterpret the files.

This issue is preventing me from using my previous darks in DSS to process images taken with NINA.

Sample files:

• a light taken from NINA
• a dark taken from NINA
• a dark taken from SCP
• error message from DSS

‌

[Séverin Beauvais]

I am not sure if my analysis is correct, but the fact remains that lights taken with NINA are not compatible with darks taken with SCP.

[Dale Ghent]

NINA FITS files include the BAYERPAT keyword which supersedes COLORTYP. DSS has supported BAYERPAT since version 4.2.5.

[Séverin Beauvais]

Thanks for the quick reply.

I am using DSS 4.2.6.

Then I don’t know why I cannot use my previous darks in DSS.

‌

[Dale Ghent]

Perhaps the image dimensions are different?

[Dale Ghent]

I am 4 meters up on a ladder at the moment, so I cannot look at your images until later. You can open both dark and light images in DSS and see if the image dimensions are different. It is not uncommon for different apps to produce slightly different image sizes, by an extra row of pixels or so, depending on how they use the ZWO SDK for their respective native driver implementations.

[Séverin Beauvais]

edited sample file descriptions

[Stefan B]

The issue here is most likely the way SCP differs in writing FITS files compared to NINA. While SCP writes the fits as bottom-up, NINA writes it as top-down (both is allowed per the fits standard). This is also indicated by the "ROWORDER" keyword in the header. Most likely DSS doesn't support this relatively new keyword. This results in the BayerPattern being reversed and thus making it incompatible. Looking at the uploaded FITS files, all necessary header keywords are set. This is not a bug but rather an issue with the loose FITS standard making these incompatible in DSS.

[Séverin Beauvais]

See updated files.

I noticed that the NINA FITS files have EXPOSURE=120.0, while the SCP FITS file has EXPOSURE=120.

[Dale Ghent]

Hello Séverin. Per section 4.2.4 of Definition of the Flexible Image Transport System, version 4.0, both formats are valid representations of a floating-point number.

As said in our previous messages, NINA embeds all the information that DSS needs to debayer the image. It is the responsibility of DSS to reconcile any stylistic differences in metadata that are contained in images produced by two different imaging systems. Stefan gave a perfectly reasonable explanation as to why you are experiencing this issue - the open-endedness of the FITS standard leaves even the row ordering of the image up to each program to decide, and incompatible images sometimes result when mixing FITS images that were created by different programs. No program is wrong in this case. This is why is it always strongly recommended that you stick to a single source for your images. If you switch programs, you should make new calibration frames using that same program. I will note that in the many hours since you first raised this issue, a new set of dark frames could have been created.

‌

[Séverin Beauvais]

Thank you Dale and Stefan for your quick responses, patience, references, and work on NINA.

(Yes, I did create a new set of darks for this resolution/ exposure/ gain today.)

PS I hope to be able to contribute to NINA myself.