[libcamera-devel] AeLock proposal v4

[Kieran Bingham]

Hi Paul,

On 15/09/2021 09:56, paul.elder at ideasonboard.com wrote:
> Hello,
> 
> Here's v4 of the aelock proposal, based on what we discussed in the
> meeting yesterday.
> 
> Requirements:
> - LOCK: AGC do not update output results
> - MANUAL: override the values computed by AGC
> - SEAMLESS TRANSITIONS: no flickering
> - custom minimum values for the manual controls (no magic value for
>   enabling auto)
> 
> The conclusion was that the locked state, as an explicitly selectable
> state for the user, is unnecessary. Its presence causes not-very-nice
> cases (eg. manual -> locked transition, manual with no values, etc), so
> we've decided to turn it into an implicit state combined with manual,
> with the presence of a manual control value to act as a trigger to
> switch from the internal "locked" state to "manual" state. This blocks
> going the other way, but allows going back to auto.
> 
> We of course have separate controls for the sub-controls.
> 
> In which case the design is so simple that we don't need a diagram...?
> 
> Controls:
> 
> ExposureTime
> - input: the manual exposure time value to use
> - output: the exposure time value that was used for the request that is
>   returned
> 
> ExposureTimeMode:
> - states: Auto, Disabled
> - input: In Auto mode use the exposure time value computed by the AEC.
>   In Disabled mode, don't update the exposure time value until
>   ExposureTime is provided. When it is, start to an continue to use the
>   provided value.

This implies that the 'last setting from auto' will persist?
So to implement the 'lock' options we've seen in Android - it sounds
like we can just move from Auto ExposureTimeMode to Disabled
ExposureTimeMode?


> - output: the mode that was used for the request that is returned
> 
> Same two controls for AnalogGain.
> 
> 
> The flow for seamless switching from auto to manual:
> 1. Set ExposureTimeMode to Disabled
> 2. Wait for the first request where ExposureTimeMode is Disabled
> 3. Copy the ExposureTime value from that request, and submit it

Is this from the perspective of the application or an IPA?

(I assume Application?)

But in that case, I would presume they would be able to / expect to set
ExposureTimeMode to Disabled (This really sounds like 'Manual' mode to
me?) and set the ExposureTime value that they want ...

Why is the 'waiting' necessary? - or indeed the copying of a value from
that request to resubmit it ? Surely resubmitting the value from that
request, is the same value it would stay on anyway?

Perhaps I haven't grasped the 'requirement' for 'Seamless'.

I guess the process above is to allow the app to 'know' what value the
'last' automatic setting provided. (I.e. the first time a request comes
back with ExposureTimeMode as Disabled, that request control metadata
tells the app what the exposure was at that point, and then it's up to
the app to make changes from there.



> If a manual value is provided while the mode is auto, the manual value
> will be ignored.
> 
> 
> The one thing that deviates from the consistency is that a value-control
> is used as a trigger. Its value is still saved (thus resubmission is
> unnecessary if the value doesn't change), but its presence acts as a
> trigger to switch from the internal locked state to manual state. This
> is seen as fine, since it's not too intrusive, and it enables a cleaner
> API.

Sounds fairly good to me so far.
Much easier to digest anyway ;-)

Setting ExposureTimeMode=Disabled(/Manual) without giving a value, I
would expect it to 'stay as it was, whatever the last auto value
calculated was'.

So indeed that's the same as an internal 'lock'.

Kieran