| Age | Commit message (Collapse) | Author |
|---|
|
The libcamera project is not yet ready to declare ABI nor API stability,
but it will benefit the community to be able to provide more regular
release cycles to determine 'versioned' points of history.
Ideally, these releases will be made at any ABI breakage, but can be
made at arbitary time based points along the way.
To support releases which may not be ABI stable, declare the soversion
of both the libcamera and libcamera-base library to be dependant upon
both the major minor and patch component of the project version.
As part of this, introduce a new 'Versions' summary section to highlight
the different version components that may become apparent within any
given build.
Bumping versions may leave dangling libcamera.so.* symlinks in build
directories. This will confuse Doxygen which will print during its
directory scanning phase a warning that the symlink can't be read. As we
don't need Doxygen to follow symlinks, disable it with EXCLUDE_SYMLINKS.
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
V4L2 has deprecated queuing output buffers with bytesused set to 0. Warn
if the caller attempts to do so.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Tested-by: Naushir Patuck <naush@raspberrypi.com>
|
|
The bytesused value for the parameters buffer is initialized to 0 and
never set. The V4L2 API specification indicates that, for an output
video device, the driver will set the bytesused value to the size of the
plane in that case. The videobuf2 framework does so, but considers this
as deprecated and prints a warning:
[ 54.375534] use of bytesused == 0 is deprecated and will be removed in the future,
[ 54.388026] use the actual size instead.
Fix it by setting bytesused to the correct value before queuing the
parameters buffer.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Tested-by: Naushir Patuck <naush@raspberrypi.com>
|
|
The bytesused value for the parameters buffer is initialized to 0 and
never set. The V4L2 API specification indicates that, for an output
video device, the driver will set the bytesused value to the size of the
plane in that case. The videobuf2 framework does so, but considers this
as deprecated and prints a warning:
[ 54.375534] use of bytesused == 0 is deprecated and will be removed in the future,
[ 54.388026] use the actual size instead.
Fix it by setting bytesused to the correct value before queuing the
parameters buffer.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Tested-by: Naushir Patuck <naush@raspberrypi.com>
|
|
Private members of the FrameBuffer class are split between FrameBuffer
and FrameBuffer::Private. There was no real justification for this
split, and keeping some members private in the FrameBuffer class causes
multiple issues:
- Future modifications of the FrameBuffer class without breaking the ABI
may be more difficult.
- Mutable access to members that should not be modified by applications
require a friend statement, or going through the Private class.
Move all remaining private members to the Private class to address the
first issue, and add a Private::metadata() function to address the
second problem.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Tested-by: Naushir Patuck <naush@raspberrypi.com>
|
|
utils::defopt causes compilation issues on gcc 8.0.0 to gcc 8.3.0,
likely due to bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86521
that was fixed in gcc 8.4.0. gcc 8.3.0 may be considered old (libcamera
requires gcc-8 or newer), but it is shipped by Debian 10 that has LTS
support until mid-2024.
As no workaround has been found to fix compilation on gcc 8.3.0 while
still retaining the functionality of utils::defopt, remove it from the
libcamera base library. This change could be reverted once support for
gcc-8 will be dropped.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The ControlList::set() function overload used for array controls
constructs a Span from an initializer list. It doesn't specify the Span
size explicitly, which results in a dynamic extent Span being
constructed. That causes a compilation failure for fixed-size array
controls, as they are defined as Control<T> with T being a fixed-extent
Span, and conversion from a dynamic-extent to fixed-extent Span when
calling ControlValue::set() can't be implicit.
Fix this by constructing the Span using the size of the control, which
resolves to a fixed-extent and dynamic-extent Span for fixed-size and
dynamic-size array controls respectively. The ControlList::set()
function that takes an initializer list can then be used for fixed-size
array controls.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
Array controls specify the array size through the YAML 'size' element,
which stores a list of values, one per dimension. Variable-size arrays
currently use an empty 'size' list, which prevents describing the number
of dimensions of the array.
Improve this by using the same notation for fixed-size and variable-size
array controls. Dimensions that are not fixed are described as a string
instead of an integer, such as [n], [n,3] or [w,h]. The strings have
currently no special meaning, this may change in the future.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
The REGISTER_PIPELINE_HANDLER() macro defines a class type that inherits
from the PipelineHandlerFactory class, and implements a constructor and
a createInstance() function. Replace the code generation through macro
with the C++ equivalent, a class template, as done in libipa with the
Algorithm and CameraSensorHelper factories.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Xavier Roumegue <xavier.roumegue@oss.nxp.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Avoid naked pointer with memory allocation by returning a unique_ptr
from PipelineHandlerFactory::createInstance(), in order to increase
memory allocation safety.
This allows iterating over factories in the CameraManager and unit tests
using const pointers.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Xavier Roumegue <xavier.roumegue@oss.nxp.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The PipelineHandlerFactory::create() function has no need to modify the
factory instance. Make it const, as well as the createInstance()
function.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Xavier Roumegue <xavier.roumegue@oss.nxp.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Commit 036d26d6677e ("test: threads: Test thread cleanup upon abnormal
termination") added calls to functions provided by the pthread library
in the threads test, but didn't add the corresponding dependency. This
caused a link breakage on some platforms:
/usr/bin/ld: test/threads.p/threads.cpp.o: undefined reference to symbol 'pthread_cancel@@GLIBC_2.4'
/usr/bin/ld: /lib/arm-linux-gnueabihf/libpthread.so.0: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
Fix it by adding the missing dependency.
Fixes: 036d26d6677e ("test: threads: Test thread cleanup upon abnormal termination")
Reported-by: Naushir Patuck <naush@raspberrypi.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Tested-by: Naushir Patuck <naush@raspberrypi.com>
Acked-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Append "_mono" to the sensor name when generating the tuning filename for
monochrome sensor variants. So the new naming convention is as follows:
<sensor_name>.json - Standard colour sensor variant
<sensor_name>_mono.json - Monochrome sensor variant
Rename the existing imx296.json file to imx296_mono.json as this tuning file
is based on the monochrome variant of the IMX296.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Add BayerFormat conversions for formats::R12 (12-bit unpacked) format.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The "R" pixel formats (R8, R10, R10_CSI2P etc.) record the associated
colour space as being YUV rather than RAW, meaning that the code was
not detecting them as being raw formats.
In the case of Raspberry Pi, we deal only with raw formats, so the
revised test must work correctly for both these and the standard Bayer
formats.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The base V4L2Device class is bound to a video device node by either
open(), which opens the device node and creates a new file descriptor,
or setFd(), which takes an already open file descriptor. The former
populates the V4L2Device instance controls, while the latter doesn't.
This prevents using controls on V4L2 M2M devices. Fix it by populating
controls in setFd(), which is called by open().
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Xavier Roumegue <xavier.roumegue@oss.nxp.com>
|
|
v4l2_ext_controls.errorIdx (in the case of single failing control for
VIDIOC_*_EXT_CTRLS calls) represents the index of that control.
Since it is a single control, we can print the control id rather than
its index. This improves logging as the id can be easily co-related
with the controls while reading the log.
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Currently, if a Unicam timeout is signalled, the pipeline handler only raises
an error message. Update the error handling to put the pipeline handler in an
internal error state, disable all device streams, and return all outstanding
requests as cancelled. Any subsequent requests that come into the pipeline
handler will also be returned as cancelled.
Any further error handling (e.g. a reset with camera stop()/start()) is up to
the application to perform as it requires.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Add an error state used internally in the Raspberry Pi pipeline handler.
Currently this state is never set, but will be in a subsequent commit when a
device timeout has been signalled.
Add a isRunning() helper to identify if the state machine is in a stopped/error
state.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Since commit bedef55d9500 ("libcamera: pub_key: Gracefully handle failures
to load public key") the build will fail if openssl is not found on the
host system.
Use the existing HAVE_IPA_PUBKEY define to avoid accessing pubKey_ which
does not exist when building without openssl.
Signed-off-by: Matthias Fend <matthias.fend@emfend.at>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
The min/max/def ControlValue of a ControlInfo can take arbitrary types that
are different from each other and different from the ControlId type.
The serialiser serialises these ControlValue separately by their type but
does not store the type. The deserialiser assumes that ControlValue types
match the ControlId type. If this is not the case, deserialisation will try
to deserialise values of the wrong type.
Fix this by serialising each of the min/max/def ControlValue's ControlType
and storing it just before the serialised ControlValue.
Fixes: https://bugs.libcamera.org/show_bug.cgi?id=137
Signed-off-by: Christian Rauch <Rauch.Christian@gmx.de>
Tested-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
Commit e297673e7686 ("libcamera: v4l2_device: Adjust colorspace based on
pixel format") has introduced a warning when trying to convert a color
space from V4L2 to libcamera if the media bus code is unknown. This was
meant to catch unknown image formats, but turned out to be also
triggered for metadata formats.
Color spaces are not applicable to metadata formats, there should thus
be no warning. Fix it by skipping the color space translation and
returning std::nullopt directly if the kernel reports
V4L2_COLORSPACE_DEFAULT. This doesn't introduce any change in behaviour
other than getting rid of the warning, as the V4L2Device::toColorSpace()
function returns std::nullopt already in that case.
Fixes: e297673e7686 ("libcamera: v4l2_device: Adjust colorspace based on pixel format")
Reported-by: Naushir Patuck <naush@raspberrypi.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Tested-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
|
|
A UVC device could expose only formats that are not supported by
libcamera. The pipeline handler doesn't currently consider this as an
error, and happily creates a camera. The camera won't be usable, and
worse, generateConfiguration() and validate() will crash as those
functions assume that at least one format is supported.
Fix this by failing match() if none of the formats exposed by the camera
are supported. Log an error message in that case to notify the user.
Bug: https://bugs.libcamera.org/show_bug.cgi?id=145
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Tested-by: Christian Rauch <Rauch.Christian@gmx.de>
|
|
Populate and cache the list of supported formats in
UVCCameraData::init(), to avoid repeating the operation every time
generateConfiguration() is called. Combine this with the search for
the largest size advertised by the camera to avoid iterating over the
formats twice in init().
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Tested-by: Christian Rauch <Rauch.Christian@gmx.de>
|
|
Move the camera ID generation to UVCCameraData, and cache the ID in that
class. This will be useful to access the ID in multiple locations, such
as when printing error messages.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Tested-by: Christian Rauch <Rauch.Christian@gmx.de>
|
|
When the V4L2Device fails to open, it is not clear what device
caused the failure. The Entity name is presented, but not the device
node.
Provide it.
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
If the CameraSensor fails to identify the VCM specified, it could still
be possible to continue to operate the sensor. Autofocus support will be
disabled, but this would be no different to operating a camera with a
fixed focus. While of course the fixed focus position may not be
suitable, it would provide a better user experience to be able to
continue to operate the camera, while still reporting that the lens is
disabled.
Bug: https://bugs.libcamera.org/show_bug.cgi?id=146
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
It can be helpful to know 'which' file failed to parse if there is a
failure.
Report it to the user in the error message.
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
Overriding the dependency enables libcamera to be used
as a meson subproject more easily.
Signed-off-by: Barnabás Pőcze <pobrn@protonmail.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The ycbcrEncodingToV4l2 map is missing the YCbCrEncoding::None encoding,
which results in a failure of V4L2Device::fromColorSpace() to convert
color spaces from libcamera to V4L2 for RGB formats. Fix it by adding
the missing encoding. As V4L2 has no such encoding, use
V4L2_YCBCR_ENC_DEFAULT as the value doesn't matter.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
Add support for color space to the uvcvideo pipeline handler. UVC
devices have a fixed color space per format, so only the validate()
function needs to be extended to retrieve the color space from the
kernel. There is no need to pass the value back to the driver in
configure().
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
The CameraConfiguration::validateColorSpaces() function performs color
space validation on a camera configuration, by validating the color
space of each stream individually, and optionally ensuring that all
streams share the same color space. The individual validation is very
basic, limited to ensuring that raw formats use a raw color space.
Color spaces are more constrained than that:
- The Y'CbCr encoding and quantization range for RGB formats must be
YcbcrEncoding::None and Range::Full respectively.
- The Y'CbCr encoding for YUV formats must not be YcbcrEncoding::None.
Instead of open-coding these constraints in the validateColorSpaces()
function, create a new ColorSpace::adjust() function to centralize color
space validation and adjustment, and use it in validateColorSpaces().
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
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>
|
|
Rectify the ColorSpace::Srgb to denote that it does not use
any Y'Cbcr encoding and uses full range.
The kernel on the other hand, recommends to use Rec601 as the encoding
for V4L2_COLORSPACE_SRGB. It is not very explicit but it can be
inferred that the kernel assumes V4L2_COLORSPACE_SRGB is a YUV-encoded
one. However, when the data is in RGB, no encoding is required (and
this is denoted by YcbcrEncoding::None in libcamera).
Hence, to be clear on the libcamera colorspace API, rectify the
ColorSpace::Srgb preset to use YcbcrEncoding::None and full range.
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
Wrap V4L2Device::toColorspace() inside a private static member
function in V4L2VideoDevice class. It improves readability in
setting the colorspace for V4L2DeviceFormat.
No functional changes intended.
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
V4L2 has no "none" YCbCr encoding, and thus reports an encoding for all
formats, including RGB and raw formats. This causes the libcamera
ColorSpace to report incorrect encodings for non-YUV formats. Fix it by
overriding the encoding reported by the kernel to YCbCrEncoding::None
for non-YUV pixel formats and media bus formats.
Similarly, override the quantization range of non-YUV formats to full
range, as limited range isn't used for RGB and raw formats.
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
Store the colour encoding corresponding to a media bus format in the
V4L2SubdeviceFormatInfo structure. This will be used to implement color
space adjustments.
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
The Request::Private::reuse() is different from Request::reuse().
It resets the members of Request::Private to default values hence,
rename it to a more appropriate Request::Private::reset().
Update the usage and documentation accordingly.
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
doxygen didn't create proper links to the overloads of
MediaDevice::link because the signatures didn't match due to an
additional 'const'
While at it remove the unnecessary `MediaDevice::` and wrap the lines
Fixes: b65feafe3244 ("libcamera: media_device: Add functions to get a MediaLink")
Signed-off-by: Marvin Schmidt <marvin.schmidt1987@gmail.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Implement color space support in the rkisp1 pipeline handler, in the
configuration generation, configuration validation and camera
configuration. As all the processing related to the color space is
performed in the part of the pipeline shared by all streams, a single
color space must cover all stream configurations. This is enforced
manually when generating the configuration, and with the
validateColorSpaces() helper when validating it.
Only the Y'CbCr encoding and quantization range are currently taken into
account, and they are programmed through the V4L2 color space API. The
primary colors chromaticities and the transfer function need to be
configured in the ISP parameters buffer, and thus conveyed to the IPA,
but the rkisp1 driver does not currently support tone mapping, so this
will be done later.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Florian Sylvestre <fsylvestre@baylibre.com>
|
|
Add a ColorSpace:fromString() function to parse a string into a color
space. The string can either contain the name of a well-known color
space, or four color space components separate by a '/' character.
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>
|
|
Sort the members of the ColorSpace class in color_space.cpp to match the
color_space.h order. No functional change intended.
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>
|
|
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>
|
|
Using Size::expandTo() to find the max resolution might generate a non-existent
resolution. For example, when application request streams for 1920x1080 and
1600x1200, the max resolution will be wrongly 1920x1200 and fails the
configuration.
Bug: https://bugs.libcamera.org/show_bug.cgi?id=139
Signed-off-by: Han-Lin Chen <hanlinchen@chromium.org>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Use a const reference in range-based for loops to avoid copies of the
loop elements.
While at it, change looping over controls in
PipelineHandlerUVC::processControls to use structured bindings.
Signed-off-by: Christian Rauch <Rauch.Christian@gmx.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The specializations of the YamlObject::get() function template for
integer types duplicate code that doesn't directly depend on the
template type argument. Move it to separate helper functions to reduce
the object size.
While at it, rephrase the comment about unsigned integer parsing.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The YamlObject::get() function template is implemented for 16-bit and
32-bit integers. Add an 8-bit specialization that will be used in the
rkisp1 IPA module, and extend the unit tests accordingly.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The YamlObject::get() function specializations for 16-bit integers cast
the return value of strto(u)l() to a 16-bit integer, rendering the
bounds checking useless. Fix them.
Fixes: c7d260c03abd ("libcamera: yaml_parser: Add get() specializations for 16-bit integers")
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The variable 'ret' is assigned but not read until after the next
assignment.
Signed-off-by: Christian Rauch <Rauch.Christian@gmx.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The colorspace fields are read-only from an application point of view,
both on video devices and on subdevs, unless the
V4L2_PIX_FMT_FLAG_SET_CSC or V4L2_MBUS_FRAMEFMT_SET_CSC flags
(respectively) are set when calling the S_FMT ioctl.
Set the flags accordingly within the V4L2SubDevice and V4L2Device when
a colorspace is being set by the application.
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Usage of find_library() to find dependencies that libcamera needs to
compile against can lead to the library being found even if the
corresponding headers are not installed. This will then result in a
compilation failure. Switch to dependency() for libdw, libunwind and
lttng-ust to fix this, all three libraries come with a pkgconfig file
that is usually installed by the distribution package that contains the
library headers.
Reported-by: Christian Rauch <Rauch.Christian@gmx.de>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
|
