Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PHD2 debayer and CCD_CFA attribute #68

Open
1 of 6 tasks
scriptorron opened this issue May 9, 2024 · 1 comment
Open
1 of 6 tasks

PHD2 debayer and CCD_CFA attribute #68

scriptorron opened this issue May 9, 2024 · 1 comment

Comments

@scriptorron
Copy link
Owner

scriptorron commented May 9, 2024

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:

  • 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".

@scriptorron
Copy link
Owner Author

INDI CCD_CFA attribute according to https://www.indilib.org/developers/deveioper-manual/101-standard-properties.html and code analysis of indi_lib:

  • Name: CCD_CFA
  • Label: "Bayer Info"
  • Access: R/W
  • Type: TEXT
  • Members:
    • CFA_OFFSET_X, "X Offset", default: 0
    • CFA_OFFSET_Y, "Y Offset", default: 0
    • CFA_TYPE, "Filter", nullptr

Values of CFA_TYPE seen in code:

  • "RGGB", "GBRG", "BGGR", ""GRBG",
  • after loading FITS: same value as FITS BAYERPAT attribute
  • when saving a FITS the BAYERPAT attribute is taken from CFA_TYPE
  • dci_ccd.cpp, line 263: mono frame has CFA_TYPE=""
  • not sure if mono and RGB images have CFA_TYPE="" or completely miss the CCD_CFA attribute

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant