path: root/Documentation/design/ae.rst

.. SPDX-License-Identifier: CC-BY-SA-4.0

Design of Exposure and Gain controls
====================================

This document explains the design and rationale of the controls related to
exposure and gain. This includes the all-encompassing auto-exposure (AE), the
manual exposure control, and the manual gain control.

Description of the problem
--------------------------

Sub controls
^^^^^^^^^^^^

There are more than one control that make up total exposure: exposure time,
gain, and aperture (though for now we will not consider aperture). We already
had individual controls for setting the values of manual exposure and manual
gain, but for switching between auto mode and manual mode we only had a
high-level boolean AeEnable control that would set *both* exposure and gain to
auto mode or manual mode; we had no way to set one to auto and the other to
manual.

So, we need to introduce two new controls to act as "levers" to indicate
individually for exposure and gain if the value would come from AEGC or if it
would come from the manual control value.

Aperture priority
^^^^^^^^^^^^^^^^^

We eventually may need to support aperture, and so whatever our solution is for
having only some controls on auto and the others on manual needs to be
extensible.

Flickering when going from auto to manual
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

When a manual exposure or gain value is requested by the application, it costs
a few frames worth of time for them to take effect. This means that during a
transition from auto to manual, there would be flickering in the control values
and the transition won't be smooth.

Take for instance the following flow, where we start on auto exposure (which
for the purposes of the example increments by 1 each frame) and we want to
switch seamlessly to manual exposure, which involves copying the exposure value
computed by the auto exposure algorithm:

::

                +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
                | N   | | N+1 | | N+2 | | N+3 | | N+4 | | N+5 | | N+6 |
                +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+

 Mode requested: Auto    Auto    Auto    Manual  Manual  Manual  Manual
 Exp requested:  N/A     N/A     N/A     2       2       2       2
 Set in Frame:   N+2     N+3     N+4     N+5     N+6     N+7     N+8

 Mode used:      Auto    Auto    Auto    Auto    Auto    Manual  Manual
 Exp used:       0       1       2       3       4       2       2

As we can see, after frame N+2 completes, we copy the exposure value that was
used for frame N+2 (which was computed by AE algorithm), and queue that value
into request N+3 with manual mode on. However, as it takes two frames for the
exposure to be set, the exposure still changes since it is set by AE, and we
get a flicker in the exposure during the switch from auto to manual.

A solution is to *not submit* any exposure value when manual mode is enabled,
and wait until the manual mode as been "applied" before copying the exposure
value:

::

                +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
                | N   | | N+1 | | N+2 | | N+3 | | N+4 | | N+5 | | N+6 |
                +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+

 Mode requested: Auto    Auto    Auto    Manual  Manual  Manual  Manual
 Exp requested:  N/A     N/A     N/A     None    None    None    5
 Set in Frame:   N+2     N+3     N+4     N+5     N+6     N+7     N+8

 Mode used:      Auto    Auto    Auto    Auto    Auto    Manual  Manual
 Exp used:       0       1       2       3       4       5       5

In practice, this works. However, libcamera has a policy where once a control
is submitted, its value is saved and does not need to be resubmitted. If the
manual exposure value was set while auto mode was on, in theory the value would
be saved, so when manual mode is enabled, the exposure value that was
previously set would immediately be used. Clearly this solution isn't correct,
but it can serve as the basis for a proper solution, with some more rigorous
rules.

Existing solutions
------------------

Raspberry Pi
^^^^^^^^^^^^

The Raspberry Pi IPA gets around the lack of individual AeEnable controls for
exposure and gain by using magic values. When AeEnable is false, if one of the
manual control values was set to 0 then the value computed by AEGC would be
used for just that control. This solution isn't desirable, as it prevents
that magic value from being used as a valid value.

To get around the flickering issue, when AeEnable is false, the Raspberry Pi
AEGC simply stops updating the values to be set, without restoring the
previously set manual exposure time and gain. This works, but is not a proper
solution.

Android
^^^^^^^

The Android HAL specification requires that exposure and gain (sensitivity)
must both be manual or both be auto. It cannot be that one is manual while the
other is auto, so they simply don't support sub controls.

For the flickering issue, the Android HAL has an AeLock control. To transition
from auto to manual, the application would keep AE on auto, and turn on the
lock. Once the lock has propagated through, then the value can be copied from
the result into the request and the lock disabled and the mode set to manual.

The problem with this solution is, besides the extra complexity, that it is
ambiguous what happens if there is a state transition from manual to locked
(even though it's a state transition that doesn't make sense). If locked is
defined to "use the last automatically computed values" then it could use the
values from the last time it AE was set to auto, or it would be undefined if AE
was never auto (eg. it started out as manual), or if AE is implemented to run
in the background it could just use the current values that are computed. If
locked is defined to "use the last value that was set" there would be less
ambiguity. Still, it's better if we can make it impossible to execute this
nonsensical state transition, and if we can reduce the complexity of having
this extra control or extra setting on a lever.

Summary of goals
----------------

- We need a lock of some sort, to instruct the AEGC to not update output
  results

- We need manual modes, to override the values computed by the AEGC

- We need to support seamless transitions from auto to manual, and do so
  without flickering

- We need custom minimum values for the manual controls; that is, no magic
  values for enabling/disabling auto

- All of these need to be done with AE sub-controls (exposure time, analogue
  gain) and be extensible to aperture in the future

Our solution
------------

A diagram of our solution:

::

  +----------------------------+-------------+------------------+-----------------+
  |          INPUT             |  ALGORITHM  |     RESULT       |     OUTPUT      |
  +----------------------------+-------------+------------------+-----------------+

    ExposureTimeMode                                             ExposureTimeMode
  ---------------------+----------------------------------------+----------------->
    0: Auto            |                                        |
    1: Manual          |                                        V
                       |                                       |\
                       |                                       | \
                       |  /----------------------------------> | 1|  ExposureTime
                       |  |    +-------------+  exposure time  |  | -------------->
                       \--)--> |             | --------------> | 0|
    ExposureTime          |    |             |                 | /
  ------------------------+--> |             |                 |/
                               |             |                       AeState
                               |     AEGC    | ----------------------------------->
    AnalogueGain               |             |
  ------------------------+--> |             |                 |\
                          |    |             |                 | \
                       /--)--> |             | --------------> | 0|  AnalogueGain
                       |  |    +-------------+  analogue gain  |  | -------------->
                       |  \----------------------------------> | 1|
                       |                                       | /
                       |                                       |/
                       |                                        ^
    AnalogueGainMode   |                                        | AnalogueGainMode
  ---------------------+----------------------------------------+----------------->
    0: Auto
    1: Manual

  AeEnable
    - True -> ExposureTimeMode:Auto + AnalogueGainMode:Auto
    - False -> ExposureTimeMode:Manual + AnalogueGainMode:Manual


The diagram is divided in four sections horizontally:

- Input: The values received from the request controls

- Algorithm: The algorithm itself

- Result: The values calculated by the algorithm

- Output: The values reported in result metadata and applied to the device

The four input controls are divided between manual values (ExposureTime and
AnalogueGain), and operation modes (ExposureTimeMode and AnalogueGainMode). The
former are the manual values, the latter control how they're applied. The two
modes are independent from each other, and each can take one of two values:

- Auto (0): The AGC computes the value normally. The AGC result is applied
  to the output. The manual value is ignored *and is not retained*.

- Manual (1): The AGC uses the manual value internally. The corresponding
  manual control from the request is applied to the output. The AGC result
  is ignored.

The AeState control reports the state of the unified AEGC block. If both
ExposureTimeMode and AnalogueGainMode are set to manual then it will report
Idle. If at least one of the two is set to auto, then AeState will report
if the AEGC has Converged or not (Searching). This control replaces the old
AeLocked control, as it was insufficient for reporting the AE state.

There is a caveat to manual mode: the manual control value is not retained if
it is set during auto mode. This means that if manual mode is entered without
also setting the manual value, then it will enter a state similar to "locked",
where the last automatically computed value while the mode was auto will be
used. Once the manual value is set, then that will be used and retained as
usual.

This simulates an auto -> locked -> manual or auto -> manual state transition,
and makes it impossible to do the nonsensical manual -> locked state
transition.

AeEnable still exists to allow applications to set the mode of all the
sub-controls at once. Besides being for convenience, this will also be useful
when we eventually implement an aperture control. This is because applications
that will be made before aperture will have been available would still be able
to set aperture mode to auto or manual, as opposed to having the aperture stuck
at auto while the application really wanted manual. Although the aperture would
still be stuck at an uncontrollable value, at least it would be at a static
usable value as opposed to varying via the AEGC algorithm.

With this solution, the earlier example would become:

::

                 +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
                 | N+2 | | N+3 | | N+4 | | N+5 | | N+6 | | N+7 | | N+8 | | N+9 | | N+10|
                 +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
 Mode requested:  Auto    Manual  Manual  Manual  Manual  Manual  Manual  Manual  Manual
 Exp requested:   N/A     None    None    None    None    10      None    10      10
 Set in Frame:    N+4     N+5     N+6     N+7     N+8     N+9     N+10    N+11    N+12

 Mode used:       Auto    Auto    Auto    Manual  Manual  Manual  Manual  Manual  Manual
 Exp used:        2       3       4       5       5       5       5       10      10

This example is extended by a few frames to exhibit the simulated "locked"
state. At frame N+5 the application has confirmed that the manual mode has been
entered, but does not provide a manual value until request N+7. Thus, the value
that is used in requests N+5 and N+6 (where the mode is disabled), comes from
the last value that was used when the mode was auto, which comes from frame
N+4.

Then, in N+7, a manual value of 10 is supplied. It takes until frame N+9 for
the exposure to be applied. N+8 does not supply a manual value, but the last
supplied value is retained, so a manual value of 10 is still used and set in
frame N+10.

Although this behavior is the same as what we had with waiting for the manual
mode to propagate (in the section "Description of the problem"), this time it
is correct as we have defined specifically that if a manual value was specified
while the mode was auto, it will not be retained.

Description of the controls
---------------------------

As described above, libcamera offers the following controls related to exposure
and gain:

- AnalogueGain

- AnalogueGainMode

- ExposureTime

- ExposureTimeMode

- AeState

- AeEnable

Auto-exposure and auto-gain can be enabled and disabled separately using the
ExposureTimeMode and AnalogueGainMode controls respectively. The AeEnable
control can also be used, as it sets both of the modes simultaneously. The
AeEnable control is not returned in metadata.

When the respective mode is set to auto, the respective value that is computed
by the AEGC algorithm is applied to the image sensor. Any value that is
supplied in the manual ExposureTime/AnalogueGain control is ignored and not
retained. Another way to understand this is that when the mode transitions from
auto to manual, the internally stored control value is overwritten with the
last value computed by the auto algorithm.

This means that when we transition from auto to manual without supplying a
manual control value, the last value that was set by the AEGC algorithm will
keep be used. This can be used to do a flickerless transition from auto to
manual as described earlier. If the camera started out in manual mode and no
corresponding value has been supplied yet, then a best-effort default value
shall be set.

The manual control value can be set in the same request as setting the mode to
auto if the desired manual control value is already known.

Transitioning from manual to auto shall be implicitly flickerless, as the AEGC
algorithms are expected to start running from the last manual value.

The AeState metadata reports the state of the AE algorithm. As AE cannot
compute exposure and gain separately, the state of the AE component is
unified. There are three states: Idle, Searching, and Converged.

The state shall be Idle if both ExposureTimeMode and AnalogueGainMode
are set to Manual. If the camera only supports one of the two controls,
then the state shall be Idle if that one control is set to Manual. If
the camera does not support Manual for at least one of the two controls,
then the state will never be Idle, as AE will always be running.

The state shall be Searching if at least one of exposure or gain calculated
by the AE algorithm is used (that is, at least one of the two modes is Auto),
*and* the value(s) have not converged yet.

The state shall be Converged if at least one of exposure or gain calculated
by the AE algorithm is used (that is, at least one of the two modes is Auto),
*and* the value(s) have converged.