When generating control headers, the YAML files to be used are
determined dynamically based on the selected pipeline handlers. As part
of this process, the build system populates an array of meson File
objects used as an input for the control headers generation custom
target, as well as an array of file names (as strings). The file names
array is later used to generate the control source files for the
libcamera core, as well as the source code for controls support in the
Python bindings.
Both of the source code generators manually turn the array of file names
into File objects. This duplicates code and reduces readability. A third
similar implementation has also been proposed to generate control
support sources in the GStreamer element, making the issue worse.
To simplify this, store File objects instead of file names in the
controls_files array. As the meson configuration summary doesn't support
File objects, create a separate controls_files_names to store the file
names for that sole purpose.
The exact same process occurs for properties, address them the same way.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
The init_py_*() functions are called by the top-level entry point of the
libcamera Python module to initialize different parts of the bindings.
They are declared in py_main.cpp where they are called, and defined in
separate compilation units. This results in functions being defined
without a corresponding declaration, and will generate warnings when we
enable -Wmissing-declarations.
Fix this by moving the function declarations from py_main.c to
py_main.h, and including py_main.h in the various compilation units that
need it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Meson uses tags to sort installed files in categories, and makes it
possible to install a subset of the files using the '--tags' argument to
'meson install'. This is typically used by distributions to split the
runtime, development and documentation files into separate packages.
By default, meson tries to guess the correct tag for installed files,
but can't always do so properly. Mark the install targets that meson
can't guess with the correct install_tag.
As the feature has been introduced in meson 0.60, bump the minimum meson
version. The latest LTS release of all major distributions that
libcamera currently targets ship a recent enough meson version.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Label draft controls and properties through the "draft" vendor tag
and deprecate the existing "draft: true" mechanism. This uses the new
vendor tags mechanism to place draft controls in the same
libcamera::controls::draft namespace and provide a defined control id
range for these controls. This requires moving all draft controls from
control_ids.yaml to control_ids_draft.yaml.
One breaking change in this commit is that draft control ids also move
to the libcamera::controls::draft namespace from the existing
libcamera::controls namespace. This is desirable to avoid API breakages
when adding new libcamera controls. So, for example, the use of
controls::NOISE_REDUCTION_MODE will need to be replaced with
controls::draft::NOISE_REDUCTION_MODE.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Add support for using separate YAML files for controls and properties
generation. The mapping of vendor/pipeline handler to control file is
done through the controls_map variable in include/libcamera/meson.build.
This simplifies management of vendor control definitions and avoids
possible merge conflicts when changing the control_ids.yaml file for
core and draft controls. With this change, libcamera and draft controls
and properties files are designated the 'libcamera' vendor tag.
In this change, we also rename control_ids.yaml -> control_ids_core.yaml
and property_ids.yaml -> property_ids_core.yaml to designate these as
core libcamera controls.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
The template file to the gen-controls.py and gen-py-controls.py is now
passed in through the '-t' or '--template' command line argument instead
of being a positional argument. This will allow multiple input files to
be provided to the scripts in a future commit.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Add support for vendor-specific controls and properties to libcamera.
The controls/properties are defined by a "vendor" tag in the YAML
control description file, for example:
vendor: rpi
controls:
- MyExampleControl:
type: string
description: |
Test for libcamera vendor-specific controls.
This will now generate a control id in the libcamera::controls::rpi
namespace, ensuring no id conflict between different vendors, core or
draft libcamera controls. Similarly, a ControlIdMap control is generated
in the libcamera::controls::rpi namespace.
A #define LIBCAMERA_HAS_RPI_VENDOR_CONTROLS is also generated to allow
applications to conditionally compile code if the specific vendor
controls are present. For the python bindings, the control is available
with libcamera.controls.rpi.MyExampleControl. The above controls
example applies similarly to properties.
Existing libcamera controls defined in control_ids.yaml are given the
"libcamera" vendor tag.
A new --mode flag is added to gen-controls.py to specify the mode of
operation, either 'controls' or 'properties' to allow the code generator
to correctly set the #define string.
As a drive-by, sort and redefine the output command line argument in
gen-controls.py and gen-py-controls.py to ('--output', '-o') for
consistency.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Replace the usage of CameraConfiguration::transform with the newly
introduced CameraConfiguration::orientation.
Rework and rename the CameraSensor::validateTransform(transform) to
CameraSensor::computeTransform(orientation), that given the desired
image orientation computes the Transform that pipeline handlers should
apply to the sensor to obtain it.
Port all pipeline handlers to use the newly introduced function.
This commit breaks existing applications as it removes the public
CameraConfiguration::transform in favour of
CameraConfiguration::orientation.
Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
The python bindings layer has to parse the libcamera controls to ensure
that they are converted to suitable names for the python layer.
Part of this strips out common prefixes from control names, however the
SceneFlicker control would end up using an illegal name if processed in
the same way as the other controls.
The SceneFlicker control has now been removed as part of the
introduction of the AeFlickerMode and AeFlickerPeriod controls.
Remove the workaround in the python layer.
Fixes: 6fdbf3f38c ("libcamera: controls: Add controls for AEC/AGC flicker avoidance")
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
The meson style, which libcamera follows, recommends a space before
colons in function parameters. Fix the style violations through the
project.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Change the parameter type of `generateConfiguration()` from `const std::vector&`
to `libcamera::Span`. A span is almost always preferable to a const vector ref
because it does not force dynamic allocation when none are needed, and it allows
any contiguous container to be used.
A new overload is added that accepts an initializer list so that
cam->generateConfiguration({ ... })
keeps working.
There is no API break since a span can be constructed from a vector
and the initializer list overload takes care of the initializer lists,
but this change causes an ABI break.
Signed-off-by: Barnabás Pőcze <pobrn@protonmail.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
[Kieran: Apply checkstyle fixups]
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
We are using pybind11 'smart_holder' branch to solve the Camera
destructor issue (see the comment in this patch, or the commit
that originally added Python bindings support).
As it would be very nice to use the mainline pybind11 (which is packaged
in distributions), this patch adds a workaround allowing us to move to
the mainline pybind11 version.
The workaround is simply creating a custom holder class
(PyCameraSmartPtr), used only for the Camera, which wraps around the
shared_ptr. This makes the compiler happy.
Moving to mainline pybind11 is achieved with:
- Change the pybind11 wrap to point to the mainline pybdind11 version
- Tell pybind11 to always use shared_ptr<> as the holder for
PyCameraManager, as we use the singleton pattern for the
PyCameraManager, and using shared_ptr<> to manage it is a requirement
- Tell pybind11 to always use PyCameraSmartPtr<> as the holder for Camera
- Change the meson.build file to use a system-installed pybind11
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
The Python bindings will now accept, or return, a list or tuple of
libcamera.Rectangle objects for such controls.
This had previously been omitted, but now we have, for example, the
AfWindows control which requires this feature.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
The JPEG color space is badly name, as the JPEG specification (ITU-T
T.81) doesn't define any particular color space:
The interchange format does not specify a complete coded image
representation. Application-dependent information, e.g. colour
space, is outside the scope of this Specification.
The JFIF specification (ITU-T T.871) is clearer as it requires ITU-R
BT.601 YCbCr encoding and a full quantization range:
The interpretations of Y, CB, and CR are derived from the E'Y, E'Cb,
and E'Cr signals defined in the 625-line specification of Rec. ITU-R
BT.601, but these signals are normalized so as to permit the usage of
the full range of 256 levels of the 8-bit binary encoding of the Y
component.
It however doesn't specify color primaries or a transfer function
explicitly. It only mentions the latter when describing the conversion
from YCbCr to RGB:
The inverse relationship for computing full scale 8-bit per colour
channel gamma pre-corrected RGB values (following Rec. ITU-R BT.601
gamma pre-correction and colour primary specifications) from YCbCr
colours (with 256 levels per component) can be computed as follows:
[...]
Given that ITU-R BT.601-5 (1995) didn't specify color primaries or a
transfer function, and that the later ITU-R BT.601-7 (2011) version
specifies color primaries for the 625-line variant that do not match
sRGB, the JPEG color space in libcamera is badly named. This is
confirmed by ITU-T T.871:
As this Recommendation | International Standard is based on the prior
informally-circulated JFIF version 1.02 specification that was
produced in 1992, which referenced Rec. ITU-R BT.601 (formerly CCIR
601), it references that specification for definition of the E'Y,
E'Cb, and E'Cr signals that correspond to the YCBCR values specified
herein. However, since the development of the prior JFIF version 1.02
specification, additional industry specifications have been developed,
Rec. ITU-R BT.601 has been updated, and common industry practice has
emerged which often follows the sYCC specification in IEC
61966-2-1/Amd.1. The difference between the use of the colour
interpretation specification in this Recommendation | International
Standard and that of the sYCC specification may be considered
negligible in practice.
Rename the color space to sYCC, as its definition matches the sYCC
standard, and indicate that it is typically used to encode JPEG images.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Blocking wait can be easily implemented on top in Python, so rather than
supporting only blocking reads, or supporting both non-blocking and
blocking reads, let's support only non-blocking reads.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Wrap the CameraManager with a PyCameraManager class and move the related
code inside the new class.
This helps understanding the life times of the used-to-be global
variables, gets rid of static handleRequestCompleted function, and
allows us to simplify the binding code as the more complex pieces are
inside the class.
There should be no user visible functional changes.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
We always call CameraManager.read_event() and
CameraManager.get_ready_requests(), so to simplify the use merge the
read_event() into the get_ready_requests().
This has the side effect that get_ready_requests() will now block if
there is no event ready. If we ever need to call get_ready_requests() in
a polling manner we will need a new function which behaves differently.
However, afaics the only sensible way to manage the event loop is to use
select/poll on the eventfd and then call get_ready_requests() once,
which is the use case what the current merged function supports.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Implement non-contextmanager use to MappedFrameBuffer so that we can
either:
with MappedFrameBuffer(fb) as mfb:
...
or
mfb = MappedFrameBuffer(fb)
mfb.mmap()
...
mfb.munmap()
While at it, improve the error handling a bit.
Note that the mmap() returns self. In other words, one can do this:
mfb = MappedFrameBuffer(fb).mmap()
...
mfb.munmap()
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
We create symlinks from the Python bindings build dir to the source dir
so that 1) the build dir can be used to use the bindings, and 2) to
allow modifications of the source .py files to be used right away
without rebuilding.
The symlinks were recently fixed and changed to use absolute paths.
However, absolute paths ruin one main use case I have: using the
bindings from the build dir via nfs from an ARM device.
So move back to relative paths, but accomplish this with the --relative
parameter for ln, instead of guessing the right relative path as was
done before the above-mentioned fix.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Add ControlInfo class and change the controls related methods to
resemble the C++ API (e.g. no more string based control methods).
We don't implement ControlList or ControlInfoMap but just expose the
same data via standard Python dict.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
The Python bindings controls generation was not very good. It only
covered the enums and they were in the main namespace.
This adds the controls somewhat similarly to the C++ side. We will have
e.g.:
libcamera.controls.Brightness
libcamera.controls.AeMeteringModeEnum.CentreWeighted
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
