[libcamera-devel] How to activate AGC control in libcamera, or set the GAIN/EXPOSURE parameter by v4l2 command.

[tetsuya.nomura at soho-enterprise.com]

Dear Naush-san

Thank you for your information.

If you need to know the correct exposure time, it can be calculated from the register value,
Input clock frequency is 24MHz, PLL parameter to calculate the one clock period of the video transfer clock, line_length_pck to calculate the length of the line in usec, and the coarse_integration_time in unit of line.
If extending the v-total-size for 15fps operation, use the frame_length_line parameter.

I hope I could provide you the necessary information.

Best Regards,

NOMURA

-----Original Message-----
From: Naushir Patuck <naush at raspberrypi.com> 
Sent: Monday, October 5, 2020 5:46 PM
To: David Plowman <david.plowman at raspberrypi.com>
Cc: tetsuya.nomura at soho-enterprise.com; libcamera-devel at lists.libcamera.org
Subject: Re: [libcamera-devel] How to activate AGC control in libcamera, or set the GAIN/EXPOSURE parameter by v4l2 command.

Hi David and Nomura-san,

On Mon, 5 Oct 2020 at 09:16, David Plowman <david.plowman at raspberrypi.com> wrote:
>
> Hello again Nomura-san
>
> Yes, my apologies. I should have been clearer that putting "#define 
> RPI_LOGGING_ENABLE 1" at the top of the file means *before* all the 
> includes. So there may be lots of extra debug that we're not 
> interested in, but we can still see what we need.
>
> Near the bottom of the file I see:
>
> computeGain: Initially Y 0.316143 target 0.320543 gives gain 1.01072
>
> which means that the raw image has reached its target brightness level 
> which is set to about 0.32 of the full dynamic range. Actually it 
> appears to be about 1% below, this is probably because exposure time 
> and analogue gain get slightly quantised because the camera cannot 
> deliver the exact values the AGC algorithm wants.
>
> We also have
>
> writeAndFinish: Camera exposure update: shutter time 60000 analogue 
> gain 6.15941

If I understand things correctly, there may be a slight problem with this.  Currently, the Raspberry Pi pipeline handler cannot send an exposure > 33ms to the sensor.  This is because the v4l2 driver requires us the extend the VBLANK ctrl appropriately to match a 15fps / 66ms exposure request.  Since imx219 does not use embedded metadata at present, there is no way of knowing that it has actually returned 33ms.  The staggered write only returns what was requested of it, i.e.
60ms in the above case.  imx477 uses embedded data, so it would correctly report that the 60ms request actually only returned 33ms.

My up-coming changes for exposure and fps control fix this issue and send the staggered write what will actually be accepted by the sensor driver after clipping -  or in this case, it would extend VBLANK to allow 60ms correctly.

Regards,
Naush



>
> so the algorithm is requesting an exposure time of 60ms and an 
> analogue gain of 6.159x, and it looks like these values are being 
> achieved (apart from 1% quantisation error).
>
> So in your case, the limiting factor is indeed the y_target, and not 
> the exposure/gain limits, and further increasing the y_target should 
> result in the analogue gain going even higher. I forget exactly what 
> the maximum gain is that this sensor supports, but if you ask for 
> larger values you should see the algorithm applying any extra (above 
> what the sensor can deliver) as digital gain. Obviously it will all 
> get noisier and noisier!
>
> Best regards
> David
>