The driver can get them from the hardware in many cases. It's the same reason we have pixel size and similar in the driver, the driver/camera knows and the client/user may want to know.

They aren't variables, they're constants. The bayer pattern is fixed for a given camera, as is the fact that it's monochrome or color.

The client should be able to ask the camera driver for those values and then be able to act on the results. If for some reason the camera doesn't expose those values, the user could specify "custom" or something in the client and pick them, but most cameras internally have a way to determine whether they are color or monochrome and what their offsets are. In windows, the camera driver is what exposes this information. I know this because I've been writing software using ASCOM on windows for good long while and it provides that data for every camera I have ever connected. On windows, I've been able to write software that properly handles any camera I've ever used, whether it was color, monochrome, DSLR you name it. It would be nice if INDI worked the same way

They're variables as far as the client is concerned. For GPhoto driver for example, the bayer pattern differs for different cameras, and I don't believe GPhoto provide such information, it has to be filled by the user. At any rate, there is noting in principle against including such information in the driver as RW. How should the bayer pattern be represented, just a string (BGGR, RGGB...etc)?

One possibility would be two new properties under CCD_INFO and one new text property:
1. CCD_INFO CCD_CFA_OFFSET_X
2. CCD_INFO CCD_CFA_OFFSET_Y
3. CCD_CFA CCD_CFA_TYPE

The CCD_CFA_TYPE would represent the "family" of color filter array such as RGGB, CMYG, RGBE, etc. and would be used by the client to pick the correct algorithm. The offsets for X and Y would allow the client to choose the correct starting point such as the difference between RGGB and GBRG which use the same algorithm, but with a one row offset.

I think that this data for the GPhoto could be provided by the driver based on the model of the camera even if GPhoto doesn't itself provide it. The real win here is to make it so the driver developer who is the one with the knowledge about the hardware provides it downstream to the client such that the client can use any conformant driver and hardware. Even if the hardware or GPhoto in this case doesn't know/provide that information there is a list of supported devices for which the data could be looked up and then included in a table in the driver in order to populate the appropriate properties.

That's not practically feasible, we can't keep a lookup table with the driver, it is doomed to be out of date very soon. Also, you can't possibly cover the cameras supported by GPhoto, it is a huge undertaking. Since this information needs to be only entered once, let this task fall be the burden of the user. For other CCDs, the offsets and patterns are known and can be hardcoded in the driver itself. We can add the CCD_CFA property, but it will not part of the CCD_INFO property since CCD_INFO is RO (only exception is GPhoto where it is RW, again due to GPhoto limitations). I will try to work on that in the new few days.

I would think this data would be RO. Even if the user sets it, there's no reason to send it back to the driver since the driver isn't doing anything with it anyhow, right?

Please do not invent the wheel, use BAYOFFX and BAYOFFY properties in FITS header. Offsets are property of the image, not the camera, remember that you can use subframe and not necessary on mask boundaries!

Cyanogen has different opinion on keyword names, but defines both mask type and offsets:

www.cyanogen.com/help/maximdl/FITS_File_Header_Definitions.htm

FITS header properties are fine by me for that, but need to also ensure we define the CFA pattern as well. It's a shame those properties are misnamed since technically there is only one Bayer pattern and all the other variants are not Bayer, but different Color Filter Array patterns.

Just FYI for those following the thread, bayer info are recorded in the FITS header for GPhoto and SBIG drivers as of now.

Jasem, can you share some raw colour FITS to let us test client implementation? Thank you, Peter