summaryrefslogtreecommitdiff
path: root/src/ipa
AgeCommit message (Collapse)Author
2024-12-03ipa: rpi: Rename Matrix to Matrix3x3Stefan Klug
The upcoming patches will introduce a Matrix class into libcamera/internal. That name clashes with the Matrix class from the RaspberryPi ccm implementation. Rename the rpi version to Matrix3x3 to prevent the name clash. Matrix3x3 will be replaced by the generic implementation later. Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2024-12-03libcamera: software_isp: Actually apply black level from tuning dataMilan Zamazal
The black level obtained from the tuning file in software ISP is retrieved in init (because this is the standard algorithm method with access to tuning data) and stored into context. But the context gets reset in configure and the black level is lost and never applied. Let's store the black level from the tuning file into an algorithm instance variable and put it into the context only later in configure. This is similar to what rkisp1 IPA does with the values obtained from the tuning file. Fixes: 41e3d61c745153779ed5a38634d7266bffd60d61 ("libcamera: software_isp: Clear IPA context on configure and stop") Signed-off-by: Milan Zamazal <mzamazal@redhat.com> Tested-by: Robert Mader <robert.mader@collabora.com> Reviewed-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-11-29libcamera: software_isp: Remove unused IPAActiveState fieldsStanislaw Gruszka
Now agc struct in IPAActiveState is not used any longer. If there will be need to have this struct, this patch can be reverted. Signed-off-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com> Reviewed-by: Milan Zamazal <mzamazal@redhat.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-11-29libcamera: software_isp: Initialize exposure+gain before agc calculationsStanislaw Gruszka
On my setup, since commit fb8ad13d ("libcamera: software_isp: Move exposure+gain to an algorithm module"), at start camera output stays very dark for dozen of seconds, and then later slowly gets to normal. This is because existing sensor exposure+gain settings are not used at start. We save initial values in frameContext but in the agc algorithm we use IPA context. Fix the problem by using in frameContext sensor values, since we already use those in blc algorithm and change exposure type to int32_t to unnecessary castings. Signed-off-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com> Reviewed-by: Milan Zamazal <mzamazal@redhat.com> Tested-by: Robert Mader <robert.mader@collabora.com> Tested-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-11-29libcamera: libipa: camera_sensor: Add GalaxyCore gc08a3 sensor propertiesHarvey Yang
Provide the GalaxyCore gc08a3 camera sensor properties and registration with libipa for the gain code helpers. Signed-off-by: Han-Lin Chen <hanlinchen@chromium.org> Co-developed-by: Xing Gu <xinggu@chromium.org> Signed-off-by: Xing Gu <xinggu@chromium.org> Co-developed-by: Yudhistira Erlandinata <yerlandinata@chromium.org> Signed-off-by: Yudhistira Erlandinata <yerlandinata@chromium.org> Co-developed-by: Harvey Yang <chenghaoyang@chromium.org> Signed-off-by: Harvey Yang <chenghaoyang@chromium.org> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-11-29libcamera: libipa: camera_sensor: Add GalaxyCore gc05a2 sensor propertiesHarvey Yang
Provide the GalaxyCore gc05a2 camera sensor properties and registration with libipa for the gain code helpers. Signed-off-by: Han-Lin Chen <hanlinchen@chromium.org> Co-developed-by: Xing Gu <xinggu@chromium.org> Signed-off-by: Xing Gu <xinggu@chromium.org> Co-developed-by: Yudhistira Erlandinata <yerlandinata@chromium.org> Signed-off-by: Yudhistira Erlandinata <yerlandinata@chromium.org> Co-developed-by: Harvey Yang <chenghaoyang@chromium.org> Signed-off-by: Harvey Yang <chenghaoyang@chromium.org> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-11-26ipa: rkisp1: awb: Expand commentLaurent Pinchart
The RGB to YCbCr conversion matrix mentioned in a comment, coming from the hardware documentation, does not match any of the canonical matrices specified by any standard. While researching where the values came from, it became apparent they are likely Bt.601 limited range coefficients rounded to 6 bits of decimal precision. Record this in comments. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Milan Zamazal <mzamazal@redhat.com>
2024-11-26ipa: rkisp1: awb: Use Vector and Matrix for linear algebraLaurent Pinchart
Replace the manual vector and matrix calculations with usage of the Vector and Matrix classes. This simplifies the code and improves readability. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Milan Zamazal <mzamazal@redhat.com>
2024-11-26ipa: rkisp1: awb: Use RGB class to store colour gainsLaurent Pinchart
Replace the manual storage of gains in the IPA active state and frame context with usage of the RGB class. This simplifies the code thanks to usage of the arithmetic functions provided by the RGB class. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Milan Zamazal <mzamazal@redhat.com>
2024-11-26ipa: libipa: colour: Use Vector and Matrix for linear algebraLaurent Pinchart
Replace the manual vector and matrix calculations with usage of the Vector and Matrix classes. This simplifies the code and improves readability. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Milan Zamazal <mzamazal@redhat.com>
2024-11-26ipa: libipa: colour: Use the RGB class to model RGB valuesLaurent Pinchart
The rec601LuminanceFromRGB() and estimateCCT() functions take RGB triplets as three variables. Replace them with instances of the RGB class and adapt the users accordingly. Only variables passed directly to these functions are converted to RGB instances, further conversion of IPA modules to the RGB class will be performed separately. While at it, fix a typo in the documentation of the estimateCCT() function. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Milan Zamazal <mzamazal@redhat.com>
2024-11-26ipa: ipu3: awb: Replace Awb::RGB class with ipa::RGBLaurent Pinchart
Now that libipa has a generic RGB class, replaces the local implementation from the IPU3 AWB algorithm. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Milan Zamazal <mzamazal@redhat.com>
2024-11-26ipa: libipa: vector: Add sum() functionLaurent Pinchart
Add a function to calculate the sum of a vector. It will be useful for algorithms. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Milan Zamazal <mzamazal@redhat.com>
2024-11-26ipa: libipa: vector: Add element-wise min() and max() functionsLaurent Pinchart
Add functions to calculate the element-wise minimum and maximum of two vectors or of a vector and a scalar. This will be used in algorithm implementations. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Milan Zamazal <mzamazal@redhat.com>
2024-11-26ipa: libipa: vector: Add compound assignment operatorsLaurent Pinchart
Extend the Vector class with compound assignment operators that match the binary arithmetic operators. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Milan Zamazal <mzamazal@redhat.com>
2024-11-26ipa: libipa: vector: Add missing binary arithemtic operatorsLaurent Pinchart
The Vector class defines multiple element-wise arithmetic operators between vectors or between a vector and a scalar. A few variants are missing. Add them. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Milan Zamazal <mzamazal@redhat.com>
2024-11-26ipa: libipa: vector: Generalize arithmetic operatorsLaurent Pinchart
Instead of hand-coding all arithmetic operators, implement them based on a generic apply() function that takes an operator-specific binary operators. This will simplify adding missing arithmetic operators. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Milan Zamazal <mzamazal@redhat.com>
2024-11-26ipa: libipa: vector: Rename the dot product operator*() to dot()Laurent Pinchart
The Vector class defines a set of arithmetic operators between two vectors or a vector and a scalar. All the operators perform element-wise operations, except for the operator*() that computes the dot product. This is inconsistent and confusing. Replace the operator with a dot() function. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Milan Zamazal <mzamazal@redhat.com>
2024-11-26ipa: libipa: vector: Add scalar constructorLaurent Pinchart
The default constructor leaves the vector data uninitialized. Add a constructor to fill the vector with copies of a scalar value, and fix the documentation of the default constructor. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Milan Zamazal <mzamazal@redhat.com>
2024-11-26ipa: libipa: vector: Add r(), g() and b() accessorsLaurent Pinchart
The Vector class can be useful to represent RGB pixel values. Add r(), g() and b() accessors, similar to x(), y() and z(), along with an RGB type that aliases Vector<T, 3>. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Milan Zamazal <mzamazal@redhat.com>
2024-11-26ipa: libipa: vector: Add mutable x(), y() and z() accessorsLaurent Pinchart
The x(), y() and z() functions of the Vector class are convenience accessors for the first, second and third element of the vector respectively, meant to improve readability of class users when a vector represents coordinates in 1D, 2D or 3D space. Those accessors are limited to immutable access to the vector elements, as they return a copy. Extend the API with mutable accessors. The immutable accessors are modified to return a reference to the vector elements instead of a copy for consistency. As they are inline functions, this should make no difference in terms of performance as the compiler can perform the same optimizations in their case. While at it, reorder functions to declare operators before other member functions, to be consistent with the usual coding style. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Milan Zamazal <mzamazal@redhat.com>
2024-11-26libcamera: Rename "shutter speed" to "exposure time"Laurent Pinchart
The terms "shutter" and "shutter speed" are used through libcamera to mean "exposure time". This is confusing, both due to "speed" being used as "time" while it should be the inverse (i.e. a maximum speed should correspond to the minimum time), and due to "shutter speed" and "exposure time" being used in different places with the same meaning. To improve clarity of the code base and the documentation, use "exposure time" consistently to replace "shutter speed". This rename highlighted another vocabulary issue in libcamera. The ExposureModeHelper::splitExposure() function used to document that it splits "exposure time into shutter time and gain". It has been reworded to "split exposure into exposure time and gain". That is not entirely satisfactory, as "exposure" has a defined meaning in photography (see https://en.wikipedia.org/wiki/Exposure_(photography)) that is not expressed as a duration. This issue if left to be addressed separately. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Naushir Patuck <naush@raspberrypi.com> Acked-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-11-25libcamera: libipa: camera_sensor_helper: add IMX290 black levelGeoffrey Van Landeghem
Report the default sensor black level reported by the datasheet. Note that IMX327 and IMX462 depend on the IMX290 CameraSensorHelper. That's fine since those sensors report the same defaults for the black level as the Sony IMX290. Signed-off-by: Geoffrey Van Landeghem <geoffrey.vl@gmail.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
2024-11-25ipa: raspberrypi: Add tuning file for IMX327 sensorGeoffrey Van Landeghem
Add a default tuning file for Sony IMX327 sensor. This tuning file is a copy of the IMX290 and is added to make the IMX327 sensor just work without hassle. Note the extra description field to clarify this is just an interim tuning file untill someone provides a proper one. Signed-off-by: Geoffrey Van Landeghem <geoffrey.vl@gmail.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
2024-11-25ipa: raspberrypi: Add tuning file for IMX462 sensorGeoffrey Van Landeghem
Add a default tuning file for Sony IMX462 sensor. This tuning file is a copy of the IMX290 and is added to make the IMX462 sensor just work without hassle. Note the extra description field to clarify this is just an interim tuning file untill someone provides a proper one. Signed-off-by: Geoffrey Van Landeghem <geoffrey.vl@gmail.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
2024-11-25ipa: rpi: cam_helper: Add Sony IMX327Geoffrey Van Landeghem
The IMX327 sensor is largely compatible with the already supported Sony IMX290 so we can reuse the same helpers for the analogue gain conversion functions. Signed-off-by: Geoffrey Van Landeghem <geoffrey.vl@gmail.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
2024-11-25libcamera: libipa: camera_sensor: Provide helper and properties for Sony IMX462Geoffrey Van Landeghem
The sensor is largely compatible with the already supported Sony IMX290 so we can reuse the same helpers for the analogue gain conversion functions. Signed-off-by: Geoffrey Van Landeghem <geoffrey.vl@gmail.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
2024-11-25libipa: FCQueue: Make sure FrameContext#0 is initializedJacopo Mondi
Some IPA modules, like the RkISP1 one, call FCQueue::get(0) at IPA::start() time, before any frame context has been allocated with FCQueue::alloc() called at queueRequest() time. The FCQueue implementation aims to detect when a FrameContext is get() before it is alloc()-ated, Warns about it, and initializes the FrameContext before returning it. In case of frame#0, a get() preceding an alloc() call is not detected as the "frame == frameContext.frame" test returns success, as FrameContexts are zeroed by default. As a result, the first returned FrameContext is not initialized. Explicitly test for frame#0 to make sure the FrameContext is initialized if get(0) is called before alloc(0). To avoid re-initializing a frame context, in case alloc() has been called correctly before get(), introduce an "initialised" state variable that tracks the FrameContext initialisation state. Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Reviewed-by: Stefan Klug <stefan.klug@ideasonboard.com>
2024-11-19ipa: rpi: awb: Disable CT search bias for Grey World AWBNaushir Patuck
If grey world AWB is setup in the tuning file, the CT curve will either be missing or invalid. Disable biasing the statistics for the search in such cases. Fixes: ea8fd63d936f ("ipa: rpi: awb: Add a bias to the AWB search") Signed-off-by: Naushir Patuck <naush@raspberrypi.com> Reviewed-by: David Plowman <david.plowman@raspberrypi.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-11-18ipa: rpi: Use centralised libipa helpersDaniel Scally
Use the centralised libipa helpers rather than open coding common functions. Signed-off-by: Daniel Scally <dan.scally@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
2024-11-18ipa: rkisp1: Use centralised libipa helpersDaniel Scally
Use the centralised libipa helpers instead of open-coding common functions. Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Signed-off-by: Daniel Scally <dan.scally@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Milan Zamazal <mzamazal@redhat.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2024-11-18ipa: ipu3: Use centralised libipa helpersDaniel Scally
Use the centralised libipa helpers instead of open coding common functions. Signed-off-by: Daniel Scally <dan.scally@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Milan Zamazal <mzamazal@redhat.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2024-11-18ipa: libipa: Add colour helpersDaniel Scally
We start to have some functions relating to colour that are effectively identical crop up across the IPA modules. Add a file allowing those to be centralised within libipa so that a single implementation can be used in all of the IPAs. Signed-off-by: Daniel Scally <dan.scally@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Milan Zamazal <mzamazal@redhat.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2024-11-13ipa: libipa: Add data accessor to HistogramStefan Klug
For debugging purposes it is helpful to access the internal data of the histogram. Add an accessor for that. Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-11-13ipa: rkisp1: Add debug metadata support to the rkisp1Stefan Klug
Add a DebugMetadata helper to the context and add the corresponding plumbing. This is all that is needed to support debug metadata in an IPA. Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-11-13ipa: rkisp1: Add constructor to the ipa contextStefan Klug
Initialization using the initializer list is cumbersome and requires modifications to the list whenever the context is modified. Fix that by adding a proper constructor to the context. Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-11-11libcamera: Rationalize IPA and handlers namesJacopo Mondi
The names used by the IPA interface and the names used for buffer completions handlers in libcamera clash in the use of the term "buffer". For example video device buffer completion handler is called "bufferReady" and the IPA event to ask the IPA to compute parameters are called "fillParamsBuffers". This makes it hard to recognize which function handles video device completion signals and which ones handle the IPA interface events. Rationalize the naming scheme in the IPA interface function and events and the signal handlers in the pipelines, according to the following table. Remove the name "buffer" from the IPA interface events and events handler and reserve it for the buffer completion handlers. Rename the IPA interface events and function to use the 'params' and 'stats' names as well. IPA Interface: - fillParamsBuffer -> computeParams [FUNCTION] - processStatsBuffer -> processStats [FUNCTION] - paramFilled -> paramsComputed [EVENT] Pipeline handler: - bufferReady -> videoBufferReady [BUFFER HANDLER] - paramReady -> paramBufferReady [BUFFER HANDLER] - statReady -> statBufferReady [BUFFER HANDLER] - paramFilled -> paramsComputed [IPA EVENT HANDLER] Cosmetic change only, no functional changes intended. Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Milan Zamazal <mzamazal@redhat.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-11-04controls: rpi: Add a vendor rpi::ScalerCrops controlNaushir Patuck
Add a vendor control rpi::ScalerCrops that is analogous to the current core::ScalerCrop, but can apply a different crop to each configured stream. This control takes a span of Rectangle structures - the order of rectangles must match the order of streams configured by the application. Signed-off-by: Naushir Patuck <naush@raspberrypi.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2024-10-28ipa: libipa: Fix ExposureModeHelper function name in documentationLaurent Pinchart
Previous iterations of the ExposureModeHelper class had a setShutterGainLimits() function, which got renamed to setLimits(). The documentation still uses the old name. Fix it. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
2024-10-21ipa: rpi: Add tuning files for OV7251Dave Stevenson
OV7251 is a mono VGA global shutter sensor that has a mainline driver and works with libcamera. Add the supporting files for it. The tuning is copied from OV9281. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Naushir Patuck <naush@raspberrypi.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-10-18libcamera: software_isp: Black level from tuning fileMilan Zamazal
This patch allows obtaining a black level from a tuning file in addition to the camera sensor helper. If both of them define a black level, the one from the tuning file takes precedence. The use cases are: - A user wants to use a different black level, for whatever reason. - There is a sensor without known gains but with a known black level. Because a camera sensor helper cannot be defined without specifying gains, the only way to specify the black level is using the tuning file. Software ISP uses its fallback gain handling in such a case. Signed-off-by: Milan Zamazal <mzamazal@redhat.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-10-18libcamera: software_isp: Get black level from the camera helperMilan Zamazal
The black level in software ISP is unconditionally guessed from the obtained frames. CameraSensorHelper optionally provides the black level from camera specifications now. Let's use the value if available. If the black level is not available from the given CameraSensorHelper instance, it's still determined on the fly. Signed-off-by: Milan Zamazal <mzamazal@redhat.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Tested-by: Robert Mader <robert.mader@collabora.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-10-18libcamera: software_isp: Clear IPA context on configure and stopRobert Mader
Like the hardware pipelines do. Not clearing frameContexts otherwise can trigger asserts like "Frame context for ... has been overwritten by ..." when switching between cameras using the swISP, e.g. on phones. Clearing the configuration and active state will become more important with upcoming changes such as getting the black level from the camera helper. Fixes: 04d171e6b299 ("libcamera: software_isp: Call Algorithm::queueRequest") Signed-off-by: Robert Mader <robert.mader@collabora.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Milan Zamazal <mzamazal@redhat.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-10-18ipa: rkisp1: algorithms: awb: Check for correct stats typeStefan Klug
Sometimes the ISP produces statistics only with a subset of statistic types being valid. It doesn't happen normally, but was observed in the wild. Check for the RKISP1_CIF_ISP_STAT_AWB bit to prevent using invalid or outdated data. As it doesn't happen regularly add an error message to get notified when it happens. For simpler code structure, the ColourTemperature metadata entry gets written unconditionally and overwritten later if needed. Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-10-18ipa: rkisp1: algorithms: agc: Check for correct stats typeStefan Klug
Sometimes the ISP produces statistics only with a subset of statistic types being valid. It doesn't happen normally, but was observed in the wild. Check for the RKISP1_CIF_ISP_STAT_AUTOEXP bit to prevent using invalid or outdated data. As it doesn't happen regularly add an error message to get notified when it happens. Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-10-08ipa: rpi: awb: Add a bias to the AWB searchNaushir Patuck
In the case of an AWB search failure, the current algorithm logic will return a point on the CT curve closest to where the search finisned. This can be quite undesirable. Instead, add some bias params to the AWB algorithm which will direct the search to a set CT value in the case where statistics become unreliable causing the search to fail. Signed-off-by: Naushir Patuck <naush@raspberrypi.com> Reviewed-by: David Plowman <david.plowman@raspberrypi.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-10-08ipa: rpi: awb: Add a const for the default colour temperatureNaushir Patuck
A default CT of 4500K is used in a couple of places. Add a constexpr value for the default CT value and use it instead. 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: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-10-03libcamera: software_isp: Improve wording in a commentMilan Zamazal
A minor wording improvement suggested on refactoring review. Signed-off-by: Milan Zamazal <mzamazal@redhat.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-09-30ipa: rpi: Replace last users of math.hLaurent Pinchart
As described in the coding style document, libcamera favours <cmath> over <math.h>. Replace the last few occurrences of the latter with the former in the Raspberry Pi IPA and adapt the code accordingly. In some cases, the <math.h> include is simply dropped as it isn't needed. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
2024-09-30ipa: rpi: Use std::abs()Laurent Pinchart
As explained in the coding style document, usage of std::abs() is preferred over abs() or fabs() as it picks the correct function based on the argument type. Replace calls to abs() and fabs() with std::abs() in the Raspberry Pi algorithms. This fixes a reported warning from clang: ../src/ipa/rpi/controller/rpi/awb.cpp:508:6: error: using integer absolute value function 'abs' when argument is of floating point type [-Werror,-Wabsolute-value] if (abs(denominator) > eps) { ^ ../src/ipa/rpi/controller/rpi/awb.cpp:508:6: note: use function 'std::abs' instead if (abs(denominator) > eps) { ^~~ std::abs Reported-by: Maarten Lankhorst <dev@lankhorst.se> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by: Naushir Patuck <naush@raspberrypi.com> Reviewed-by: Naushir Patuck <naush@raspberrypi.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>