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.

OK, so I re-added CloseCamera/OpenCamera calls so the cam is now locked only for the duration of shots.

Playing with the text props will still crash, so be careful with them. Probably best leave them at the first item.

And I added width/height setting. You need to do this on the "Image Setting" page - and make sure your width is divisible by 2.

I also noticed that you can't compile the driver on buster, as there are changes in libcamera (exposure is a long, not a pointer and a few other things). Then again, it probably won't run the newer cams anyway.

@OUTTA Have you seen this: github.com/raspberrypi/libcamera-apps/issues/344

I have the waveshare module and contrary to what it reports

2022-12-22T16:38:58: Driver ../build/indi-libcamera/indi_libcamera_ccd: ExposureTime : [14..7229147]

it seems like it does expose for 15s?

Interesting I have IMX462 but it does not seem to work as expected.
Do you run V4L2 command before or that is in driver? Is that PR in latest version?

Also one thing i noticed about gain, do you use "gain" or "analoggain" parameter. Gain is digital, and analoggain is one we are interested in.

From the core and help texts both gains are synonymous

Indeed you are right,and I have been writing "analog" to terminal for nothing whole last year or so

Libcamera knows:

"analogue_gain": This tunes a physical amplifier between pixel circuit and ADC on the camera chip. It influences raw and processed frames.

"digital_gain" and "colour_gains": These are parameters of the software running in the ISP for processing the frames. They are digital multiplication factors and influence only the processed frame. The "colour_gains" are used to set the white balance.

Yeah, but:

www.waveshare.com/wiki/IMX519-78_16MP_AF_Camera#libcamera-jpeg

"The gain parameter set will first set the analog gain parameter inside the photosensitive chip. If the set gain exceeds the maximum built-in analog gain value of the driver, the maximum analog gain of the chip will be set first, and then the remaining gain multiples will be used as numbers. gain to take effect. "

So you unless you exceed the analog gain max, you'll never use the digital gain.

That "gain" is implemented by the "libcamera-jpeg" application. But the "libcamera" library distinguishes between analogue and digital gains.

The "libcamera" has algorithms for automated gain control (AGC) and automated exposure control (AEC). As long as these algorithms are not disabled the gain and exposure time settings are ignored (or used as start values for the optimization). I do not know if "libcamera-jpeg" disables the algorithms automatically when you set values for gain and exposure time. But when you use "libcamera" directly you need to disable the algorithms explicitly. Otherwise you will have no control over final exposure time and gains.

The AGC/AEC algorithms do experimental exposures to find optimized values for exposure time and gains. Not only that you do not have control over the final exposure time and gains you will also wait much longer until you get the frame.