For both vc4 and pisp, vd55g1.json has been generated using ctt with
rpi.dpc algorithm removed as this is already handled in the sensor's
ISP. vd55g1_mono.json has been adapted from vd55g1.json by removing
color correction related algorithms.
Adding Cyril Liotard as co-developer for providing the base vd55g1.json
tuning files for both vc4 and pisp. Thank you.
Co-Developed-by: Cyril Liotard <cyril.liotard@st.com>
Signed-off-by: Cyril Liotard <cyril.liotard@st.com>
Signed-off-by: Benjamin Mugnier <benjamin.mugnier@foss.st.com>
Acked-by: Naushir Patuck <naush@raspberrypi.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Take the unique pointer to the `Fence` object by rvalue reference
so that it is not destroyed if the function returns an error code
and does not take ownership of the unique pointer.
Signed-off-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Stefan Klug <stefan.klug@ideasonboard.com>
In commit b8d332cdcc ("libcamera: framebuffer: Replace vector with
span in constructor") the FrameBuffer::planes() function was modified to
return a Span instead of a vector. This leads to the following runtime
exception in the python binding:
TypeError: Unregistered type : libcamera::Span<libcamera::FrameBuffer::Plane const, 18446744073709551615ul>
Fix that by manually converting the Span to a vector.
Note: The best solution would be to implement a Span type caster for
pybind11. But implementing and testing that properly is a bit more
involved than expected. As we don't need bidirectional mapping, use the
same workaround as for FrameMetadata::planes() for now.
While at it, update the lambda for pyFrameMetadata.planes() to call the
inner planes() only once.
Fixes: b8d332cdcc ("libcamera: framebuffer: Replace vector with span in constructor")
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>
Reviewed-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com>
First, there is a single big endian format defined in `formats.yaml`: RGB565_BE.
However, while the yaml file specifies "big_endian: true", the python script
looks for a key named "big-endian". Causing `RGB565{,_BE}` both to be the same.
Second, the python script simply appends " | DRM_FORMAT_BIG_ENDIAN" to the
fourcc of the format. However, there is no definition of that macro is
available in the only user, `formats.h.in`.
Fix the first one by checking for "big_endian" in the script as well, and
fix the second one by defining a constant with the same value and using that.
Signed-off-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com>
Fixes: 7c496f1c54 ("utils: gen-formats: Support big-endian DRM formats")
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
GPU ISP can produce only 32-bit output. Let's add support to the PPM
writer for all the common RGB image formats so that we can store GPU ISP
output as PPM files. Contingent alpha values are ignored as there is no
support for the alpha channel in PPM.
There is no obvious performance penalty in my environment compared to
output in the raw format.
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Milan Zamazal <mzamazal@redhat.com>
Reviewed-by: Pavel Machek <pavel@ucw.cz>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Forcing the "non-pod" members to be initialized from `const T&` is not the
ideal solution because it disallows e.g. move constructors. So generate a
templated constructor, which members to be initialized more freely, e.g.
using move constructors.
Signed-off-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>
In the near future we will add a SyncAdjustment control for adjusting
the frame duration via the sync algorithm. This control needs to be able
to take on a negative value, since the frame duration can be shortened
in addition to being extended. While the control is an int, it would be
convenient to be able to clamp it to frame duration limits, which are
usually handled as utils::Duration values internally. To allow this
using utils::Duration, add a unary negation operation to
utils::Duration. Also add a test for the operator.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.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>
The CCM algorithm will now let an explicit colour matrix be set when
AWB is in manual mode.
We must handle any controls that can cause the AWB to be enabled or
disabled first, so that we know the AWB's state correctly when we come
to set the CCM.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
[Kieran: Remove duplicated Matrix3x3 from ccm.cpp]
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Pass Request::ReuseBuffers flag to request->reuse()
where the same buffers are added to the request, as the flag
exists precisely for such use cases.
This commit also drops invalid comments about creating new requests,
since requests were already being reused for `buffer_import`
and `capture` tests since commit c753223ad6
("libcamera, android, cam, gstreamer, qcam, v4l2: Reuse Request").
Signed-off-by: Umang Jain <uajain@igalia.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
If the currently selected camera disappears as reported by the `cameraRemoved`
signal, then `MainWindow::camera_` is reset to `nullptr`. In this case,
pressing the start/stop button will try to start streaming, leading to
a nullptr derefence in `MainWindow::startCapture()` when the configuration
is generated for the camera.
Fix that by returning from `MainWindow::toggleCapture()` if no camera is set.
While this will cause the "checked" status of `startStopAction_` to go out of
sync, this should not be an issue because when a new camera is selected, the
state is synchronized.
Bug: https://bugs.libcamera.org/show_bug.cgi?id=177
Signed-off-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>
The sharpening default values are updated to be slightly less
aggressive, and exposure profiles are made slightly more
consistent. This now matches the latest tuning changes.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Sharpening is reduced slightly for official Raspberry Pi cameras, and
exposure profiles made a bit more consistent.
Denoise is reduced for the imx708 where it appears too strong.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Noise and detail tuning is improved for all official Raspberry Pi
cameras.
The old tunings left too much noise in and even sharpened some of
it. The new tunings remove more noise, and no longer sharpen it. Some
of the more general over-sharpening is also removed. Note that lost
detail can be recovered well using TDN (temporal denoise), which is
the recommended method to get the best results.
There are some minor adjustments to the CDN deviation, now that this
gets backed-off as TDN ramps up.
The contrast in the gamma in the bright areas is also toned down just
a little.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
The default noise/sharpness/gamma values are updated to reflect the
latest camera tuning work.
- Denoise is increased when not using temporal denoise.
- Denoise is reduced when benefitting from temporal denoise.
- Over-sharpening is reduced.
- High contrast gamma is slightly reduced.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
The CDN (colour denoise) deviation gets gradually reduced frame by
frame as TDN (temporal denoise) comes in and has more effect. CDN is
more harmful to image detail than TDN, so ramping it down in favour of
TDN is beneficial.
The tuning file parameters are chosen so that existing tuning files
don't have to be updated and will carry on working "mostly like they
did" (apart from the new back-off).
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Add an imx415 tuning file for both the VC4 and PiSP. This tuning file
has been created and supplied by Arducam to support the B0569 module.
Note that this conflicts with an already existing imx415.json and
as such is provided as imx415_b0459.json.
More work will be required to support module specific tuning file
parsing.
Acked-by: Naushir Patuck <naush@raspberrypi.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Add an imx335 tuning file for both VC4 and PiSP. This tuning file
has been created and supplied by Arducam to support the B0568 module.
Acked-by: Naushir Patuck <naush@raspberrypi.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
In current implementation, the sink pad counter of the crossbar is not
incremented if the pad is not connected to any subdevice. This would lead
to incorrect routing and format configuration if CSI is not connected
to first sink pad.
To avoid such issue, every sink pads must be taken into account. Then if
CSI and sensor are present, current counter is used for routing at match(),
and stored in camera data to be reused during configure().
Signed-off-by: Antoine Bouyer <antoine.bouyer@nxp.com>
Tested-by: Pavel Löbl <pavel@loebl.cz>
Tested-by: Julien Vuillaumier <julien.vuillaumier@nxp.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
libcamera uses the meson python module to handle native compilation of
Python extension modules, and uses the shared_module() function when
cross-compiling due to an issue in the python module. The difference
between native and cross compilation also extends to the installation
path: native compilation lets the python module handle the paths, while
cross compilation constructs a path manually using a heuristic based on
the Python version and hardcoded components.
This manually-constructed installation path is problematic for cross
compilation for the same reason it caused issue when used for native
compilation: it is not guaranteed to be right, and it can't be
overridden by users.
Switch to obtaining the installation path from the meson python module
for cross-compilation as well. This also prepares for usage of
py.extension_module() once the file suffix issue will be fixed in meson.
On Debian 13, this change replaces the incorrect path
/usr/local/lib/python3.12/site-packages/libcamera with the still (but
differently) incorrect /usr/local/lib/python3/dist-packages/libcamera.
Future fixes in meson to address this issue will make the path correct
by default.
When the path calculated by the python module is not correct, it can now
be overridden by the user through the meson python.platlibdir
configuration variable.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
libcamera uses the meson python module to handle native compilation of
Python extension modules.
When cross-compiling, the module uses the build machine suffix instead
of the host machine suffix in some enviroments (for instance naming the
shared object file _libcamera.cpython-313-x86_64-linux-gnu.so instead of
_libcamera.cpython-313-aarch64-linux-gnu.so when cross-compiling from
x86_64 to aarch64). This prevents using the python module in that case,
and libcamera uses the normal dependency() function to locate the Python
libraries, and the shared_module() function to build the module.
Not using the meson python module to get the Python dependency prevents
selecting a specific Python interpreter, the same way as it does for
native builds. While having multiple Python interpreter versions in a
cross-build environment is likely less common, different behaviours and
features between native and cross-compilation are still not optimal.
Improve this situation by getting the dependency from the python module
for cross-compilation as well. This also prepares for usage of
py.extension_module() once the file suffix issue will be fixed in meson.
The user will need to ensure that the Python interpreter for the build
machine matches the version of the interpreter in the cross-compilation
environment for the host machine. Otherwise, meson will fail to find the
Python dependency. Cross-compilation environment provided by Linux
distributions (such as Debian multi-arch support) should work out of the
box, but compiling libcamera manually against a cross-compilation
environment provided by Buildroot or Yocto may require manual
configuration.
When the interpreters versions do not match, meson needs to be pointed
to the build ùachine interpreter from the cross-compilation environment
using the cross file. For instance, assuming a 'br_host_dir' variable
pointing to the host directory from Buildroot, the cross file should
contain
[binaries]
python = br_host_dir / 'bin/python3'
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
The existing meson.build file installs the bindings to a manually
constructed directory that is not included in the Python path in most
distributions. For instance, on a Debian 12 system, the modules is
intalled in /usr/lib/x86_64-linux-gnu/python3.11/site-packages/, while
the Python interpreter looks for site packages in
/usr/lib/python3/dist-packages/.
It also always builds the bindings using the system Python, as it
searches for the Python library using the standard dependency()
function. This prevents build the Python bindings for a different
interpreter version without changing the system default interpreter.
Modify the build process to use the meson python module to build the
Python bindings targets, so it installs them to the correct directories
for Python. This also allows specifying a different target Python
interpreter through the '[binaries]' section of a meson native file.
The behaviour is not changed for cross-compilation, as the meson python
module has known issues in that case.
Signed-off-by: William Vinnicombe <william.vinnicombe@raspberrypi.com>
Co-developed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
The meson python module's find_installation() method conveniently allows
testing if the interpreter provides a set of modules. We use it to check
for the presence of the modules required at build time. Unfortunately,
the meson python module is not meant to access the system Python
interpreter of the build machine, but the Python environment of the host
machine.
Usage of find_installation() for this purpose is incorrect, it may find
modules in a different interpreter than the one used to run the build
scripts that use those modules. For instance, when cross-compiling
libcamera against a Buildroot environment, and pointing meson in the
cross-file to the build machine Python interpreter from Buildroot, the
find_installation() method will refer to the latter, while our code
generation scripts that use the modules will use the former.
Replace find_installation() with a manual check using python3 directly.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
When checking the version of the sphinxcontrib.doxylink module, the
Python interpreter used by Sphinx must be used, as that's where the
module will be imported from. Using the meson python_installation object
for this purpose is incorrect, as it's meant to access the Python
installation of the host machine, not the system Python interpreter on
the build machine.
For instance, when cross-compiling libcamera against a Buildroot
environment, and pointing meson in the cross-file to the build machine
Python interpreter from Buildroot, the meson python module will refer to
the latter, while Sphinx will use the former.
Fix this by using python3 directly.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
The planes variable in the Device::createFrameBuffer() function is a
reference to buffer.planes() that is only used as a range initializer in
a range-based for loop. Use buffer.planes() directly and drop the
variable.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
The minimum version of meson currently required by libcamera, v0.63,
does not properly detect Qt6. As qcam switched from Qt5 to Qt6 a while
ago, building libcamera with meson v0.63 is currently broken.
The issue was fixed in meson v0.64. That was the last meson version
before v1.0.0. For mainly psychological reasons, and to avoid bumping
the meson version too often, go straight to v1.0.1. This will support
the following versions of popular distributions and build environments:
- Debian Bookworm and newer (v1.0.1)
- Ubuntu 24.04LTS and newer (v1.3.2)
- Buildroot 2023.08 (v1.1.1)
- Yocto Scarthgap (v1.3.1)
The previous version of Debian, Ubuntu and Yocto shipped versions of
meson older than v0.63 (v0.56.2 in Debian Bullseye, v0.61.2 in Ubuntu
22.04LTS, and v0.61.3 in Yocto Kirkstone), so the meson version bump
doesn't require a distribution upgrade. For Buildroot, moving to v1.0.1
means users on versions from 2022.08 (when not using qcam) or 2023.02 to
2023.05 will need to upgrade.
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 paths of the doxygen tag files for sphinxcontrib-doxygen must be
absolute or relative the the current working directory. However, when
libcamera is built as a subproject, the current working directory
is the top-level build directory. Thus the paths for the tag files
will not be correct.
Fix that by using `configure_file()` to generate the final sphinx
configuration with the appropriate paths queried from meson.
Fixes: 0382d215db ("Documentation: Use Sphinx doxylink to generate links to doxygen")
Signed-off-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
If `addModel` is true, then the previously set `name` will be overwritten.
This does not seem to be the intended behaviour, so fix it by using `+=`.
Before:
Available cameras:
1: 'imx219' (/base/soc@0/bus@30800000/i2c@30a30000/camera@10)
After:
Available cameras:
1: External camera 'imx219' (/base/soc@0/bus@30800000/i2c@30a30000/camera@10)
Fixes: aab49f903e ("cam: Do not assume Location is available")
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>
In `Semaphore::release()`, unlocking the mutex before signalling the condition
variable can be problematic, especially with "temporary" objects such as the
ones `BoundMethodBase::activatePack()` uses to handle `ConnectionTypeBlocking`.
Specifically, `Semaphore::acquire()` might lock the mutex after `Semaphore::release()`
has unlocked it, but before it had the chance to notify the condition variable.
In that case `Semaphore::acquire()` can succeed, and execution may proceed to
destroy the `Semaphore` object while the other thread is in the process of
running `std::condition_variable::notify_all()`.
Bug: https://bugs.libcamera.org/show_bug.cgi?id=225
Fixes: 66e7c5b774 ("libcamera: Add Semaphore class")
Signed-off-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
