I do not think anyone can mind ChatGPT or other AI, I even use Copilot officially in my work. This is the future, better get used to it before rather than later

I got it to work by commenting out a few imports and places. But yeah, it's probably pip vs apt. In particular as I use pip with venv.

OK, the most recent commit does:

- fix dng files
- fix fits processing
- added "gain" control
- added bits per pixel ( in image info
- should set bounds correctly (can't subframe yet, though, as I'm not sure what should be set to what)
- consolidates setting of options
- replace use of mmap when putting together the image, this fixes a crash that will occur randomly

Issues and TODOs:
- FITS files are still very dark, no idea why.
- gain apparently only works with jpeg (still and stream), not raw files. At least it doesn't show any changes
- for the correct "main" sizes, we should probably have a selection
- for subframes I think we need to use "rio" in the 0...1 range, but I'm not sure on what base
- there should be brightness etc controls, like in v4l2 but the creation there seems to be very dynamic. not sure if this applies here, too.

In general, I found playing with the command line apps pretty inconsistent.

On the bright side, the IMX290 seems to have 7s exposures which is a lot more than the usb imx 290 cam has (156ms or so, the rest with stacking).

Awesome progress Anjo! Do you think you can submit a PR now to INDI so that we can perhaps make this available for more users to test?

@Jasem can you give me some pointers on how the new properties are supposed to be used?

Here you go, but I won't be doing cosmetics just yet. There's just too much stuff I'm not sure if it's ok or not.

github.com/indilib/indi-3rdparty/pull/697

Here's some more properties, I guess this can be used to create them dynamically. I think it's "low,high,current":

>>> pprint.pprint(picam2.camera_controls)
{'AeConstraintMode': (0, 3, 0),
'AeEnable': (False, True, None),
'AeExposureMode': (0, 3, 0),
'AeMeteringMode': (0, 3, 0),
'AnalogueGain': (1.0, 16.0, None),
'AwbEnable': (False, True, None),
'AwbMode': (0, 7, 0),
'Brightness': (-1.0, 1.0, 0.0),
'ColourCorrectionMatrix': (-16.0, 16.0, None),
'ColourGains': (0.0, 32.0, None),
'Contrast': (0.0, 32.0, 1.0),
'ExposureTime': (0, 66666, None),
'ExposureValue': (-8.0, 8.0, 0.0),
'FrameDurationLimits': (33333, 120000, None),
'NoiseReductionMode': (0, 4, 0),
'Saturation': (0.0, 32.0, 1.0),
'ScalerCrop': (libcamera.Rectangle(0, 0, 0, 0),
libcamera.Rectangle(65535, 65535, 65535, 65535),
libcamera.Rectangle(0, 0, 0, 0)),
'Sharpness': (0.0, 16.0, 1.0)}

You can create them using XML skeleton file or directly in the source using INDI::PropertyNumber. I you have static number of properties that will be always there then you can declare in the header INDI::PropertyNumber ControlsNP {10} for example for 10 controls and then in initProperties you define them

I'd rather prefer something like the V4L driver does, ie auto create menus and controls, but I guess there's no corresponding API for the creation of visible names.

And finally, controls for about everything (brightness, f-stops, contrast, awb etc).

It just doesn't look like the images get better when you play around with them.

I can only speak about Raspberry Pi cameras directly connected to the CSI port:

Only exposure time ("ExposureTime") and analogue gain ("AnalogueGain"") influence raw pictures. True raw pictures have a Bayer pattern like "RGGB" (with two "G" in it!). Formats like "RGB" or "YUV" are already processed by the Image Signal Processor (ISP) on the Raspberry Pi.

It is my strong opinion that processed pictures are useless for later stacking:

• One of the very first steps in the ISP is to subtract the black level. In contrast to a dark frame subtraction a factory value is used here. This is not measured on your particular image sensor. Ususally the value used as black level is too high. You can be lucky when you have enough light pollution. But when observing a really dark sky all faint structures like nebulas will be saturated to black. There is no way to correct this afterwards.
• The ISP uses fixed point arithmetic and scales the resulting frame to 8 bit. This adds a lot of discretization noise. A good stacking software does all these things with floating point arithmetic.
• Lossy compression like JPG adds so many artifacts to underexposed pictures that after stacking with a good software you can not believe anymore what you see.

I would recommend to focus on raw Bayer pictures.

@Anjo you did an impressive work. Thanks.

If I understand correctly your code, libcamera driver resolution is not updated with resolution update messages coming from indi server

Maybe adding/editing the following lines could help: