The Moravian Instruments C4-160000 camera is a dual-gain CMOS camera, which requires taking Dark and Light Frames in two gain settings (read modes). Ideally, I would like to take and preprocess the images with ekos, but currently this is not possible. Instead, SIPS.exe is needed at least to pre-process the images. However, when images are taken with ekos, the sips.exe cannot process because of missing FITS headers indicating the read mode. Likewise, any other program with preprocessing (i.e. PixInsight) will need to know what read mode was used for processing.
These calibration images are critical for calibration, and we need a few more features to make them work in an automated way:
Read Mode | GAIN | DATAMAX |
---|---|---|
16-bit HDR | 0.82 | 65535 |
12-bit hi-gain | 0.82 | 4096 |
12-bit lo-gain | 18.69 | 4096 |
"16-bit" lo-gain | 0.82 | 65535 |
The FITS headers are needed to identify the read mode and also make it possible to pre-process the images with the SIPS.exe from MI.
The FITS header make identification easier and also make output compatible with the MI SIPS.exe program, required for calibration. Perhaps adding a "READMODE" fits header would also help some users.
To fully pre-process the images in ekos, processing must take two DARK and FLAT frames into account. When the measured value (in the 16-bit HDR image) is less or equal to a threshold value, use the 12-bit-hi-gain DARK/FLAT image... Otherwise, use the "16-bit" lo-gain DARK/FLAT images.
The threshold for the C4-160000 camera is 3600 ADU. This is the same procedure taken by the camera, when the HDR mode is used. The documentation for this is in the C4 Camera User's Guide page 43ff:
https://www.gxccd.com/download/C4%20Manual.pdf
I think this new kind of 2-gain cameras will become more common and ekos should be able to pre-process such data as well. Of course, we can make a script to do it outside ekos, but it would be much nicer to have this feature buildin.
Please file this issue at https://github.com/indilib/indi-3rdparty
Hi Jasem, I duplicated the report there: #522
Correction: The table has a typo: the two 4096 values should read 4095.