When no log category is specified, `nullptr` is passed, and
then the `_log()` function implementations replace that with
`LogCategory::defaultCategory()`. But since the call site always
knows the log category, this condition can be removed and the
`_LOG1()` macro can use `LogCategory::defaultCategory()`.
So remove the condition from the `_log()` implementations and
use references to refer to log categories.
Signed-off-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
As CameraConfiguration::validate() might alter the configuration
previously negotiated with downstream, log an info when this happens as
GStreamer source elements are not supposed to do that.
Also check if downstream can accept this new stream configuration and if
not, return a not-negotiated error.
Signed-off-by: Jaslo Ziska <jaslo@ziska.de>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Umang Jain <uajain@igalia.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
gst_pad_peer_query_accept_caps() might only check if the caps are
acceptable with the peer element, but not recursively with all
downstream elements. If the reconfigure flag was set because the
pipeline downstream changed, gst_pad_peer_query_accept_caps() might still
return true, even though downstream can't handle the current caps, which
causes a not-negotiated error.
This commit fixes this issue by emitting a query event which
recursively checks with all downstream elements. Because at this point
we are only interested in whether the current caps are still acceptable,
use the currently used caps as a filter and then check if the query
returned empty caps.
Signed-off-by: Jaslo Ziska <jaslo@ziska.de>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Umang Jain <uajain@igalia.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Use the Sphinx doxylink extension to generate links to the
Doxygen-generated documentation automatically. Not only does this fix
currently broken links, but it also ensures that any removal or rename
of a class or function referenced to from the Sphinx documentation
without a corresponding documentation update will be caught by a
documentation build error.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Stefan Klug <stefan.klug@ideasonboard.com>
The libcamera Sphinx documentation needs to link to the API
documentation generated by Doxygen. The links currently point to the
documentation hosted on the official https://libcamera.org/ website.
This causes multiple issues:
- Doxygen generates URLs with MD5 hashes of function signatures, making
the link targets unstable.
- When testing documentation builds that include API changes, links to
new API elements will be broken.
- The generated documentation can't be browsed offline.
Fix this by using the Sphinx doxylink extension. This allows specifying
link targets as class and function names, with the link being
automatically generated using the same MD5 hashing as Doxygen. The root
of the link target is configured in a central location, which defaults
to the build directory and can be overridden to point to the libcamera
website when pushing the documentation.
This commit only introduces the infrastructure to use doxylink. Manual
links will be replaced separately.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Stefan Klug <stefan.klug@ideasonboard.com>
The name of the documentation authors listed in conf.py is seriously out
of date. As the information is bound to bitrot, replace the names by a
generic mention of the libcamera documentation authors.
While at it, update the copyright dates.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Stefan Klug <stefan.klug@ideasonboard.com>
libcamera only generates HTML documentation. Drop the unused
configuration options for other output formats, as well as unneeded
entries in the exclude patterns.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Stefan Klug <stefan.klug@ideasonboard.com>
The linux kernel documentation for the Media Controller has moved.
Update the URL accordingly to the new location.
The existing link pointed to the 'introduction' page - but this isn't
easy to identify or get an overview of the full documentation available
for media controller. Instead point the link to the top level of the
media controller userspace API pages.
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Commit a29c53f6a6 ("meson: Use libyaml wrap file from wrapdb")
modified the libyaml wrap in a way that resulted in the subproject
source code being stored in a different subdirectory, but didn't update
.gitignore accordingly. Fix it.
Fixes: a29c53f6a6 ("meson: Use libyaml wrap file from wrapdb")
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com>
Most pipeline handler methods are dispatched in the internal `CameraManager`
thread. `PipelineHandler::generateConfiguration()` is called directly,
however, which likely goes against the expectations, so call it on the
internal thread.
Before 14618cdd0c ("libcamera: base: bound_method: Move return value")
this could not be done because the function returns `std::unique_ptr`, and
that type cannot be copied.
Bug: https://bugs.libcamera.org/show_bug.cgi?id=273
Signed-off-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Only try to send the "Exit" message if the `IPCPipeUnixSocket` object
exists. If the constructor fails, then `ipc_` might remain nullptr,
which would lead to a nullptr dereference in the destructor.
This change also modifies the constructor so that only a valid
`IPCPipeUnixSocket` object will be saved into the `ipc_` member,
which avoids error messages when `IPCPipeUnixSocket::sendAsync()`
is callded in the inappropriate state.
Bug: https://bugs.libcamera.org/show_bug.cgi?id=276
Signed-off-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Accept empty `ControlList`s without an info map. Serialization
supports `ControlList`s without an associated `ControlInfoMap`
object. However, for deserialization, a "v4l2" control list
without an info map resulted in a fatal error.
After 30114cadd8 ("ipa: rpi: Defer initialising AF LensPosition ControlInfo and value")
the `lensControls` member of `ipa::RPi::ConfigResult` is left empty
and without an info map in every case, not just when a lens is not present.
This causes the above assertion to trigger every single time.
Also fix the indefinite article of "a ControlInfoMap" in the
error message.
Signed-off-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com>
Reviewed-by: Isaac Scott <isaac.scott@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
libcamera includes packaging information for Gentoo Linux. This is due
to historical reasons, the ebuild is not testing or maintained, and we
don't plan to add packaging information for other major distributions
such as Debian or Fedora. Drop the Gentoo ebuild.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Header comment blocks used to contain the file name. Considered as
useless information, the names have been removed, with the last ones
supposed to be dropped in commit d3bf27180e ("libcamera: Drop
remaining file names from header comment blocks"). A few have however
been forgotten, and more crept back since. Remove them.
While at it, fix one typo in a header comment block by replacing
'MaliC55 with Mali-C55', and add a missing blank line in
src/ipa/rpi/pisp/pisp.cpp.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
To debug color issues in a pipeline it is necessary to know the color
space used. Therefore add the color space to the string representation
of V4L2DeviceFormat that is returned by toString() and operator<<(). The
format gets for example printed as
[0:05:52.981684000] [230] DEBUG RkISP1 rkisp1_path.cpp:468 Configured main resizer video device with 1920x1080-NV12/sYCC
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <uajain@igalia.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
In Qt 6.9.0 the qtmochelpers.h header introduced a construct that gcc 12
and gcc 13 incorrectly flag as variable shadowing:
In file included from src/apps/qcam/qcam.p/moc_viewfinder_gl.cpp:12:
/usr/include/qt6/QtCore/qtmochelpers.h: In instantiation of ‘constexpr void QtMocHelpers::detail::UintDataStorage<std::integer_sequence<int, Idx ...>, T ...>::forEach(F&&) const [with F = QtMocHelpers::UintData<QtMocHelpers::SignalData<void(libcamera::FrameBuffer*)> >::copyTo<{anonymous}::qt_meta_tag_ZN12ViewFinderGLE_t, QtMocHelpers::MetaObjectContents<24, 10, 60, 3> >(QtMocHelpers::MetaObjectContents<24, 10, 60, 3>&, size_t, uint&) const::<lambda(const auto:39&)>; int ...Idx = {0}; T = {QtMocHelpers::SignalData<void(libcamera::FrameBuffer*)>}]’:
/usr/include/qt6/QtCore/qtmochelpers.h:255:21: required from ‘constexpr const QtMocHelpers::MetaObjectContents<24, 10, 60, 3> ViewFinderGL::qt_staticMetaObjectContent<{anonymous}::qt_meta_tag_ZN12ViewFinderGLE_t>’
src/apps/qcam/qcam.p/../../../../../../src/apps/qcam/viewfinder_gl.h:32:2: required from ‘constexpr const auto ViewFinderGL::qt_staticMetaObjectStaticContent<{anonymous}::qt_meta_tag_ZN12ViewFinderGLE_t>’
src/apps/qcam/qcam.p/moc_viewfinder_gl.cpp:63:5: required from here
src/apps/qcam/qcam.p/../../../../../../src/apps/qcam/viewfinder_gl.h:32:2: in ‘constexpr’ expansion of ‘ViewFinderGL::qt_create_metaobjectdata<{anonymous}::qt_meta_tag_ZN12ViewFinderGLE_t>()’
src/apps/qcam/qcam.p/moc_viewfinder_gl.cpp:58:87: in ‘constexpr’ expansion of ‘QtMocHelpers::metaObjectData<ViewFinderGL, {anonymous}::qt_meta_tag_ZN12ViewFinderGLE_t, StringRefStorage<char [13], char [15], char [1], char [24], char [7]>, UintData<SignalData<void(libcamera::FrameBuffer*)> >, UintData<>, UintData<> >(0, qt_stringData, qt_methods, qt_properties, qt_enums, QtMocHelpers::UintData<>(), const QtMocHelpers::detail::UintDataBlock<0, 0>{uint [1](), uint [1]()})’
/usr/include/qt6/QtCore/qtmochelpers.h:563:36: in ‘constexpr’ expansion of ‘(& methods)->QtMocHelpers::UintData<QtMocHelpers::SignalData<void(libcamera::FrameBuffer*)> >::copyTo<{anonymous}::qt_meta_tag_ZN12ViewFinderGLE_t, QtMocHelpers::MetaObjectContents<24, 10, 60, 3> >(result, ((size_t)dataoffset), metatypeoffset)’
/usr/include/qt6/QtCore/qtmochelpers.h:201:57: error: declaration of ‘entry’ shadows a member of ‘QtMocHelpers::detail::UintDataStorage<std::integer_sequence<int, 0>, QtMocHelpers::SignalData<void(libcamera::FrameBuffer*)> >’ [-Werror=shadow]
201 | [[maybe_unused]] auto invoke = [&f](const auto &entry) { f(entry.entry); return 0; };
| ~~~~~~~~~~~~^~~~~
/usr/include/qt6/QtCore/qtmochelpers.h:180:7: note: shadowed declaration is here
180 | T entry;
| ^~~~~
There is little we can do but silence the warning. Do so selectively
based on the Qt and gcc versions, to still detect variable shadowing
with compilers unaffected by the issue.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <uajain@igalia.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Camera creation is one of the most important events generated by
libcamera, but we are completely silent about it. The lack of a log
message makes it more difficult to identify problems and provide
support. Fix it by adding an Info message that reports the camera id and
its pipeline handler when the camera is added.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Umang Jain <uajain@igalia.com>
Reviewed-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
The match() function currently reports that it is not possible to create
any cameras if it encounters an empty media graph.
Fix this by looping over all media graphs and only returning false when
all of them fail to create a camera.
It is worth noting that an issue does exist when on a partial match that
ends in an invalid match, any media devices that were acquired will stay
acquired. This is not a new issue though, as any acquired media devices
in general are not released until pipeline handler deconstruction. This
requires a rework of how we do matching and pipeline handler
construction, so it is captured in a comment.
In the meantime, this fix fixes a problem without increasing the net
number of problems.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Tested-by: Hui Fang <hui.fang@nxp.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
In Camera::queueRequest() the control list is updated transparently by
converting AeEnable into ExposureTimeMode and AnalogueGainMode
controls.
However, this was not happening during Camera::start(), meaning that
setting AeEnable there was having no effect. It should behave the same
here too.
Fixes: 7abd413905 ("libcamera: camera: Pre-process AeEnable control")
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
ISI can be used to support multiple cameras at the same time in the media
device. A dedicated pad is assigned to each camera by HW (dts). We then
assign one (or more) source pad(s) depending on ISI constraints in the SoC.
Since ISI may have different number of pipes depending on SoC, the number
of cameras is computed _before_ going through all pipeline's components,
to limit number of pipes that could be assigned to a camera.
For instance, 3 is targeted as maximum amount of streams per camera as
defined by 'kNumStreams' constant. If 2 cameras are connected, with
only 5 ISI pipes, this target cannot be achieved. In such case, 2 streams
are assigned to each camera.
On the other hand, if ISI has 8 source pads (from index 6 to 13) and 2
cameras, first three source pads [6:8] are assigned to first camera, and
the three next source pads [9:11] are assigned to the second camera. All
these pads (sink and sources) must have same format to prevent configuration
mismatch during start.
However, since ISI routing must be performed _before_ any stream becomes
active, 'setRouting' is now executed during the 'match' step, instead of
'configure'. Indeed, it is up to the application to decide when a camera
'start' is executed: this could happen before or after the other camera
configuration is executed. Moving routing into the 'match' step makes sure
the routing is correctly applied before any 'start' is executed.
Signed-off-by: Antoine Bouyer <antoine.bouyer@nxp.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
This patch adds number of streams per camera as constructor parameter, and
limits stream count to 3. Some applications may need up to 3 streams for
preview + capture + video record. Currently, imx8-isi pipeline only supports
up to 2. Increase constant parameter to 3 to match these applications'
requirements.
Minimum value between default value 3, and total amount of ISI's pipes is
now applied. For SOCs which only have 1 ISI pipe (ie i.MX93), available
stream count becomes 1.
Signed-off-by: Antoine Bouyer <antoine.bouyer@nxp.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
The mali-c55 pipeline handler currently looks for a media entity with
the function MEDIA_ENT_F_IO_V4L to recognise a memory input subdevice.
This is apparently intended for video device entities, and we should
be looking for MEDIA_ENT_F_PROC_VIDEO_PIXEL_FORMATTER. Correct the
entity function that the pipeline handler looks for.
Signed-off-by: Daniel Scally <dan.scally@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Isaac Scott <isaac.scott@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
At the moment the mali-c55 pipeline handler sets bytesused for a
buffer to be the maximum possible size (i.e. the size of a struct
mali_c55_params_buffer). This is not really in keeping with the goal
of the extensible parameters formats, and will not work with the new
framework for those formats. Update the IPA module and pipeline
handler to set bytesused to the size of the parameters that were
actually supplied rather than the maximum possible size.
Signed-off-by: Daniel Scally <dan.scally@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Isaac Scott <isaac.scott@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Type casting from unsigned int to int performed in stats computation is
unnecessary, window_.width is unsigned and the array index is always
non-negative. Let's simply use unsigned int in all the
SwStatsCpu:stats* methods.
Signed-off-by: Milan Zamazal <mzamazal@redhat.com>
Reviewed-by: Umang Jain <uajain@igalia.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Here we update the digital gain handling to use the value computed by
process() in the AgcStatus, not the version that was previously in the
AgcPrepareStatus.
Because we apply this digital gain directly with no further
modification, we have to update it to reflect any exposure/gain
quantisation that happens (in IpaBase::applyAGC).
We must also run the new platformPrepareAgc() even when we're skipping
platformPrepareIsp(), which has been split out of the previous
platformPrepareIsp() implementation.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Previously we let prepare() do the work by comparing the desired total
exposure against the shutter time and analogue gain. This can cause
the image to "wink" at high framerates because we may skip running
prepare() to get the new digital gain even when the delayed AGC status
(which came out of an earlier call to process()) shows that a change
was required.
Now we're taking explicit control of the digital gain by calculating
it ourselves so that we can output it in the standard AgcStatus
object. This means that whenever the delayed AGC status changes, we
have the correct digital gain to go with it.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
The delay context counter must be advanced even when we decide not to
run prepare/process. Otherwise, when we skip them at higher
framerates, the current IPA context counter will catch up and
overwrite the delay context.
It's safe to advance the counter because the metadata is always copied
forward a slot when we decide not to run the IPAs.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Much of the time we use the term "analogue gain" where we really mean
the combined analogue and digital gain (because the digital gain will
make up whatever the analogue gain can't deliver).
This commit replaces the use of "analogue gain" by just "gain" in
places where we really mean the combined gain. There are a couple of
principle areas:
1. Where we previously talked about the "fixedAnalaogueGain"
(including setting it "manually") this is now just the "fixedGain"
(because it always encompassed both analogue and digital gain).
Along with this, the setfixedExposureTime/Gain functions no longer
update the output status directly. Applications should wait in the
usual way for AGC/AEC changes to take effect, and this "shortcut"
actually doesn't fit well with the gain being the combined gain.
2. The divideUpExposure method is adjusted to be clearer that it's
setting the combined gain, and it's prepare() that will discover later
what the analogue gain actually delivered.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Previously these were handled in the AGC/AEC exposure update
calculations by explicitly driving a higher digital gain to "cancel
out" any colour gains that were less than 1.
Now we're ignoring this in the AGC and leaving it to the IPA code to
normalise all the gains so that the smallest is 1. We don't regard
this as a "real" increase because one of the colour channels (just not
necessarily the green one) still gets the minimum gain possible.
We do, however, update the statistics calculations so that they
reflect any such digital gain increase, so that images are driven to
the correct level.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Per the b4 documentation: B4 is a tool created to make it easier for
project developers and maintainers to use a distributed development
workflow that relies on patches and distribution lists for code
contributions and review.
B4 is now a common tool used by developers for Linux kernel workflows.
While the Linux kernel support is handled inside b4, other projects can
rely on a .b4-config file to achieve the same thing.
Add a .b4-config file to instruct b4 to send patches to the
libcamera-devel mailing list. This allows the command b4 prep
--auto-to-cc to automatically add the mailing to its To: list.
Command output without .b4-config :
$ b4 prep --auto-to-cc
Collecting To/Cc addresses
No new addresses to add.
With .b4-config :
$ b4 prep --auto-to-cc
Collecting To/Cc addresses
+ To: libcamera-devel@lists.libcamera.org
---
You can trim/expand this list with: b4 prep --edit-cover
Invoking git-filter-repo to update the cover letter.
New history written in 0.02 seconds...
Completely finished after 0.04 seconds.
Signed-off-by: Benjamin Mugnier <benjamin.mugnier@foss.st.com>
Acked-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Instead of copying, just move the returned value when the call is made
through an argument pack. This enables, e.g. `Object::invokeMethod()`
to be usable with functions returning types, such as`std::unique_ptr`,
that have no copy ctor/assignment. Since there are no other users of
the argument pack object, this is safe to do. Reference return types
are not supported, so a simple `std::move()` is sufficient.
Bug: https://bugs.libcamera.org/show_bug.cgi?id=273#c1
Signed-off-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Exposure compensation allows to over- or under-expose an
image by a given value. Add support for that in agc_mean_luminance.
The added exposure compensation can lead to luminance target values that
are close or above saturation and are therefore never reachable. Add a
fix for that by limiting the maximum luminance target to 0.95.
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>
To debug color issues in a pipeline it is necessary to know the color
space used. Therefore add the color space to the string representation
of V4L2SubdeviceFormat that is returned by toString() and operator<<().
Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Isaac Scott <isaac.scott@ideasonboard.com>
Fix the eval() function for Pwls that contain only a single point.
Remove the should_fail from the corresponding test case.
Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Sometimes it is useful to have a Pwl with only a single point defined.
A practical use case is tuning files with only a single entry for Pwl
related parameters, where the expectation is that this entry just gets
used.
Add a failing test case for such a single point Pwl.
Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
If a Pwl is evaluated outside of the domain, it gets extrapolated
linearly. Fix the documentation as it states otherwise.
Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
