IPA proxies are created with a call to IPAManager::createIPA(), which is
a static member function. This requires a complicated dance in the
createIPA() function to retrieve the IPAManager instance through the
camera manager, itself retrieved from the pipeline handler. Simplify the
code by turning IPAManager::createIPA() into a non-static member
function, and providing a wrapper in the PipelineHandler class to keep
instantiation of IPA proxies easy in pipeline handlers.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com>
Reviewed-by: Isaac Scott <isaac.scott@ideasonboard.com>
libcamera uses std::unique_ptr<> to simplify life time management of
objects and avoid leaks. For historical reasons there are a fair number
of plain pointers with manual memory management. Replace them with
std::unique_ptr<> when the conversion is simple.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Milan Zamazal <mzamazal@redhat.com>
Reviewed-by: Isaac Scott <isaac.scott@ideasonboard.com>
Reviewed-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com>
`RkISP1Frames::{clear,destroy}()` always push all buffers from the
`RkISP1FrameInfo` object to the corresponding `available*Buffers_`
queues. This is not entirely correct.
If no dewarper is used, then `availableMainPathBuffers_` is never
consumed, so it will grow with each request. Fix it by only queueing
the buffer if `RkISP1CameraData::usesDewarper_`.
Additionally, in raw capture mode, no parameter or statistics buffers are
used, so those queues will be filled up with `nullptr`s without limit.
Fix that by only queueing them if they are not null.
Fixes: c8f63760e5 ("pipeline: rkisp1: Support raw Bayer capture at runtime")
Fixes: 12b553d691 ("libcamera: rkisp1: Plumb the dw100 dewarper as V4L2M2M converter")
Signed-off-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Stefan Klug <stefan.klug@ideasonboard.com>
Add the missing `override` specifiers in the derived classes of `Debayer`,
so that the compiler can ensure that the functions in the derived classes
really override the functions in the base class.
Signed-off-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Bryan O'Donoghue <bod.linux@nxsw.ie>
This member stores an egl image handle, but currently there is no need for it
since the image handle is only really used in `createDMABufTexture2D()`.
(`destroyDMABufTexture()` is an unused function.)
So remove the member (and the unused function), and instead destroy the image
immediately after calling `glEGLImageTargetTexture2DOES()`. The texture will
keep a reference to the image, so this is safe to do. In fact, this solves
an issue, specifically, the egl images were never destroyed, and continuously
leaked during streaming.
Fixes: f520b29fe9 ("libcamera: software_isp: debayer_egl: Add an eGL Debayer class")
Closes: https://gitlab.freedesktop.org/camera/libcamera/-/work_items/322
Signed-off-by: Gianfranco Mariotti <gianfranco.mariotti94@gmail.com>
Signed-off-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
The update-kernel-headers.sh script copies all headers to include/linux/
without creating subdirectories. This behaviour was correct until the
addition of linux/media/v4l2-isp.h, which should be copied to
include/linux/media/v4l2-isp.h, not include/linux/v4l2-isp.h. Fix it.
Fixes: ee8f88fc64 ("include: linux: Add v4l2-isp.h")
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com>
The recently added application options (DNG output support, KMS and SDL2
outputs for cam, and JPEG support for cam) are not printed in the
summary. This makes it more difficult to quickly assess the
configuration when those options are set to the 'auto' value. Add them
to the summary, and move all application configuration options to a
dedicated section of the summary to improve readability.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
All boolean options in libcamera other than the soft ISP options are
printed as YES/NO (with colours when supported by the terminal). Extend
this to the soft ISP options for consistency.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com>
drm_fourcc.h is the last file in libcamera to miss machine-parseable
license information. A patch to convert it to SPDX license identifiers
has been submitted to the kernel. Until it gets merged, apply the change
locally.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com>
Multiple files in the Raspberry Pi pipeline handler and IPA module are
missing SPDX headers. Add them with the following licenses:
- For code and documentation, use the BSD-2-Clause license, as for the
rest of the Raspberry Pi code.
- For the example pipeline handler configuration files, use the CC0-1.0
license to facilitate their usage.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Multiple files in libcamera are missing SPDX headers. Add them with the
following licenses:
- CC-BY-SA-4.0 for documentation
- CC0-1.0 for build system, development tool configuration files and
TODO lists, as we consider them non-copyrightable, and for example
configuration files to facilitate their use
- BSD-2-Clause for a file copied from the Raspberry Pi tuning tool (and
add the corresponding copyright information)
While at it, add a missing blank line to
src/libcamera/pipeline/virtual/README.md.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com>
The reuse tool fails to lint the extract-docs.py file because it
considers the 'SPDX-License-Identifier' string in a regex as a malformed
license identifier. Work around the issue by adding parentheses in the
regular expression, which doesn't affect the behaviour of the regex
matching but prevents the reuse tool from seeing the line.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com>
libcamera use the nlohmann_json wrap indirectly through libpisp. This
causes the nlohmann_json.wrap being copied to /subprojects at configure
time, and nlohmann_json being downloaded to /nlohmann_json-3.11.2. Add
an entryto .gitignore to cover both.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com>
The sensor-config property may optionally be specified to give the
outputSize and bitDepth of the SensorConfiguration that is applied to
the camera configuration. For example, use
libcamerasrc sensor-config="sensor/config,width=2304,height=1296,depth=10"
to request the 10-bit 2304x1296 mode of a sensor.
All three parameters, width, height and bit depth, must be present, or
it will issue a warning and revert to automatic mode selection (as if
there were no sensor-config at all).
If a mode is requested that doesn't exist then camera configuration
will fail and the pipeline won't start.
As future-proofing, the SensorConfiguration's binning, increment and
analog-crop parameters may be specified, though libcamera currently
ignores them.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Closes: https://gitlab.freedesktop.org/camera/libcamera/-/issues/300
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Tested-by: Fabien Danieau <fabien.danieau@pollen-robotics.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
The cam tool is our swiss army knife for interogating libcamera.
A frequently needed piece of information is to determine what version of
libcamera is installed or being run on a system.
This information is available in the debug logs of libcamera when a
CameraManager is instantiated. However without actually starting the
CameraManager this information is not presented.
Add an option to 'cam' to allow it to report the version. Whilst this
is the version from the 'cam' command, it directly gets the version of
the libcamera library to which cam is linked.
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Between v2 and the now merged v3 of commit 42d914f20c ("Documentation:
Enable doxygen-awesome-css") the GENERATE_TREEVIEW = YES was dropped
because it defaults to YES according to the doxygen web documentation.
Unfortunately for doxygen < 1.13.0 the default was NO. Fix the value to
YES so that doxygen-awesome-css works properly even with older versions
of doxygen.
Fixes: 42d914f20c ("Documentation: Enable doxygen-awesome-css")
Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com>
Tested-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com>
Reviewed-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Add the Pipeline handler name to the Camera Properties when a camera is
constructed.
This helps support and identify how the camera is being managed
internally and what configuration has taken effect, especially as the
pipeline handler chosen can be impacted by both environment variables
and configuration files.
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Introduce a script which can be installed into the system to aide
reporting potential camera and media related issues.
The script shall capture system information and store it in a temporary
file - but it remains the users responsibilty to choose to share this
data, and no automatic bug submissions are anticipated.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
The intent of the outputCfgs argument to the configure() function of
converter classes and the softISP is to allow the passed in stream-configs
to not be changed.
But only the vector is const, the reference inside the vector are not
const, which allows modifying the stream-configs as can be seen inside
DebayerEGL::configure() which was using a non const reference outputCfg
helper variable.
Fix this by making the references inside the vector const.
Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Reviewed-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
This commit removes the Raspberry Pi CTT from the libcamera source tree.
This change is introduced to help a number of RPi users who are not so
faimilar with git and cloing the libcamera tree to run the CTT. The
library is also modularised in python for our users to incorporate into
their own "tuning" applications if needed. Licensing for our CTT tool
remains the same.
The Raspberry Pi CTT now lives at the following repo:
https://github.com/raspberrypi/ctt
and a package is avilable on pypi to install:
https://pypi.org/project/rpi-ctt/
This commit also removes the delayedctrls_parse.py script that has long
since code rotted.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Acked-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Previously it was not possible to disable the use of libtiff in the cam
and qcam applications if it was detected. Fix that by adding a meson
feature option.
Signed-off-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Previously it was not possible to control these dependencies, they were
always used if found. Furthermore, libjpeg was unnecessarily added as a
dependency even if sdl2 was not found. Fix that by introducing three
options to control the dependencies.
Signed-off-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com>
Reviewed-by: Milan Zamazal <mzamazal@redhat.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
generateLut was failing to fill in the final slope value, meaning that
fully saturated pixels would full slightly short (the slope of the
final piecewise linear segment would default to zero).
The loop is slightly reorganised to fix the problem.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Nick Hollinghurst <nick.hollinghurst@raspberrypi.com>
Reviewed-by: Naushir Patuck <naush@rasbperrypi.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
As shown by commit 94d32fdc55 ("pipeline: simple: Consider output sizes
when choosing pipe config"), the extra pixel columns CPU debayering
requires on the input side makes resolution selection non trivial.
Add logging of the selected input config on a successful configure() so
that the logs clearly show which sensor mode has been selected.
Reviewed-by: Milan Zamazal <mzamazal@redhat.com>
Reviewed-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com>
Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Add CPU soft ISP multi-threading support.
Benchmark results for the Arduino Uno-Q with a weak CPU which is good for
performance testing, all numbers with an IMX219 running at
3280x2464 -> 3272x2464:
1 thread : 147ms / frame, ~6.5 fps
2 threads: 80ms / frame, ~12.5 fps
3 threads: 65ms / frame, ~15 fps
Adding a 4th thread does not improve performance.
Tested-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com> # ThinkPad X1 Yoga Gen 7 + ov2740
Reviewed-by: Milan Zamazal <mzamazal@redhat.com>
Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Add a DebayerCpuThreadclass and use this in the inner render loop.
This contains data which needs to be separate per thread.
This is a preparation patch for making DebayerCpu support multi-threading.
Benchmarking on the Arduino Uno-Q with a weak CPU which is good for
performance testing, shows 146-147ms per 3272x2464 frame both before and
after this change, with things maybe being 0.5 ms slower after this change.
Tested-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com> # ThinkPad X1 Yoga Gen 7 + ov2740
Reviewed-by: Milan Zamazal <mzamazal@redhat.com>
Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Make the storage used to accumulate the RGB sums and the Y histogram
value a vector of SwIspStats objects instead of a single object so
that when using multi-threading every thread can use its own storage to
collect intermediate stats to avoid cache-line bouncing.
Benchmarking with the GPU-ISP which does separate swstats benchmarking,
on the Arduino Uno-Q which has a weak CPU which is good for performance
testing, shows 20ms to generate stats for a 3272x2464 frame both before
and after this change.
Reviewed-by: Milan Zamazal <mzamazal@redhat.com>
Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
