[libcamera-devel] [RFC PATCH 03/14] controls: Replace AeLocked with AeState, and add AeLock

Naushir Patuck naush at raspberrypi.com
Wed Jun 23 11:06:00 CEST 2021


Hi Jacopo and David,

On Wed, 23 Jun 2021 at 09:12, Jacopo Mondi <jacopo at jmondi.org> wrote:

<snip>


> >
> > Are we saying that AeDisable means "stop adjusting the AEC/AGC
> > immediately, whether it's converged or not", but AeLock means "wait
> > until it's converged and then immediately stop adjusting the AEC/AGC"?
>
> If AeLock is set on a Converged state then yes, the values are not
> changed until the lock is lifted.
>
> Does the transition table repoted here helps ?
>
> https://developer.android.com/reference/android/hardware/camera2/CaptureResult#CONTROL_AE_STATE
>
> Thanks
>    j
>

Having a brief look at the above document, I think
Jacopo's description makes
sense now.  Enabling AeLock locks the current AE computed values, whether
the algorithm has converged or not.  However, with AeLock set to on, other
controls are effectively ignored by the AE (e.g. aePrecaptureTrigger, maybe
other things as well).  Not sure why this is the case, as the application
surely
knows what state it wants the AE to be in...?

We don't deal with pre-capture sequences in RPi AE, so for us AeLock and
AeDisable are actually the same thing.  Thinking about it, even with a
pre-capture
sequence, we could probably say the same.  This may also be the case for
other vendor AE algorithms, but Android makes these states explicit.

 Or it could be that I've just completely misunderstood that document :-)

Naush
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libcamera.org/pipermail/libcamera-devel/attachments/20210623/5117ce7e/attachment.htm>


More information about the libcamera-devel mailing list