FITS missing COLORTYP, causes DSS to fail
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
Comments (10)
-
reporter -
NINA FITS files include the
BAYERPAT
keyword which supersedesCOLORTYP
. DSS has supportedBAYERPAT
since version 4.2.5. -
reporter 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.
-
Perhaps the image dimensions are different?
-
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.
-
reporter - edited description
edited sample file descriptions
-
repo owner - changed status to closed
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.
-
reporter See updated files.
I noticed that the NINA FITS files have EXPOSURE=120.0, while the SCP FITS file has EXPOSURE=120.
-
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.
-
reporter 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.
- Log in to comment
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.