| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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 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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
