Add a small utility function that calculates the quantized gain that
gets applied by a sensor when the gain code is set to gainCode(gain).
This is needed by algorithms to calculate a digital correction gain that
gets applied to mitigate the error introduce by quantization.
Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com>
Reviewed-by: Isaac Scott <isaac.scott@ideasonboard.com>
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
The i.MX8 M Plus has a compression curve inside the compand block. This
curve is necessary to process HDR stitched data and is useful for other
aspects like applying a digital gain to the incoming sensor data.
Add a basic algorithm for the compression curve. This algorithm has a
hardcoded input width of 20bit and output width of 12bit which matches
the imx8mp pipeline. Only a static gain is supported in this version.
Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
The public and internal Doxygen API documentation is compiled and
installed in api-html and internal-api-html directories respectively.
The '-html' suffix doesn't provide any value, and the asymmetry between
the names can be confusing. Rename the directories to public-api and
internal-api respectively.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Stefan Klug <stefan.klug@ideasonboard.com>
Reviewed-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com>
The libcamera documentation comprises two parts: pages generated by
Sphinx into the Documentation/html/ directory within the build tree, and
API reference documentation generated by Doxygen into
Documentation/internal-api-html/ and Documentation/api-html/. The two
parts are generated separately, but link to each other.
From Sphinx to Doxygen, we use the doxylink extension for Sphinx to
generate links to the Doxygen pages corresponding to API elements. The
extension needs to be configured with the paths to the Doxygen
documentation, which are set based on the html/, api-html/ and
internal-api-html/ directories being placed side by side in the same
parent directory.
Furthermore, we also want to link to the API documentation from the
Sphinx toctree. As toctrees can only link to pages within the Sphinx
documents tree (or to http URLs), we have placeholder .rst documents for
api-html and internal-api-html in the Sphinx documentation tree. Those
generate the Documentation/html/internal-api-html/index.html and
Documentation/html/api-html/index.html placeholder files in the build
tree.
The other way around, the API documentation's introduction pagelinks to
Sphinx pages using relative paths. Those paths are hardcoded based on
the api-html/ and internal-api-html/ directories being children of the
html/ directory.
This results in links being broken in different ways in the build tree,
as well as in the installation directory: the toctree links direct to
the placeholder pages within the html/ directory instead of the Doxygen
documentation in sibling directories, and the Doxygen introduction links
to Sphinx are simply broken. When publishing documentation on the
website we work around those issues by overriding conf.py with a custom
version and moving the api-html/ and internal-api-html/ directories to
the html/ directory.
Fixing this is surprisingly difficult. The toctree links can't be
changed to point to a path outside of the Sphinx document tree as this
isn't supported by Sphinx. Using http URLs would link to the
libcamera.org website inside of local documentation, which isn't
acceptable. It may be possible to develop a Sphinx extension to patch
the toctree after it gets parsed, but that would be complex and likely
fragile. Modifying the install path of the Doxygen documentation to
html/api-html/ and html/internal-api-html/ causes issues as the Sphinx
documentation will then overwrite the Doxygen index.html files with the
placeholder indexes. Creating symlinks from html/api-html/ to api-html/
in the installation directory causes similar problems if 'meson install'
is run twice. Creating the symlinks in the build directory (which was
attempted with a custom Sphinx extension) is also a no-go: starting with
meson v1.8.0, installing symlinks to directories causes an exception due
to a bug in meson.
The right solution is probably to investigate usage of the doxysphinx
extension. As that's no small amount of work, let's start with a
non-perfect but simple improvement: configure doxylink based on the
api-html/ and internal-api-html/ directories being children of the
Sphinx html/ documentation, and move those two API documentation
directories to html/ during installation with a post-install script.
This fixes links in the installation directory. Links in the build
directory remain broken, with the toctree links and the links from
Doxygen to Sphinx being broken already, and the links to API elements
through doxylink now being broken too. This is considered as an
acceptable compromise and an overall improvement. The installation
directory is more important, as in the build tree people also have
access to sources. Application developers in particular are less likely
to read documentation from the libcamera build tree, they may not even
have a copy of the libcamera source tree.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Stefan Klug <stefan.klug@ideasonboard.com>
The libcamera Sphinx documentation contains three toctrees: a main
toctree that contains all documentation pages in a flat hierarchy, and
two hidden toctrees that point to the introduction and API pages. This
architecture is mostly meant to support publishing the documentation on
the libcamera.org website. The process recreates a hybrid documentation
tree mixing content specific to the website and content extracted from
libcamera. The hidden toctrees are used to prevent Sphinx from warning
about unreferenced pages when the documentation is built as part of
libcamera.
This set of hacks work, but produce unorganized documentation in the
build directory, as well as when installed to the system. Furthermore,
they make it difficult to host multiple versions of the libcamera
documentation on the website, which we will eventually want to do as the
API stabilizes. It would be generally better to host on libcamera.org
the documentation built as part of libcamera with the same structure of
documents.
To prepare for that change, reorganize the toctrees in libcamera with
three visible trees: a toctree for users, a toctree for developers, and
a toctree for integrators. Include the public and internal API pages
in the first two trees respectively. This mimics the structure of the
documentation as currently organized on the website. The resulting
documentation becomes easier to navigate in the build and installation
directories.
Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com>
Our current theme doesn't handle many of the rst features (namely notes,
proper code highlighting, font formatting). The sphinx book theme
provides a unobtrusive design which makes the documentation way more fun
to read. The branding is minimal. The libcamera logo is included and
theme colors are set to the libcamera blue.
To get meson/sphinx to successfully compile the docs the package
"python3-sphinx-book-theme" needs to be installed (at least on debian
based systems).
Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Stefan Klug <stefan.klug@ideasonboard.com>
Include doxygen-awesome-css in the doxygen config.
The project's documentation indicated that the HTML_COLORSTYLE option
needs to be set to LIGHT starting with Doxygen 1.9.5. The reason isn't
explained, and tests have not shown any noticeable difference with
Doxygen 1.9.5, 1.13.2 and 1.14.0.
Unlike Doxygen itself that generates different CSS files depending on
the HTML color style, doxygen-awesome-css use the same CSS that defaults
to auto-light, and relies on adding "light-mode" to the class of the
<html> element manually to disable dark mode.
As we don't do this, doxygen-awesome-css effectively operates in
auto-light mode. Given that setting HTML_COLORSTYLE to LIGHT makes no
visible difference, leave the option unset to default to auto-light mode
that matches the actual behaviour.
Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Stefan Klug <stefan.klug@ideasonboard.com>
Reviewed-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com>
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>
Stefan Klug
Laurent Pinchart
Matthias Fend
Benjamin Mugnier
Barnabás Pőcze
Milan Zamazal
Paul Elder
David Plowman
Umang Jain
Hans de Goede
Naushir Patuck
Kieran Bingham
Antoine Bouyer
William Vinnicombe