PHD2 preview shows Bayer pattern of HQ camera. Star profile has many peaks. This happens with binning 1 and 2. The issue disappears when enabling 2x2 averaging in the PHD2 settings. For now the 2x2 averaging is the only workaround.
It seems, PHD2 does not know that the image data are from a CFA with Bayer filters. A code analysis showed that PHD2 detects Bayer data when the camera has the CCD_CFA/CFA_TYPE attribute. Than the code seems to debayer the data only for binning 1 and independent of the CFA_TYPE value.
Any string in CFA_TYPE is enough to tell PHD2 that the camera provides Bayer data. This decision can not be reverted by deleting the CCD_CFA attribute! (Missing feature in PHD2?)
If PHD2
has detected a CFA frame and
binning is 1 and
CAPTURE_RECON is enabled in capture options (where in settings?)
the frame gets a simple debayer (sliding 2x2 window) to calculate luminance. Image resolution stays unchanged. This is exactly the same algorithm as used for 2x2 averaging.
At least the missing debayering for binning 2 will be critical (is that a missing feature in PHD2?).
Open questions:
[x] What values are allowed for CFA_TYPE?
[ ] How to handle monochrome images?
[ ] How to handle RGB images?
[ ] How to check the correct implementation of CCD_CFA? Are there INDI clients which evaluate the INDI CCD_CFA and not the FITS BAYERPAT attribute to decide the pattern type? Is there a risk that a wrong CFA_TYPE leads to a wrong interpretation of the color channels?
[ ] The earliest time the indi_pylibcamera driver knows the CFA type is after camera configuration (or even after first image capture). Do clients allow such late change of the CCD_CFA?
[ ] What if a different camera configuration is selected in indi_pylibcamera and the CFA type changes? PHD2 can not redo its decision!
Implementing the CCD_CFA attribute in indi_pylibcamera can lead to unexpected behavior in PHD2! It is safer to force the luminance calculation by enabling the "2x2 averaging".
PHD2 preview shows Bayer pattern of HQ camera. Star profile has many peaks. This happens with binning 1 and 2. The issue disappears when enabling 2x2 averaging in the PHD2 settings. For now the 2x2 averaging is the only workaround.
It seems, PHD2 does not know that the image data are from a CFA with Bayer filters. A code analysis showed that PHD2 detects Bayer data when the camera has the CCD_CFA/CFA_TYPE attribute. Than the code seems to debayer the data only for binning 1 and independent of the CFA_TYPE value.
Any string in CFA_TYPE is enough to tell PHD2 that the camera provides Bayer data. This decision can not be reverted by deleting the CCD_CFA attribute! (Missing feature in PHD2?)
If PHD2
the frame gets a simple debayer (sliding 2x2 window) to calculate luminance. Image resolution stays unchanged. This is exactly the same algorithm as used for 2x2 averaging.
At least the missing debayering for binning 2 will be critical (is that a missing feature in PHD2?).
Open questions:
indi_pylibcamera
driver knows the CFA type is after camera configuration (or even after first image capture). Do clients allow such late change of the CCD_CFA?indi_pylibcamera
and the CFA type changes? PHD2 can not redo its decision!Implementing the CCD_CFA attribute in
indi_pylibcamera
can lead to unexpected behavior in PHD2! It is safer to force the luminance calculation by enabling the "2x2 averaging".