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:

By the way: I implemented a libcamera driver for the HQ camera in Python: indi_pylibcamra

It runs on a Raspberry Pi Zero (Raspian without XServer) and delivers raw Bayer pattern images. It is in an early stage. For instance I did not check if the color information is set in the right order in the FITS. During a first check with a photo lense I got the impression that I exchanged blue and red. Local saving is also not implemented. And doing Connect->Disconnect->Connect leads to an error. It also needs documentation. I will continue to work on it after Xmas.

Marry Christmas and Happy New Year to all of you!

This fellow is smart listen to what he says.

Let me just digress on images from this implementation, in this current state, changing gain does not change histogram, and that is main thing you should watch. Changing exposure does change it, but up to certain point, depending what is supported from camera driver.

I know that imx290/462 can support up to 15s but to activate that mode you need to set some address, in driver to 0xFFFFF, and that is not implemented in RPI driver, only in arducam driver.

Actually, the DNG doesn't change at all with exposure and gain settings at least not from what I see. It's only after you shoot a jpeg it does change.

Also, the controls can be useful for a variety of things, getting video to work better being one.

So yeah, for the "actual" images raw is fine, but it's a lot more convenient when you have other options, too.

For me it does, but again not for raw images. They don't change at all unless you shoot jpegs first.

Thanks for this, I hope I'll get try it in the next few days.

Frankly, if I had time I would have written a pure python command line driver (ie, not using picamera2, but forking to a new process and getting stdout or the file it produces). Otherwise libcamera is just too flaky for my tastes.

I'd just have used a pre-exisitng lib like github.com/MMTObservatory/pyINDI/tree/mmtcam_stuff

I think they have a CCD template floating around. But I also definitely wanted video, and have no idea on how to show that on the client and how many props I would have to implement for it.

@Anjo

Thank you. Last week I started to write the driver based on the mentioned pyINDI package. But then I found too many things to work around and decided to implement the protocol by myself. It was not difficult.

I agree that having the possibility to get processed pictures has advantages. At least when you focus your telescope on a bright star you don't need raw images. In this situation it is more important to have short dead time between changing focus and seeing the effect on the image. With smaller JPG images you can save a lot transmission time. My Raspberry Pi needs about 13 seconds to transmit the Raw image - searching focus becomes a nightmare.