summaryrefslogtreecommitdiff
path: root/src
AgeCommit message (Collapse)Author
2022-10-10pipeline: rkisp1: Set bytesused before queuing parameters bufferLaurent Pinchart
The bytesused value for the parameters buffer is initialized to 0 and never set. The V4L2 API specification indicates that, for an output video device, the driver will set the bytesused value to the size of the plane in that case. The videobuf2 framework does so, but considers this as deprecated and prints a warning: [ 54.375534] use of bytesused == 0 is deprecated and will be removed in the future, [ 54.388026] use the actual size instead. Fix it by setting bytesused to the correct value before queuing the parameters buffer. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Tested-by: Naushir Patuck <naush@raspberrypi.com>
2022-10-10pipeline: ipu3: Set bytesused before queuing parameters bufferLaurent Pinchart
The bytesused value for the parameters buffer is initialized to 0 and never set. The V4L2 API specification indicates that, for an output video device, the driver will set the bytesused value to the size of the plane in that case. The videobuf2 framework does so, but considers this as deprecated and prints a warning: [ 54.375534] use of bytesused == 0 is deprecated and will be removed in the future, [ 54.388026] use the actual size instead. Fix it by setting bytesused to the correct value before queuing the parameters buffer. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Tested-by: Naushir Patuck <naush@raspberrypi.com>
2022-10-10libcamera: framebuffer: Move remaining private data to Private classLaurent Pinchart
Private members of the FrameBuffer class are split between FrameBuffer and FrameBuffer::Private. There was no real justification for this split, and keeping some members private in the FrameBuffer class causes multiple issues: - Future modifications of the FrameBuffer class without breaking the ABI may be more difficult. - Mutable access to members that should not be modified by applications require a friend statement, or going through the Private class. Move all remaining private members to the Private class to address the first issue, and add a Private::metadata() function to address the second problem. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Tested-by: Naushir Patuck <naush@raspberrypi.com>
2022-10-10libcamera: base: utils: Drop defoptLaurent Pinchart
utils::defopt causes compilation issues on gcc 8.0.0 to gcc 8.3.0, likely due to bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86521 that was fixed in gcc 8.4.0. gcc 8.3.0 may be considered old (libcamera requires gcc-8 or newer), but it is shipped by Debian 10 that has LTS support until mid-2024. As no workaround has been found to fix compilation on gcc 8.3.0 while still retaining the functionality of utils::defopt, remove it from the libcamera base library. This change could be reverted once support for gcc-8 will be dropped. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2022-10-10ipa: rkisp1: Drop use of utils::defoptLaurent Pinchart
utils::defopt causes compilation issues on gcc 8.0.0 to gcc 8.3.0, likely due to bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86521 that was fixed in gcc 8.4.0. gcc 8.3.0 may be considered old (libcamera requires gcc-8 or newer), but it is shipped by Debian 10 that has LTS support until mid-2024. As no workaround has been found to fix compilation on gcc 8.3.0 while still retaining the functionality of utils::defopt, stop using it in the RkISP1 IPA module. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2022-10-07ipa: raspberrypi: Remove unneeded Span castsLaurent Pinchart
Commit 09c1b081baa2 ("libcamera: controls: Generate and use fixed-sized Span types") added explicit Span casts for fixed extent spans that were required due to the ControlList::set() function that takes an std::initializer_list not being able to infer a control size from template arguments. This has now been fixed, so the casts are not needed anymore. Drop them. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Christian Rauch <Rauch.Christian@gmx.de> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
2022-10-07libcamera: controls: Construct Span with size for array controlsLaurent Pinchart
The ControlList::set() function overload used for array controls constructs a Span from an initializer list. It doesn't specify the Span size explicitly, which results in a dynamic extent Span being constructed. That causes a compilation failure for fixed-size array controls, as they are defined as Control<T> with T being a fixed-extent Span, and conversion from a dynamic-extent to fixed-extent Span when calling ControlValue::set() can't be implicit. Fix this by constructing the Span using the size of the control, which resolves to a fixed-extent and dynamic-extent Span for fixed-size and dynamic-size array controls respectively. The ControlList::set() function that takes an initializer list can then be used for fixed-size array controls. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
2022-10-07utils: gen-controls: Improve YAML notation for variable-size array controlsLaurent Pinchart
Array controls specify the array size through the YAML 'size' element, which stores a list of values, one per dimension. Variable-size arrays currently use an empty 'size' list, which prevents describing the number of dimensions of the array. Improve this by using the same notation for fixed-size and variable-size array controls. Dimensions that are not fixed are described as a string instead of an integer, such as [n], [n,3] or [w,h]. The strings have currently no special meaning, this may change in the future. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
2022-10-07libcamera: pipeline_handler: Implement factories through class templatesLaurent Pinchart
The REGISTER_PIPELINE_HANDLER() macro defines a class type that inherits from the PipelineHandlerFactory class, and implements a constructor and a createInstance() function. Replace the code generation through macro with the C++ equivalent, a class template, as done in libipa with the Algorithm and CameraSensorHelper factories. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Xavier Roumegue <xavier.roumegue@oss.nxp.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2022-10-07libcamera: pipeline_handler: Return unique_ptr from createInstanceLaurent Pinchart
Avoid naked pointer with memory allocation by returning a unique_ptr from PipelineHandlerFactory::createInstance(), in order to increase memory allocation safety. This allows iterating over factories in the CameraManager and unit tests using const pointers. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Xavier Roumegue <xavier.roumegue@oss.nxp.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2022-10-07libcamera: pipeline_handler: Make factory create() function constLaurent Pinchart
The PipelineHandlerFactory::create() function has no need to modify the factory instance. Make it const, as well as the createInstance() function. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Xavier Roumegue <xavier.roumegue@oss.nxp.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2022-10-07ipa: camera_sensor_helper: Implement factories through class templatesLaurent Pinchart
The REGISTER_CAMERA_SENSOR_HELPER() macro defines a class type that inherits from the CameraSensorHelperFactory class, and implements a constructor and createInstance() function. Replace the code generation through macro with the C++ equivalent, a class template, as done by the Algorithm factory. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Xavier Roumegue <xavier.roumegue@oss.nxp.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2022-10-07ipa: camera_sensor_helper: Return unique_ptr from createInstanceLaurent Pinchart
Avoid naked pointer with memory allocation by returning a unique_ptr from CameraSensorHelperFactory::createInstance(), in order to increase memory allocation safety. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Xavier Roumegue <xavier.roumegue@oss.nxp.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2022-10-07ipa: camera_sensor_helper: Make registerType() and createInstance() privateLaurent Pinchart
The CameraSensorHelperFactory registerType() and createInstance() functions are called by the CameraSensorHelperFactory class only. Make them private. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Xavier Roumegue <xavier.roumegue@oss.nxp.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2022-10-07ipa: camera_sensor_helper: Make factory createInstance() function constLaurent Pinchart
The CameraSensorHelperFactory::createInstance() function has no need to modify the factory instance. Make it const. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Xavier Roumegue <xavier.roumegue@oss.nxp.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2022-10-07ipa: ipu3: Fix minor Doxygen issues in IPAFrameContextLaurent Pinchart
The IPAFrameContext documentation has a spurious Doxygen \struct statement that is not needed, and uses a \struct instead of a \var in another location. Fix both issues. This doesn't cause any change in the generated documentation. Note that the Doxygen output for IPAFrameContext is incorrect, documentation is missing for all members. This is caused by using "." instead of "::" in our documentation, which we currently do because the correct syntax produces Doxygen warnings (and still incorrect output). See https://github.com/doxygen/doxygen/issues/9343. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2022-10-05test: threads: Fix link failure due to missing dependencyLaurent Pinchart
Commit 036d26d6677e ("test: threads: Test thread cleanup upon abnormal termination") added calls to functions provided by the pthread library in the threads test, but didn't add the corresponding dependency. This caused a link breakage on some platforms: /usr/bin/ld: test/threads.p/threads.cpp.o: undefined reference to symbol 'pthread_cancel@@GLIBC_2.4' /usr/bin/ld: /lib/arm-linux-gnueabihf/libpthread.so.0: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status Fix it by adding the missing dependency. Fixes: 036d26d6677e ("test: threads: Test thread cleanup upon abnormal termination") Reported-by: Naushir Patuck <naush@raspberrypi.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Naushir Patuck <naush@raspberrypi.com> Tested-by: Naushir Patuck <naush@raspberrypi.com> Acked-by: Jacopo Mondi <jacopo@jmondi.org>
2022-10-05ipa: raspberrypi: Fix the imx296 mono tuning black levelNaushir Patuck
The sensor black level is 60 (in 10-bits), fix this in the mono variant tuning file. Signed-off-by: Naushir Patuck <naush@raspberrypi.com> Reviewed-by: David Plowman <david.plowman@raspberrypi.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2022-10-05ipa: raspberrypi: Add a tuning file for the colour variant of IMX296Naushir Patuck
Add the tuning file (imx296.json) for the colour variant of the IMX296 sensor. Signed-off-by: Naushir Patuck <naush@raspberrypi.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: David Plowman <david.plowman@raspberrypi.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2022-10-05pipeline: raspberrypi: Update naming convention for tuning filesNaushir Patuck
Append "_mono" to the sensor name when generating the tuning filename for monochrome sensor variants. So the new naming convention is as follows: <sensor_name>.json - Standard colour sensor variant <sensor_name>_mono.json - Monochrome sensor variant Rename the existing imx296.json file to imx296_mono.json as this tuning file is based on the monochrome variant of the IMX296. Signed-off-by: Naushir Patuck <naush@raspberrypi.com> Reviewed-by: David Plowman <david.plowman@raspberrypi.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2022-10-05libcamera: bayer_format: Add unpacked mono 12-bit format to the conversion tableNaushir Patuck
Add BayerFormat conversions for formats::R12 (12-bit unpacked) format. Signed-off-by: Naushir Patuck <naush@raspberrypi.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: David Plowman <david.plowman@raspberrypi.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2022-10-04pipeline: raspberrypi: Detect monochrome "R" formats as being rawDavid Plowman
The "R" pixel formats (R8, R10, R10_CSI2P etc.) record the associated colour space as being YUV rather than RAW, meaning that the code was not detecting them as being raw formats. In the case of Raspberry Pi, we deal only with raw formats, so the revised test must work correctly for both these and the standard Bayer formats. Signed-off-by: David Plowman <david.plowman@raspberrypi.com> Reviewed-by: Naushir Patuck <naush@raspberrypi.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2022-10-04ipa: raspberrypi: Limit minimum exposure time for the IMX296Naushir Patuck
Limit the minimum allowable exposure time to a single line in the IMX296 camera helper. This equates to approximately 30us. Signed-off-by: Naushir Patuck <naush@raspberrypi.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: David Plowman <david.plowman@raspberrypi.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2022-10-04ipa: raspberrypi: Fix sensor delays for the IMX296Naushir Patuck
The IMX296 implements a 2 frame delay for exposure, gain and vertical blanking changes. Report this in the camera helper. Signed-off-by: Naushir Patuck <naush@raspberrypi.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: David Plowman <david.plowman@raspberrypi.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2022-10-04libcamera: v4l2_device: List controls when setting file descriptorLaurent Pinchart
The base V4L2Device class is bound to a video device node by either open(), which opens the device node and creates a new file descriptor, or setFd(), which takes an already open file descriptor. The former populates the V4L2Device instance controls, while the latter doesn't. This prevents using controls on V4L2 M2M devices. Fix it by populating controls in setFd(), which is called by open(). Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Xavier Roumegue <xavier.roumegue@oss.nxp.com>
2022-10-04qcam: Fix YUV planar fragment shadersLaurent Pinchart
Commit 251f0534b74b ("qcam: viewfinder_gl: Take color space into account for YUV rendering") introduced compilation failures in the YUV semi-planar and planar fragment shaders due to a bad copy & paste. Fix it. Fixes: 251f0534b74b ("qcam: viewfinder_gl: Take color space into account for YUV rendering") Reported-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
2022-10-03ipa: ipu3: Correct context during configure()Kieran Bingham
The introduction of the FCQueue in the IPU3 inadvertently introduced a bug which cleared the initialisation of the session configuration immediately after some parameters had been set. Furthermore, it cleared and never re-initialised the sensor line duration property, which was previously only set during the call to init(). Move the clearing of the contexts from the updateSessionConfiguration() call to the earliest opportunity in configure(), and immediately re-initialise the sensor parameters. Bug: https://bugs.libcamera.org/show_bug.cgi?id=151 Fixes: 85c5c47325ab ("ipa: ipu3: Use the FCQueue") Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2022-10-01ipa: rkisp1: Remove initialized_ flags from algorithmsLaurent Pinchart
Multiple algorithms have an initialized_ flag that they set to true at the end of the init() function, and check at the beginning of prepare() to skip preparation. This serves no real purpose, as the flag can only be false if init() fails, in which case the IPA module initialization as a whole will fail. Drop the initialized_ flags. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2022-09-30py: Support controls that are ControlTypeNoneDavid Plowman
Such controls can now be created when a control doesn't have a reasonable or obvious default value. We support them using Python's "None" value, rather than generating a runtime error. Signed-off-by: David Plowman <david.plowman@raspberrypi.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Christian Rauch <Rauch.Christian@gmx.de> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2022-09-30cam: kms_sink: Add color space supportLaurent Pinchart
KMS defines YCbCr encoding and quantization properties for planes. When supported by the device, set them to match the color space of the stream to render colors accurately. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Eric Curtin <ecurtin@redhat.com>
2022-09-30libcamera: Add missing SPDX headers for miscellaneous CC0-1.0 contentsLaurent Pinchart
Miscellaneous files that are not considered copyrightable are missing an SPDX-License-Identifier header. Fix this by adding a header listing the CC0-1.0 license. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2022-09-30Documentation: Add missing SPDX headersLaurent Pinchart
Two documentation files are missing SPDX headers. Add them, with the CC-BY-SA-4.0 license that covers all the libcamera documentation. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2022-09-29libcamera: v4l2_device: Log control id instead of errorIdxUmang Jain
v4l2_ext_controls.errorIdx (in the case of single failing control for VIDIOC_*_EXT_CTRLS calls) represents the index of that control. Since it is a single control, we can print the control id rather than its index. This improves logging as the id can be easily co-related with the controls while reading the log. Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2022-09-28cam: drm: Skip DRM devices not capable of mode settingLaurent Pinchart
The DRM helper picks the first DRM card that it can open. On platforms that have a standalone GPU, this risks selecting a device corresponding to the GPU instead of the display controller. Fix this by skipping devices that don't support the KMS mode setting API. Some legacy display controllers would be skipped as well, but libcamera doesn't run on those systems anyway. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Eric Curtin <ecurtin@redhat.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2022-09-28ipa: rkisp1: awb: Remove bias from gain calculationLaurent Pinchart
The red and blue gains are computed by dividing the green mean by the red and blue means respectively. An offset of 1 is added to the dividers to avoid divisions by zero. This introduces a bias in the gain values. Fix it by clamping the divisors to a minimum of 1.0 instead of adding an offset. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2022-09-28ipa: rkisp1: awb: Freeze AWB when means are too smallLaurent Pinchart
When the RGB means are too small, gains and color temperature can't be meaningfully calculated. Freeze the AWB in that case, using the previously calculated values. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2022-09-28ipa: rkisp1: awb: Clamp gains to prevent divisions by zeroLaurent Pinchart
The gain values are currently clamped to the range [0.0, 3.996] used by the hardware. A zero value makes little sense, as it would completely remove the contribution of the corresponding color channel from the AWB accumulators, but worse, would lead to divisions by zero when calculating the raw means in subsequent iterations. Prevent this by setting the minimum gain value to 1/256. While at it, clamp the gain values before filtering them, to improve the stability of the control loop. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2022-09-28ipa: rkisp1: awb: Prevent RGB means from being negativeLaurent Pinchart
Due to hardware rounding errors in the YCbCr means, the calculated RGB means may be negative. This would lead to negative gains, messing up calculation. Prevent this by clamping the means to positive values. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2022-09-28ipa: rkisp1: awb: Log means, gains and temperature in debug messageLaurent Pinchart
Extend the debug message in Awb::process() to log the means and color temperature in addition to the gains. This is useful for debugging the algorithm behaviour. While at it, set the showpoint flag to print a fixed number of digits after the decimal point, making logs more readable. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2022-09-28ipa: rkisp1: awb: Add support for RGB meansQuentin Schulz
RkISP actually supports two modes for color means, RGB and YCbCr. The variables where the means are stored are identically named regardless of the color means mode that's been selected. Since the gains are computed in RGB mode, a conversion needs to be done when the mode is YCbCr, which is unnecessary when RGB mode is selected. This adds support for RGB means mode too, by checking at runtime which mode is selected at a given time. The default is still set to YCbCr mode for now. Cc: Quentin Schulz <foss+libcamera@0leil.net> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2022-09-28ipa: rkisp1: awb: Store color temperature as an integerLaurent Pinchart
The color temperature doesn't need floating point precision, and is calculated by Awb::estimateCCT() as an unsigned integer. Store it with the same data type in the frame context. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2022-09-28ipa: rkisp1: awb: Use frame context to fix gains calculationsLaurent Pinchart
The AWB statistics are computed after the ISP applies the colour gains. This means that the red, green and blue means do not match the data coming directly from the sensor, but are multiplied by the colour gains that were used for the frame on which the statistics have been computed. The AWB algorithm needs to take this into account when calculating the colour gains for the next frame. Do so by dividing the means by the gains that were applied to the frame, retrieved from the frame context. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2022-09-28ipa: rkisp1: Document the active state and frame contextLaurent Pinchart
Now that data used by algorithms has been partitioned between the active state and frame context, we have a better view of the role of each of those structures. Document them appropriately. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2022-09-28ipa: rkisp1: filter: Store per-frame information in frame contextLaurent Pinchart
Rework the algorithm's usage of the active state, to store the value of controls for the last queued request in the queueRequest() function, and store a copy of the values in the corresponding frame context. The latter is used in the prepare() function to populate the ISP parameters with values corresponding to the right frame. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2022-09-28ipa: rkisp1: dpf: Store per-frame information in frame contextLaurent Pinchart
Rework the algorithm's usage of the active state, to store the value of controls for the last queued request in the queueRequest() function, and store a copy of the values in the corresponding frame context. The latter is used in the prepare() function to populate the ISP parameters with values corresponding to the right frame. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2022-09-28ipa: rkisp1: cproc: Store per-frame information in frame contextLaurent Pinchart
Rework the algorithm's usage of the active state, to store the value of controls for the last queued request in the queueRequest() function, and store a copy of the values in the corresponding frame context. The latter is used in the prepare() function to populate the ISP parameters with values corresponding to the right frame. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2022-09-28ipa: rkisp1: awb: Store per-frame information in frame contextLaurent Pinchart
Rework the algorithm's usage of the active state and frame context to store data in the right place. The active state stores two distinct categories of information: - The consolidated value of all algorithm controls. Requests passed to the queueRequest() function store values for controls that the application wants to modify for that particular frame, and the queueRequest() function updates the active state with those values. The active state thus contains a consolidated view of the value of all controls handled by the algorithm. - The value of parameters computed by the algorithm when running in auto mode. Algorithms running in auto mode compute new parameters every time statistics buffers are received (either synchronously, or possibly in a background thread). The latest computed value of those parameters is stored in the active state in the process() function. The frame context also stores two categories of information: - The value of the controls to be applied to the frame. These values are typically set in the queueRequest() function, from the consolidated control values stored in the active state. The frame context thus stores values for all controls related to the algorithm, not limited to the controls specified in the corresponding request, but consolidated from all requests that have been queued so far. For controls that can be specified manually or computed by the algorithm depending on the operation mode (such as the colour gains), the control value will be stored in the frame context in queueRequest() only when operating in manual mode. When operating in auto mode, the values are computed by the algorithm and stored in the frame context in prepare(), just before being stored in the ISP parameters buffer. The queueRequest() function can also store ancillary data in the frame context, such as flags to indicate if (and what) control values have changed compared to the previous request. - Status information computed by the algorithm for a frame. For instance, the colour temperature estimated by the algorithm from ISP statistics calculated on a frame is stored in the frame context for that frame in the process() function. The active state and frame context thus both contain identical members for most control values, but store values that have a different meaning. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2022-09-28ipa: rkisp1: agc: Store per-frame information in frame contextLaurent Pinchart
Rework the algorithm's usage of the active state to store the value of controls for the last queued request in the queueRequest() function, and store a copy of the values in the corresponding frame context. The frame context is used in the prepare() function to populate the ISP parameters with values corresponding to the right frame. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2022-09-28ipa: rkisp1: Use frame number passed to Algorithm::prepare()Laurent Pinchart
Now that the Algorithm::prepare() function takes a frame number, we can use it to replace the IPAActiveState::frameCount member. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2022-09-28ipa: rkisp1: Convert to use the FCQueueKieran Bingham
Establish a queue of FrameContexts using the new FCQueue and use it to supply the FrameContext to the algorithms. The algorithms on the RKISP1 do not use this yet themselves, but are able to do so after the introduction of this patch. Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>