Query the params device for RKISP1_CID_SUPPORTED_PARAMS_BLOCKS and
inject the information into the IPA hardware context for use by the
algorithms.
To be able to modify the hardware configuration at runtime, replace the
pointer with an instance and create a copy of the static hardware
specific data.
Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
The Y mode of the histogram gets captured at the ISP output, before the
output formatter. This has the side effect that the first and the last
bins are empty in case of limited YUV range. Another side effect is
that gamma and GWDR processing is included in the histogram which makes
algorithm development very difficult. In RGB mode the histogram is taken
after xtalk (CCM) and is therefore independent of gamma and WDR. The
limited range issue also does not apply. In the ISP reference it is
however stated that "it is not possible to calculate a luminance or
grayscale histogram from an RGB histogram since the position information
is lost during its generation".
During testing the RGB histogram provided good data and better
algorithmic stability at a possible (but not measured) inaccuracy.
Another option would be to pass the color space information into the IPA
and strip the histogram accordingly. For ease of implementation switch to
the RGB mode.
Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
When the extensible parameters queued to the kernel contain an unknown
block type it fails with -EINVAL. This should not happen as user land is
supposed to check for the supported parameter types. But it took a while
to figure out where things went wrong. Add a error statement when
queuing of the parameter buffer fails for whatever reason.
Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
There are several occasions where quantization can lead to visible
effects.
In WDR mode it can happen that exposure times get set to very low values
(Sometimes 2-3 lines). This intentionally introduced underexposure is
corrected by the GWDR module. As exposure time is quantized by lines,
the smallest possible change in exposure time now results in a quite
visible change in perceived brightness.
On some sensors the possible gain steps are also quite large leading to
visible jumps if e.g. if the exposure time is fixed.
Mitigate that by applying a global gain to account for the error
introduced by the exposure quantization.
ToDo: This needs perfect frame synchronous control of the sensor to work
properly which is not guaranteed in all cases. It still improves the
behavior with the current regulation and can easily be skipped, be
removing the compress algorithm from the tuning file.
Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Calculate the error introduced by quantization as "quantization gain"
and return it separately from splitExposure(). It is not included in the
digital gain, to not silently ignore the limits imposed by the AGC
configuration.
Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com>
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
In ExposureModeHelper::splitExposure() the quantization of exposure time
and gain is not taken into account. This can lead to visible flicker
when the quantization steps are too big. As a preparation to fixing
that, add a function to set the sensor line length and the current
sensor mode helper and extend the clampXXX functions to return the
quantization error.
By default the exposure time quantization is assumed to be 1us and gain
is assumed to not be quantized at all.
Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
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>
