[BUG] AeLocked is reported when AeEnabled: False

[fredsonnenwald]

Description
When specifying picam2.set_controls({"AeEnable": False}) to disable auto exposure, the request metadata dict contains an AeLocked key. This suggests that auto exposure is still running, despite it being specifically disabled.

To Reproduce
Capture a still with auto exposure disabled:

#!/usr/bin/env python3
import atexit
from pprint import pprint
from picamera2 import Picamera2

picam2 = Picamera2(0)
atexit.register(lambda: picam2.close())
config = picam2.create_still_configuration(
    raw={"size": (1024, 768), "format": "SGBRG10"}, buffer_count=2
)

picam2.configure(config)
picam2.set_controls(
    {
        "AeEnable": False,
        "AnalogueGain": 1,
        "AwbEnable": False,
        "Brightness": 0.0,
        "Contrast": 1.0,
        "ExposureTime": 100000,
        "ExposureValue": 0.0,
        "Saturation": 1.0,
        "Sharpness": 1.0,
    }
)

picam2.start()

job = picam2.capture_request(wait=False)
request = picam2.wait(job)
metadata = request.get_metadata()
pprint(metadata)

# If no Ae is used this information should not be present
assert not "AeLocked" in metadata

picam2.close()

Expected behaviour
The assertion in the example code passes and the AeLocked is not present in request metadata.

Console Output, Screenshots

pi@raspberrypi:~/scarletoak $ python minimum_aelocked_example.py 
[2:41:11.519013607] [2770]  INFO Camera camera_manager.cpp:325 libcamera v0.3.2+27-7330f29b
[2:41:11.529145151] [2776]  INFO RPI pisp.cpp:695 libpisp version v1.0.7 28196ed6edcf 29-08-2024 (16:33:32)
[2:41:11.538395155] [2776]  INFO RPI pisp.cpp:1154 Registered camera /base/axi/pcie@120000/rp1/i2c@88000/ov5647@36 to CFE device /dev/media3 and ISP device /dev/media0 using PiSP variant BCM2712_C0
[2:41:11.538458618] [2776]  INFO RPI pisp.cpp:695 libpisp version v1.0.7 28196ed6edcf 29-08-2024 (16:33:32)
[2:41:11.547237528] [2776]  INFO RPI pisp.cpp:1154 Registered camera /base/axi/pcie@120000/rp1/i2c@80000/ov5647@36 to CFE device /dev/media4 and ISP device /dev/media1 using PiSP variant BCM2712_C0
[2:41:11.550085758] [2770]  INFO Camera camera.cpp:1197 configuring streams: (0) 2592x1944-BGR888 (1) 1296x972-SGBRG16
[2:41:11.550195184] [2776]  INFO RPI pisp.cpp:1450 Sensor: /base/axi/pcie@120000/rp1/i2c@88000/ov5647@36 - Selected sensor format: 1296x972-SGBRG10_1X10 - Selected CFE format: 1296x972-GB16
{'AeLocked': False,
 'AnalogueGain': 1.0,
 'ColourCorrectionMatrix': (1.9878311157226562,
                            -0.4670906066894531,
                            -0.5207441449165344,
                            -0.5464682579040527,
                            2.0031790733337402,
                            -0.4567108452320099,
                            -0.11487051099538803,
                            -0.7333822250366211,
                            1.8482463359832764),
 'ColourGains': (1.1785097122192383, 1.452620267868042),
 'ColourTemperature': 4000,
 'DigitalGain': 1.0000731945037842,
 'ExposureTime': 99992,
 'FocusFoM': 11,
 'FrameDuration': 100085,
 'Lux': 78.37276458740234,
 'ScalerCrop': (0, 0, 2592, 1944),
 'ScalerCrops': [(0, 0, 2592, 1944)],
 'SensorBlackLevels': (1024, 1024, 1024, 1024),
 'SensorTimestamp': 9671778998000}
Traceback (most recent call last):
  File "/home/pi/scarletoak/minimum_aelocked_example.py", line 35, in <module>
    assert not "AeLocked" in metadata
               ^^^^^^^^^^^^^^^^^^^^^^
AssertionError

Hardware :
A Raspberry Pi 5 with a Raspberry Pi Camera v1.3 and the latest packages as of last month.

pi@raspberrypi:~/scarletoak $ libcamera-hello --list-cameras
Available cameras
-----------------
0 : ov5647 [2592x1944 10-bit GBRG] (/base/axi/pcie@120000/rp1/i2c@88000/ov5647@36)
    Modes: 'SGBRG10_CSI2P' : 640x480 [58.92 fps - (16, 0)/2560x1920 crop]
                             1296x972 [43.25 fps - (0, 0)/2592x1944 crop]
                             1920x1080 [30.62 fps - (348, 434)/1928x1080 crop]
                             2592x1944 [15.63 fps - (0, 0)/2592x1944 crop]

1 : ov5647 [2592x1944 10-bit GBRG] (/base/axi/pcie@120000/rp1/i2c@80000/ov5647@36)
    Modes: 'SGBRG10_CSI2P' : 640x480 [58.92 fps - (16, 0)/2560x1920 crop]
                             1296x972 [43.25 fps - (0, 0)/2592x1944 crop]
                             1920x1080 [30.62 fps - (348, 434)/1928x1080 crop]
                             2592x1944 [15.63 fps - (0, 0)/2592x1944 crop]
pi@raspberrypi:~/scarletoak $ dpkg -l | grep camera
ii  libcamera-ipa:arm64                  0.3.2+rpt20240927-1              arm64        complex camera support library (IPA modules)
ii  libcamera0.3:arm64                   0.3.2+rpt20240927-1              arm64        complex camera support library
ii  libdc1394-25:arm64                   2.2.6-4                          arm64        high level programming interface for IEEE 1394 digital cameras
ii  libgphoto2-6:arm64                   2.5.30-1                         arm64        gphoto2 digital camera library
ii  libgphoto2-l10n                      2.5.30-1                         all          gphoto2 digital camera library - localized messages
ii  libgphoto2-port12:arm64              2.5.30-1                         arm64        gphoto2 digital camera port library
ii  python3-libcamera:arm64              0.3.2+rpt20240927-1              arm64        complex camera support library (Python bindings)
ii  python3-picamera2                    0.3.22-2                         all          Libcamera based python library

Additional context
I am working on capturing raw images so I wanted to be sure what I was receiving was actually raw. I think it is, but the presence of AeLocked is very misleading.

[davidplowman]

Hi, and thanks for the comments. I'm sorry that it's a bit misleading, but actually, when AE/AGC is off, quite a lot of it still runs to convert things like the exposure time you set into the internal units (lines) the camera wants. So it's never really "off", for what it's worth, though it does ensure to give you any "manual" values that have been set.

Actually AeLocked needs some work in general (it doesn't work as well as it should), at which point we can consider what it should report in the manual case (if anything).

But in any case, always check the exposure/gain values in the metadata from the request that you capture - these values should be correct.

[fredsonnenwald]

Thank you for the explanation! The exposure/gain values have been matching what I set manually, but it's great having a confirmation that it is working as expected.