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 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>
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 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>
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>
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>
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>
`std::atomic_{load,store}()` with `std::shared_ptr` has been deprecated
in C++20 in favour of `std::atomic<std::shared_ptr<>>`. However, it is
not available on all supported platforms. So ignore the deprecation warnings.
The specialization is available since gcc (libstdc++) 12 and llvm (libc++) 15.
Signed-off-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
There is nothing inherently non-constexpr in the `Quantized` type. Whether
it can work in `constexpr` contexts depends on the traits type. There is
no reason to explicitly disallow `constexpr` operation. So mark all eligible
methods `constexpr`.
In addition, add some `static_assert()`s to the "quantized" test to check
constexpr operation.
For example, `FixedPointQTraits<...>::toFloat()` is `constexpr`, so this
enables the construction of `{U,}Q<...>` from the underlying quantized
value in `constexpr` contexts, which can be useful for example for
storing default values in e.g. `static constexpr` variables.
Signed-off-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
`CameraSensorHelper::gain(uint32_t)` maps a gain code to the actual floating
point gain value. Calling it with `1.0` as the argument will simply get
the real gain for gain code 1. This is most likely not what was intended.
For example, in the case of the `ov2740` sensor, `againMin` is 1, but the
calculated `again10` (1 / 128 ~ 0.078) ends up being < 1, meaning that the
agc algorithm will never lower the exposure.
Fix that by using the maximum of the minimum gain and 1 as `again10`.
Fixes: 950ca85e8a ("ipa: software_isp: AGC: Do not lower gain below 1.0")
Signed-off-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com>
Reviewed-by: Milan Zamazal <mzamazal@redhat.com>
Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
The controller min frame duration is used to rate limit how often we
run IPAs. Historically this has been set to 33333us, meaning that the
algorithms effectively skip frames when the camera is running faster
than 30fps.
This patch adds a small amount of plumbing that allows this value to
be set in the Raspberry Pi configuration file. Some applications or
platforms (such as Pi 5) are easily capable of running these more
often, should there be a need to do so.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
'const auto' and 'auto const' are interchangeable in C++. There are 446
occurrences of the former in the code base, and 67 occurrences of the
latter. Standardize on the winner.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com>
The standard C library header for the poll() API is poll.h, not
sys/poll.h. The musl C library warns about this:
In file included from src/android/camera_stream.cpp:13:
host/i586-buildroot-linux-musl/sysroot/usr/include/sys/poll.h:1:2: error: #warning redirecting incorrect #include <sys/poll.h> to <poll.h> [-Werror=cpp]
1 | #warning redirecting incorrect #include <sys/poll.h> to <poll.h>
| ^~~~~~~
Fix it by including the correct header.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com>
The Mali-C55 ISP has a digital gain block which allows setting gain in Q5.8
format, a range of 0.0 to (very nearly) 32.0.
Convert usage to the new UQ<5, 8> FixedPoint Quantised type which will
support the conversion, clamping and quantisation so that the metadata
and debug prints can now report the effective gain applied instead of
the potentially inaccurate float.
Reviewed-by: Isaac Scott <isaac.scott@ideasonboard.com>
Reviewed-by: Stefan Klug <stefan.klug@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
The RKISP1 supports a configurable Hue as part of the colour processing
unit (cproc).
Implement the new control converting to the hardware scale accordingly
and report the applied control in the completed request metadata.
This is implemented as a phase shift of the chrominance values between
-90 and +87.188 degrees according to the datasheet however the type
itself would imply that this is a range between -90 and 89.2969.
Moreover, the hardware applies the inverse phase shift to the operation
expected and documented by libcamera, so we apply a negative scale when
converting the libcamera control to the Q<1,7> type, resulting in a
range of -89.2969 to +90.0 degrees control.
Reviewed-by: Isaac Scott <isaac.scott@ideasonboard.com>
Tested-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
