Sharpening is reduced slightly for official Raspberry Pi cameras, and
exposure profiles made a bit more consistent.
Denoise is reduced for the imx708 where it appears too strong.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Noise and detail tuning is improved for all official Raspberry Pi
cameras.
The old tunings left too much noise in and even sharpened some of
it. The new tunings remove more noise, and no longer sharpen it. Some
of the more general over-sharpening is also removed. Note that lost
detail can be recovered well using TDN (temporal denoise), which is
the recommended method to get the best results.
There are some minor adjustments to the CDN deviation, now that this
gets backed-off as TDN ramps up.
The contrast in the gamma in the bright areas is also toned down just
a little.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
The CDN (colour denoise) deviation gets gradually reduced frame by
frame as TDN (temporal denoise) comes in and has more effect. CDN is
more harmful to image detail than TDN, so ramping it down in favour of
TDN is beneficial.
The tuning file parameters are chosen so that existing tuning files
don't have to be updated and will carry on working "mostly like they
did" (apart from the new back-off).
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Add an imx415 tuning file for both the VC4 and PiSP. This tuning file
has been created and supplied by Arducam to support the B0569 module.
Note that this conflicts with an already existing imx415.json and
as such is provided as imx415_b0459.json.
More work will be required to support module specific tuning file
parsing.
Acked-by: Naushir Patuck <naush@raspberrypi.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Add an imx335 tuning file for both VC4 and PiSP. This tuning file
has been created and supplied by Arducam to support the B0568 module.
Acked-by: Naushir Patuck <naush@raspberrypi.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
In current implementation, the sink pad counter of the crossbar is not
incremented if the pad is not connected to any subdevice. This would lead
to incorrect routing and format configuration if CSI is not connected
to first sink pad.
To avoid such issue, every sink pads must be taken into account. Then if
CSI and sensor are present, current counter is used for routing at match(),
and stored in camera data to be reused during configure().
Signed-off-by: Antoine Bouyer <antoine.bouyer@nxp.com>
Tested-by: Pavel Löbl <pavel@loebl.cz>
Tested-by: Julien Vuillaumier <julien.vuillaumier@nxp.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
libcamera uses the meson python module to handle native compilation of
Python extension modules, and uses the shared_module() function when
cross-compiling due to an issue in the python module. The difference
between native and cross compilation also extends to the installation
path: native compilation lets the python module handle the paths, while
cross compilation constructs a path manually using a heuristic based on
the Python version and hardcoded components.
This manually-constructed installation path is problematic for cross
compilation for the same reason it caused issue when used for native
compilation: it is not guaranteed to be right, and it can't be
overridden by users.
Switch to obtaining the installation path from the meson python module
for cross-compilation as well. This also prepares for usage of
py.extension_module() once the file suffix issue will be fixed in meson.
On Debian 13, this change replaces the incorrect path
/usr/local/lib/python3.12/site-packages/libcamera with the still (but
differently) incorrect /usr/local/lib/python3/dist-packages/libcamera.
Future fixes in meson to address this issue will make the path correct
by default.
When the path calculated by the python module is not correct, it can now
be overridden by the user through the meson python.platlibdir
configuration variable.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
libcamera uses the meson python module to handle native compilation of
Python extension modules.
When cross-compiling, the module uses the build machine suffix instead
of the host machine suffix in some enviroments (for instance naming the
shared object file _libcamera.cpython-313-x86_64-linux-gnu.so instead of
_libcamera.cpython-313-aarch64-linux-gnu.so when cross-compiling from
x86_64 to aarch64). This prevents using the python module in that case,
and libcamera uses the normal dependency() function to locate the Python
libraries, and the shared_module() function to build the module.
Not using the meson python module to get the Python dependency prevents
selecting a specific Python interpreter, the same way as it does for
native builds. While having multiple Python interpreter versions in a
cross-build environment is likely less common, different behaviours and
features between native and cross-compilation are still not optimal.
Improve this situation by getting the dependency from the python module
for cross-compilation as well. This also prepares for usage of
py.extension_module() once the file suffix issue will be fixed in meson.
The user will need to ensure that the Python interpreter for the build
machine matches the version of the interpreter in the cross-compilation
environment for the host machine. Otherwise, meson will fail to find the
Python dependency. Cross-compilation environment provided by Linux
distributions (such as Debian multi-arch support) should work out of the
box, but compiling libcamera manually against a cross-compilation
environment provided by Buildroot or Yocto may require manual
configuration.
When the interpreters versions do not match, meson needs to be pointed
to the build ùachine interpreter from the cross-compilation environment
using the cross file. For instance, assuming a 'br_host_dir' variable
pointing to the host directory from Buildroot, the cross file should
contain
[binaries]
python = br_host_dir / 'bin/python3'
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
The existing meson.build file installs the bindings to a manually
constructed directory that is not included in the Python path in most
distributions. For instance, on a Debian 12 system, the modules is
intalled in /usr/lib/x86_64-linux-gnu/python3.11/site-packages/, while
the Python interpreter looks for site packages in
/usr/lib/python3/dist-packages/.
It also always builds the bindings using the system Python, as it
searches for the Python library using the standard dependency()
function. This prevents build the Python bindings for a different
interpreter version without changing the system default interpreter.
Modify the build process to use the meson python module to build the
Python bindings targets, so it installs them to the correct directories
for Python. This also allows specifying a different target Python
interpreter through the '[binaries]' section of a meson native file.
The behaviour is not changed for cross-compilation, as the meson python
module has known issues in that case.
Signed-off-by: William Vinnicombe <william.vinnicombe@raspberrypi.com>
Co-developed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
The planes variable in the Device::createFrameBuffer() function is a
reference to buffer.planes() that is only used as a range initializer in
a range-based for loop. Use buffer.planes() directly and drop the
variable.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
If `addModel` is true, then the previously set `name` will be overwritten.
This does not seem to be the intended behaviour, so fix it by using `+=`.
Before:
Available cameras:
1: 'imx219' (/base/soc@0/bus@30800000/i2c@30a30000/camera@10)
After:
Available cameras:
1: External camera 'imx219' (/base/soc@0/bus@30800000/i2c@30a30000/camera@10)
Fixes: aab49f903e ("cam: Do not assume Location is available")
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>
In `Semaphore::release()`, unlocking the mutex before signalling the condition
variable can be problematic, especially with "temporary" objects such as the
ones `BoundMethodBase::activatePack()` uses to handle `ConnectionTypeBlocking`.
Specifically, `Semaphore::acquire()` might lock the mutex after `Semaphore::release()`
has unlocked it, but before it had the chance to notify the condition variable.
In that case `Semaphore::acquire()` can succeed, and execution may proceed to
destroy the `Semaphore` object while the other thread is in the process of
running `std::condition_variable::notify_all()`.
Bug: https://bugs.libcamera.org/show_bug.cgi?id=225
Fixes: 66e7c5b774 ("libcamera: Add Semaphore class")
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>
The function is not actually thread safe contrary to its documentation.
Since it is currently not used in an unsafe context, simply remove the
mention of thread safety from the documentation.
The variable must still remain atomic because it is accessed internally
from different threads, e.g. `Thread::postMessage()`.
Also add an assertion to enforce this.
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>
It is often helpful to know which tuning file is used. Add a log
statement with INFO level for that.
As the core logic has multiple return paths, adding the log statement is
not straight forward. Extract finder logic into a ipaConfigurationFile()
function and call that with the name and optionally the fallbackName
from the configurationFile() function.
Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com>
There is no reason to allocate the frame info objects dynamically,
and then store raw pointers in the `std::map` in the rkisp1
and ipu3 pipeline handler.
Instead, store the objects directly in the map. This removes
the need for manually calling new/delete, simplifies the code,
and eliminates one memory allocation per frame.
Signed-off-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Top-level `const` qualifiers are not useful, so avoid them. This is done
either by simply removing the top-level `const`, or making the function
return a reference to const where that is appropriate.
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>
This reverts commit 10cdc914da.
The constructors introduced by that commit are not used anywhere,
and they do not match the existing practice for boolean controls.
Specifically, every single boolean control is described by calling
the `ControlInfo(ControlValue, ControlValue, ControlValue)`
constructor. Crucially, that constructor does not set `values_`,
while the two removed constructors do. And whether or not `values_`
has any elements is currently used as an implicit sign to decide
whether or not the control is "enum-like", and those are assumed
to have type `int32_t`.
For example, any boolean control described using any of the two
removed constructors would cause an assertion in failure in
`CameraSession::listControls()` when calling `value.get<int32_t>()`.
Signed-off-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Stefan Klug <stefan.klug@ideasonboard.com>
Iterate over all libcamera camera properties and report them as
device properties. Each libcamera ControlType is mapped to the
corresponding gstreamer GType. If the ControlValue is an array of
values (ControlValue::isArray()), GValue with type GST_TYPE_ARRAY
is used to set the value of that ControlValue with the corresponding
GType.
Signed-off-by: Umang Jain <uajain@igalia.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Move the existing GValue helpers from gstlibcamera-controls.cpp.in
to gstreamer-utils.cpp. The intention here is to make these helpers
available to other parts of gstreamer source element, for example,
reporting camera properties in GstDeviceProvider.
The function signature has been changed to match with the other
gstreamer-utils utility functions:
value_get_rectangle() => gst_libcamera_gvalue_get_rectangle()
value_set_rectangle() => gst_libcamera_gvalue_set_rectangle()
value_set_point() => gst_libcamera_gvalue_set_point()
value_set_size() => gst_libcamera_gvalue_set_size()
Signed-off-by: Umang Jain <uajain@igalia.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Split the value_set_rectangle() GValue helper into further
helpers pertaining to libcamera::Point and libcamera::Size.
This would help to cover additional cases where helpers
are needed for Point and Size individually (in subsequent commits).
The libcamera::Rectangle's GValue helper can be easily
constructed with the new Point and Size helpers. Hence,
this patch does not introduce any functional changes.
Signed-off-by: Umang Jain <uajain@igalia.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
For both vc4 and pisp, vd56g3.json has been generated using ctt with
rpi.dpc algorithm removed as this is already handled in the sensor's
ISP. vd56g3_mono.json has been adapted from vd56g3.json by removing
color correction related algorithms.
Adding Cyril Liotard and Jean Poire as co-developers for providing the
base vd56g3.json tuning files for vc4 and pisp respectively. Thank you.
Signed-off-by: Benjamin Mugnier <benjamin.mugnier@foss.st.com>
Co-developed-by: Cyril Liotard <cyril.liotard@st.com>
Signed-off-by: Cyril Liotard <cyril.liotard@st.com>
Co-developed-by: Jean Poire <jean.poire@st.com>
Signed-off-by: Jean Poire <jean.poire@st.com>
Reviewed-by: Naushir Patuck <naush@rasbperrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Add unit cell size from the 'pixel size' element in the datasheet.
Delays are set to 2 in case a setting is entered at the very end of the
N frame, the N+1 frame will miss it and only the N+2 frame will use this
new setting.
Note that vd56g3 has a diagonal color test pattern, but does not match
any description in specified test patterns and therefore is ignored.
Signed-off-by: Benjamin Mugnier <benjamin.mugnier@foss.st.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
The `ProcessManager` is a singleton class to handle `SIGCHLD` signals
and report the exit status to the particular `Process` instance.
However, having a singleton in a library is not favourable and it is
even less favourable if it installs a signal handler.
Using pidfd it is possible to avoid the need for the signal handler;
and the `Process` objects can watch their pidfd themselves, eliminating
the need for the `ProcessManager` class altogether.
`P_PIDFD` for `waitid()` was introduced in Linux 5.4, so this change
raises the minimum supported kernel version. `clone3()`, `CLONE_PIDFD`,
`pidfd_send_signal()` were all introduced earlier.
Furthermore, the call to the `unshare()` system call can be removed
as those options can be passed to `clone3()` directly.
Signed-off-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Instead of creating a new vector, take the vector by value to make it
possible for the caller to use move construction when calling the function.
Signed-off-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Instead of using a separate member variable, use `pid_ > 0` to determine
if the process is still running. Previously the value of `pid_` was not
reset to -1 when the process terminated, but since it is only meaningful
while the process is running, reset it to -1 in `Process::died()`.
Neither `pid_` nor `running_` are exposed, so this change has no effect
on the public interface or observable behaviour.
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>
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>
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>
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>
