BLACK FRIDAY & CYBER MONDAY SALE!
DISCOUNT OF 15% ON ANY LICENSE!
Sale will end on Tuesday, 30 November 2021, 1200 UTC.
ZWO image meta data is bogus for mono cameras (FITS)
When loading up ZWO mono files it is apparent that the FITS header is wrong. I have contacted ZWO and they have fixed it on more recent camera software. My questions: 1) will this have an effect on the image processing (1.082) if the FITS data is wrong? the preview screen shows colors which tells me it APP seems to use the FITS data. 2) will APP allow me to fix the FITS headers on older files?
Specifically the 'BAYERPAT" value is set to GRBG, when it should be set to none, or no BAYERPAT should exist.
What imaging software and which version of the ZWO driver did you use? I checked my mono images taken with Ekos (on Linux) in June 2020 and the BAYERPAT keyword is not available in the FITS header. Is the FILTER keyword present in the FITS headers of your images and does it have the correct value?
@randy-dunton To answer your two questions:
1) Yes this will have effect on image processing in APP, however this can be prevented. In tab 0 you can choose No Interpolation. That will completely ignore the BAYERPAT keyword and will treat your data as grey scale.
2) FITS headers cannot be edited in APP. But with the option given in answer 1) this should not be necessary.
Thanks Wouter !
I will redo the processing using the "no interpolation" option. Looking forward to a full manual on APP.
I use ASICAP V 1.6.2, I do not like the newer versions of ASICAP (less control), I will see if I can fix this issue as well.
Here is the FITS header as it is read by APP on my Ha channel, the FILTER keyword is not there it seems, but BAYERPAT is. Deep Sky Stacker was also having problems with this, they added a feature to read the FITS header just recently.
ZWO fixed the problem recently on ASICAP and the driver, I just have 2 years of data I need to reprocess with APP, so looking for a solution. Thanks again for you prompt help in this matter.
FITS HDUs: 1
HDU1 - SIMPLE = T / file does conform to FITS standard
HDU1 - BITPIX = 16 / number of bits per data pixel
HDU1 - NAXIS = 2 / number of data axes
HDU1 - NAXIS1 = 4656 / length of data axis 1
HDU1 - NAXIS2 = 3520 / length of data axis 2
HDU1 - EXTEND = T / FITS dataset may contain extensions
HDU1 - COMMENT FITS (Flexible Image Transport System) format is defined in 'Astronomy
HDU1 - COMMENT and Astrophysics', volume 376, page 359; bibcode: 2001A&A...376..359H
HDU1 - BRIGHT = 10 / Brightness of image
HDU1 - BSCALE = 1 / physical = BZERO + BSCALE*array_value
HDU1 - BZERO = 32768 / physical = BZERO + BSCALE*array_value
HDU1 - CBLACK = 0 / Initial display black level in ADUs
HDU1 - CWHITE = 65535 / Initial display white level in ADUs
HDU1 - EXPOINUS= 180000000 / Exposure time in us
HDU1 - GAIN = 180 / The ratio of output / input
HDU1 - PEDESTAL= 0 / Correction to add for zero-based ADU
HDU1 - XBINNING= 1 / Binning factor in width
HDU1 - YBINNING= 1 / Binning factor in height
HDU1 - BAYERPAT= 'GRBG ' / Debayer pattern,such as RGGB,BGGR,GRBG,GBRG
HDU1 - COLORTYP= 'RAW16 ' / Color space, such as RAW8,RAW16,RGB24
HDU1 - CSTRETCH= 'Medium ' / Initial display stretch mode
HDU1 - DATE-OBS= '2020-11-26T01:44:26.884' / UTC start date of observation
HDU1 - INPUTFMT= 'FITS ' / Format of file from which image was read
HDU1 - SWCREATE= 'ASICAP ' / Name of software that created the image
HDU1 - SWOWNER = 'ZWO ' / Licensed owner of software
HDU1 - XPIXSZ = 3.8 / Pixel Width in um (after binning)
HDU1 - YPIXSZ = 3.8 / Pixel Height in um (after binning)
HDU1 - END
My pleasure. Please let us know here if this solution worked in case other users encounter a similar issue.
I seem to have the same problem. I have a QHY600M which I am using with kstars/ekos. The FITS files contain BAYERPAT RGGB by default and I can change it to say Mono but there doesn't seem to be a way to have it not write something in that field. If I change it to Mono and try and process some dark or bias files then it shows CFA is mono and color space Gray 16b on the images but the integrated file color space is 16b RGB.
When doing the integration it goes through R, G1, G2, B channels in producing a bad pixel map.
Force CFA is disabled.
If I try no interpolation then the integrated master bias is still 16b RGB color space and it does the R, G1, G2, B channels to produce a bad pixel map.
The integrated Dark file has color channels but the RGB all appear to be the same. Maybe this is the correct form for Dark for APP from mono?