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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
The RkISP1 IPA module creates a single instance of its IPAFrameContext
structure, effectively using it more as an active state than a per-frame
context. To prepare for the introduction of a real per-frame context,
move all the members of the IPAFrameContext structure to a new
IPAActiveState structure. The IPAFrameContext becomes effectively
unused at runtime, and will be populated back with per-frame data after
converting the RkISP1 IPA module to using a frame context queue.
The IPAActiveState structure will slowly morph into a different entity
as individual algorithm get later ported to the frame context API.
While at it, fix a typo in the documentation of the
Agc::computeExposure() function that incorrectly refers to the frame
context instead of the global context.
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Frame contexts will become the core component of IPA modules, always
available to functions of the algorithms. To indicate and prepare for
this, turn the frame context pointer passed to Algorithm::process() into
a reference.
The RkISP1 IPA module doesn't use frame contexts yet, so pass a dummy
context for now.
While at it, drop an unneeded [[maybe_unused]] from Agc::process() and
add a missing parameter documentation for the frameContext argument to
Awb::process().
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Add support for manually controlling the color gains on the rkisp1 IPA.
To that end, add and plumb the AwbEnable and ColourGains controls. As
per-frame controls aren't supported yet in the rkisp1 IPA, simply apply
and perform checks on the controls immediately.
Signed-off-by: Paul Elder <paul.elder@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>
Denoise and Sharpness filters will be applied by RkISP1 during the
demosaicing step. The denoise filter is responsible for removing noise
from the image, while the sharpness filter will enhance its acutance.
Add filter algorithm with denoise and sharpness values based on user
controls.
Signed-off-by: Florian Sylvestre <fsylvestre@baylibre.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
The Defect Pixel Cluster Correction algorithm is responsible to minimize
the impact of defective pixels. The on-the-fly method is actually used,
based on coefficient provided by the tuning file.
Signed-off-by: Florian Sylvestre <fsylvestre@baylibre.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
The Lens Shading Correction algorithm applies multipliers to all pixels
to compensate for the lens shading effect. The coefficients are
specified in a downscaled table in the YAML tuning file.
Signed-off-by: Florian Sylvestre <fsylvestre@baylibre.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Forward declarations of IPACameraSensorInfo and inclusion of
linux/rkisp1-config.h are not needed in headers that use them only for
arguments to functions defined by the Algorithm base class, as inclusion
of algorithm.h will bring the necessary declarations for function
arguments. Drop them.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Florian Sylvestre <fsylvestre@baylibre.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
To prepare for dynamic instantiation of algorithms from the tuning file,
register the algorithms with the Module class.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
libipa defines an abstract Algorithm class template that is specialized
by IPA modules. IPA modules then instantiate and manage algorithms
internally, without help from libipa. With ongoing work on tuning data
support for the RkISP1, and future similar work for the IPU3, more code
duplication for algorithms management is expected.
To address this and share code between multiple IPA modules, introduce a
new Module class template that will define and manage top-level concepts
for the IPA module.
The Module class template needs to be specialized with the same types as
the Algorithm class. To avoid manual specialization of both classes,
store the types in the Module class, and replace the template arguments
of the Algorithm class with a single Module argument from which the
other types are retrieved.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Currently we have a single structure of IPAFrameContext but
subsequently, we shall have a ring buffer (or similar) container
to keep IPAFrameContext structures for each frame.
It would be a hassle to query out the frame context required for
process() (since they will reside in a ring buffer) by the IPA
for each process. Hence, prepare the process() libipa template to
accept a particular IPAFrameContext early on.
As for this patch, we shall pass in the pointer as nullptr, so
that the changes compile and keep working as-is.
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
The RkISP1 ISP calculates a mean value for Y, Cr and Cb at each frame.
There is a RGB mode which could theoretically give us the values for R,
G and B directly, but it seems to be failing right now.
Convert those values into R, G and B and estimate the gain to apply in a
grey world.
Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Tested-by: Peter Griffin <peter.griffin@linaro.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
As for the IPU3, we can estimate the histogram of the luminance. The
RkISP1 can estimate multiple ones, the R, G and B ones, the Y only one
and a combination of RGB. The one we are interested by in AGC is the Y
histogram.
Use the hardware revision to determine the number of bins of the
produced histogram.
Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Tested-by: Peter Griffin <peter.griffin@linaro.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
In order to have the proper pixel levels, apply a fixed black level
correction, based on the imx219 tuning file in RPi. The value is 4096 on
16 bits, and the pipeline for RkISP1 is on 12 bits, scale it.
Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Tested-by: Peter Griffin <peter.griffin@linaro.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Use the new utils::abs_diff() function where appropriate to replace
manual implementations.
While at it fix a header ordering issue in
src/libcamera/pipeline/raspberrypi/raspberrypi.cpp.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
When a new parameter buffer needs to be queued, we need to specify which
algorithm is activated or not in the ISP. Add a simple prepare function
in AGC for that, which may later evolve to take the exposure locking
into account. For that function to be called, we also need to add the
loop on the algorithms in IPARkISP1::queueRequest.
We no longer disable the AE algorithm based on the controls::AeEnable,
which will be handled in a different manner later.
Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Now that we have IPAContext and Algorithm, we can implement a simple AGC
based on the IPU3 one. It is very similar, except that there is no
histogram used for an inter quantile mean. The RkISP1 is returning a 5x5
array (for V10) of luminance means. Estimating the relative luminance is
thus a simple mean of all the blocks already calculated by the ISP.
Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Laurent Pinchart
Quentin Schulz
Kieran Bingham
Marvin Schmidt
Florian Sylvestre
Paul Elder
Umang Jain
Jean-Michel Hautbois