| Age | Commit message (Collapse) | Author |
|---|
|
When a request is given to a pipeline handler, it must parse the request
and identify what actions the pipeline handler should take to enact on hardware.
In the case of the VIVID pipeline handler, we identify the buffer from the only
supported stream, and queue it to the video capture device.
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
We can now add buffer management, and connect up our bufferReady signal
to a callback.
Note that we provide the ability to export buffers from our capture
device (data->video_) using the exportBuffers() functionality from the
V4L2VideoDevice which allows a FrameBufferAllocater to obtain buffers
from this device.
When buffers are obtained through the exportFrameBuffers API, they are
orphaned and left unassociated with the device, and must be reimported
at start() time anyway. This allows the same interface to be used
whether internal buffers, or external buffers are used for the stream.
When a buffer completes, we call the buffer completion handler on the
pipeline handler, and because we have only a single stream, we can also
immediately complete the request.
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
When the configurations have been generated and validated, they can be
applied to a device.
Vivid supports only a single stream, so it directly obtains the first
StreamConfiguration from the CameraConfiguration.
The VIVID catpure device is a V4L2Video device, so we generate a
V4L2DeviceFormat to apply directly to the capture device node.
Note that we convert the libcamera Format stored in
cfg.pixelFormat to a V4L2PixelFormat using V4L2PixelFormat helper. This
currently defaults to the single-planar formats, and should be extended
to support the Multiplanar configuration from the V4L2Device.
[todo Repair the link between the multiplanar configuration of the
V4L2VideoDevice and the pixel format selection]
Following the call to set the format using the Kernel API, if the format
has been adjusted in any way by the kernel driver, then we have failed
to correctly handle the validation stages, and thus the configure
operation is idendified has having failed.
Finally stream specific data can be directly stored and set as
reflecting the state of the stream.
[NOTE: the cfg.setStream() call here associates the stream to the
StreamConfiguration however that should quite likely be done as part of
the validation process. TBD]
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Implement the support for Generating and Validating the streams the
Camera can provide.
Vivid is a simple case with only a single stream.
Test the configurations can be generated and reported with cam -I:
"""
LIBCAMERA_LOG_LEVELS=Pipeline,VIVID:0 ./src/cam/cam -c 1 -I
[232:02:09.633067174] [2882911] INFO IPAManager ipa_manager.cpp:136 libcamera is not installed. Adding '/home//libcamera/build-vivid/src/ipa' to the IPA search path
[232:02:09.633332451] [2882911] WARN IPAManager ipa_manager.cpp:147 No IPA found in '/usr/local/lib/x86_64-linux-gnu/libcamera'
[232:02:09.633373414] [2882911] INFO Camera camera_manager.cpp:283 libcamera v0.0.11+714-d1ebd889-dirty
Using camera vivid
0: 1280x720-BGR888
* Pixelformat: NV21 (320x180)-(3840x2160)/(+0,+0)
- 320x180
- 640x360
- 640x480
- 1280x720
- 1920x1080
- 3840x2160
* Pixelformat: NV12 (320x180)-(3840x2160)/(+0,+0)
- 320x180
- 640x360
- 640x480
- 1280x720
- 1920x1080
- 3840x2160
* Pixelformat: BGRA8888 (320x180)-(3840x2160)/(+0,+0)
- 320x180
- 640x360
- 640x480
- 1280x720
- 1920x1080
- 3840x2160
* Pixelformat: RGBA8888 (320x180)-(3840x2160)/(+0,+0)
- 320x180
- 640x360
- 640x480
- 1280x720
- 1920x1080
- 3840x2160
"""
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Create a VividCameraData inheriting from the CameraData to handle camera
specific data, and use it to create and register the camera with the
CameraManager.
This can now be tested to see that the camera becomes available to
applications:
"""
LIBCAMERA_LOG_LEVELS=Pipeline,VIVID:0 ./src/cam/cam -l
[231:44:49.325333712] [2880028] INFO IPAManager ipa_manager.cpp:136 libcamera is not installed. Adding '/home/libcamera/build-vivid/src/ipa' to the IPA search path
[231:44:49.325428449] [2880028] WARN IPAManager ipa_manager.cpp:147 No IPA found in '/usr/local/lib/x86_64-linux-gnu/libcamera'
[231:44:49.325446253] [2880028] INFO Camera camera_manager.cpp:283 libcamera v0.0.11+713-d175334d-dirty
Available cameras:
1: vivid
"""
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Verify that we can match on our expected device(s).
Use a temporary debug print to check that the pipeline finds
our device:
"""
LIBCAMERA_LOG_LEVELS=Pipeline,VIVID:0 ./src/cam/cam -l
<snipped>
[230:51:10.670503423] [2872877] DEBUG VIVID vivid.cpp:81 Obtained Vivid Device
"""
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
To make sure we always build the Vivid pipeline in this branch,
explicitly add it to the pipelines build targets.
This is not any kind of best practice for pipeline handlers, but is here
to ensure that this pipeline is always compiled on this branch who's
sole purpose is to use and demonstrate the vivid pipeline handler.
|
|
Explicitly disable the unused-parameter warning in this pipeline handler.
Parameters are left unused while they are introduced incrementally, so for
documentation purposes only we disable this warning so that we can compile
each commit independently without breaking the flow of the development
additions.
This is not recommended practice within libcamera, please listen to your
compiler warnings.
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Provide all of the skeleton stubs to succesfully compile
and register a new Pipeline Handler for the Vivid test device.
Meson must be reconfigured to ensure that this pipeline handler is
included in the selected pipelines configuration, and after building, we
can test that the PipelineHandler is successfully registered by listing
the cameras on the system with LIBCAMERA_LOG_LEVELS enabled:
"""
LIBCAMERA_LOG_LEVELS=Pipeline:0 ./build-vivid/src/cam/cam -l
[230:30:03.624102821] [2867886] DEBUG Pipeline pipeline_handler.cpp:680 Registered pipeline handler "PipelineHandlerVivid"
Available cameras:
"""
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
This patch introduces support for applying runtime controls to software
ISP. It enables the contrast control as the first control that can be
used.
Signed-off-by: Milan Zamazal <mzamazal@redhat.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Software ISP is currently fully automatic and doesn't allow image
modifications by explicitly set control values. The user has no means
to make the image looking better.
This patch introduces support for contrast control, which can improve
e.g. a flat looking image. Based on the provided contrast value, it
applies a simple S-curve modification to the image.
The contrast algorithm just handles the provided values, while the
S-curve is applied in the gamma algorithm on the computed gamma curve
whenever the contrast value changes. Since the algorithm is applied
only on the lookup table already present, its overhead is negligible.
The contrast value range is 0..2 and corresponds to the whole range from
a completely flat contrast to an infinite contrast, 1.0 being the normal
value. This makes the user visible range intuitive and easy to use in
GUI sliders, while complying with Contrast control definition. There is
no unified range in the hardware pipelines, for example rkisp1 uses
0..1.993 range while rpi uses 0..10 range.
This is a preparation patch without actually providing the control
itself, which is done in the following patch.
Signed-off-by: Milan Zamazal <mzamazal@redhat.com>
Tested-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Let's have a constructor that takes just the non-default argument,
without the need to specify the defaults.
Signed-off-by: Milan Zamazal <mzamazal@redhat.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Let's have a constructor that takes just the non-default argument,
without the need to specify the defaults.
Signed-off-by: Milan Zamazal <mzamazal@redhat.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
If `cpp_debugstl` is enabled in the build configuration, then
libstdc++ will try to use `==` on operators in certain cases
to carry out extra checks. This leads to build failures because
`StringSplitter::iterator` has no `operator==`.
Implement `operator==`, and express `operator!=` in terms of it.
Signed-off-by: Barnabás Pőcze <pobrn@protonmail.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Inline some of the more trivial methods so that they can
be inlined by the compiler.
Signed-off-by: Barnabás Pőcze <pobrn@protonmail.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
It appears that the original intention was to use it in these
particular constructor tests: the variable is otherwise unused,
and `Span<const int>{ v }` is already tested.
Signed-off-by: Barnabás Pőcze <pobrn@protonmail.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
checkstyle.py will complain about cstdlib include, let's use stdlib.h
instead.
Signed-off-by: Milan Zamazal <mzamazal@redhat.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
On malformed yaml files, the yaml parser only errors out without giving
details on the error that happened. Fix that by providing a more detailed
error message.
Output old:
ERROR YamlParser yaml_parser.cpp:886 Failed to parse YAML content from /root/imx283.yaml
Output new:
ERROR YamlParser yaml_parser.cpp:627 /root/imx283.yaml:72:8 could not find expected ':' while scanning a simple key
ERROR YamlParser yaml_parser.cpp:886 Failed to parse YAML content from /root/imx283.yaml
Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
In d0478c41f432 ("libcamera: Rename "shutter speed" to "exposure time"")
the tuning file entry "shutter" was renamed to "exposure-time". As the
tuning files use camel cased key names, change "exposure-time" to
"exposureTime" for consistency. It doesn't break our users setups as
there are no tuning files using that entry in the wild (at least
officially).
Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com>
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Implement support for the ScalerCrop control that allows to apply a
digital zoom to the captured streams.
Initialize the camera controls at camera registration time and update
them at configure time as the sensor's analogue crop size might change
depending on the desired Camera configuration.
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Signed-off-by: Daniel Scally <dan.scally@ideasonboard.com>
|
|
The Mali C55 ISP has a resizing pipeline that allows to crop and scale
images.
So far the mali-c55 pipeline has only supported cropping without using
the scaling functionalities.
Now that the kernel has gained support for the scaling operations, make
the libcamera pipeline use it by combining it with a first cropping step
to align the input and output images FOV ratio, and then scale to the
desired output size.
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Signed-off-by: Daniel Scally <dan.scally@ideasonboard.com>
|
|
The mali-c55 driver now expects links to video devices to be enabled
in order for those devices to be streamed from / to. Enable the media
link between the resizers and their associated video device to fulfil
the requirement.
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Daniel Scally <dan.scally@ideasonboard.com>
|
|
At present we configure raw streams by looping through the pixel
formats we support and finding one with an associated media bus
format code that the sensor can produce. In the new representation
of raw data from the kernel driver this will not work - the sensor
could produce 8, 10, 12, 14 or 16 bit data and the ISP will force
it to RAW16, which is the only actually supported output.
To fix the issue move to simply finding a pixel format with a bayer
order that matches that of the media bus format produced by the
sensor. If the sensor can produce multiple formats with the same
bayer order use the one with the largest bitdepth.
Finally, remove the claim to support RAW formats of less than 16 bits.
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Daniel Scally <dan.scally@ideasonboard.com>
|
|
The latest version of the Mali C55 driver has changed the format
accepted by the ISP sink pad to be the 20-bit wide.
The CSI-2 receiver handles the format expansion internally by
propagating the sensor produced format from its sink to the 20-bit
expanded version on its source pad.
Instead of re-applying the sensor format to the CSI-2 receiver source
pad (which is now an invalid operation) read from there the format
propagated by the driver internally and further propagate it to the ISP
subdevice.
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Signed-off-by: Daniel Scally <dan.scally@ideasonboard.com>
|
|
Add support for the 20-bit bayer formats to libcamera's BayerFormat class.
Signed-off-by: Daniel Scally <dan.scally@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Add support in the mediaBusFormatInfo map in the v4l2-subdevice.c file
for the media bus formats used by the Mali C55 ISP.
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Signed-off-by: Daniel Scally <dan.scally@ideasonboard.com>
|
|
Add media bus codes introduced by the Mali C55 ISP support to describe
the 20-bit input formats supported by the ISP. This manual addition is
a temporary measure until the kernel driver changes are merged, from
which point this will be managed through the usual merge of the upstream
kernel headers.
Add the following formats
- MEDIA_BUS_FMT_RGB202020_1X60
for processed input formats
https://lore.kernel.org/linux-media/20241106100534.768400-2-dan.scally@ideasonboard.com/
- MEDIA_BUS_FMT_SBGGR20_1X20
MEDIA_BUS_FMT_SGBRG20_1X20
MEDIA_BUS_FMT_SGRBG20_1X20
MEDIA_BUS_FMT_SRGGB20_1X20
for the RAW bayer input format
https://lore.kernel.org/linux-media/20241106100534.768400-3-dan.scally@ideasonboard.com/
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Signed-off-by: Daniel Scally <dan.scally@ideasonboard.com>
|
|
Complete the RAW StreamConfiguration by populating the frame stride and
the frame size.
Set the minimum required alignment to 4 bytes as the Mali C55 ISP output
expands RAW output to 16 bits and a RAW Bayer macro-pixel requires
two samples to be complete.
Signed-off-by: Daniel Scally <dan.scally@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
The MaliC55CameraData::mbusCodes() function is unused. Remove it.
Signed-off-by: Daniel Scally <dan.scally@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The PipelineHandler::completeBuffer() base class function returns
a boolean to indicate if there still are pending buffers in the
Request.
Simplify the bufferReady() function in the Mali-C55 pipeline handler
using the completeBuffer() return value.
Signed-off-by: Daniel Scally <dan.scally@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Initialise the camera properties using the CameraSensor properties.
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Signed-off-by: Daniel Scally <dan.scally@ideasonboard.com>
|
|
The Mali-C55 ISP has a minimum input size limit of 640x480.
Filter out resolutions smaller than this when selecting the
sensor format. While at it, rename 'maxYuvSize' to a more
appropriate 'minSensorSize'.
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Signed-off-by: Daniel Scally <dan.scally@ideasonboard.com>
|
|
The Mali C55 ISP cannot upscale. The maximum allowed output size
is the sensor's resolution.
For RAW streams this is already handled in adjustRawSizes(), while
for processed streams the maximum allowed resolution was wrongly
set to the ISP maximum output size (8192x8192).
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Signed-off-by: Daniel Scally <dan.scally@ideasonboard.com>
|
|
There are no users of the libipa::Matrix class anymore. Drop it.
Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Use the Matrix class from libcamera/internal in the rkisp IPA so that
the libipa one can be dropped later.
Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Use the Matrix class from libcamera/internal in libipa so that the one
from libipa can be dropped later.
Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The RaspberryPi IPA contains a private Matrix3x3 class inside the ccm
algorithm. Replace it with the Matrix class available in
libcamera/internal.
While at it, mark the matrices RGB2Y and Y2RGB as static const.
Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Naushir Patuck <naush@raspberrypi.com>
|
|
Add the new Matrix class to the build.
Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The Matrix constructor that takes a std::vector is meant and only used
to initialize a Matrix from an initializer list. Using a std::vector is
problematic for two reasons. First, it requires constructing a vector,
copying the data from the initializer list, which is an expensive
operation. Then, the vector size can't be verified at compile time,
making the constructor unsafe.
The first issue could be solved by replacing the vector with a
std::initializer_list or a Span. The second issue would require checking
the initializer list size with a static assertion, or restricting usage
of the constructor to fixed-extent spans. Unfortunately, even if the
size of initializer lists is always known at compile time, the
std::initializer_list::size() function is a compile-time constant only
for constant initializer lists. Using a span would work better, but
construction of a fixed extent span from an initializer list must be
explicit, making the API cumbersome.
We can solve all those issues by passing an std::array to the
constructor. Construction of an array from an initializer list can be
implicit and doesn't involve a copy, and the array size is a template
parameter and therefore guaranteed to be a compile-time constant.
Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The Matrix class no longer lives inside lipipa. Move it into the
libcamera namespace to account for that.
Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
In preparation to moving the matrix implementation from libipa to
libcamera copy the corresponding files to the new location. The files
are copied without modification to make upcoming integration changes
easier to see. The new files are not included in the build and therefore
have no negative side effects on the build.
Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The upcoming patches will introduce a Matrix class into
libcamera/internal. That name clashes with the Matrix class from the
RaspberryPi ccm implementation. Rename the rpi version to Matrix3x3 to
prevent the name clash. Matrix3x3 will be replaced by the generic
implementation later.
Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The black level obtained from the tuning file in software ISP is
retrieved in init (because this is the standard algorithm method with
access to tuning data) and stored into context. But the context gets
reset in configure and the black level is lost and never applied.
Let's store the black level from the tuning file into an algorithm
instance variable and put it into the context only later in configure.
This is similar to what rkisp1 IPA does with the values obtained from
the tuning file.
Fixes: 41e3d61c745153779ed5a38634d7266bffd60d61 ("libcamera: software_isp: Clear IPA context on configure and stop")
Signed-off-by: Milan Zamazal <mzamazal@redhat.com>
Tested-by: Robert Mader <robert.mader@collabora.com>
Reviewed-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
In order to remove redundant camera ID lookups and comparisons switch
to pointer-based checks when choosing and switching cameras.
Co-developed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
Tested-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Now agc struct in IPAActiveState is not used any longer. If there
will be need to have this struct, this patch can be reverted.
Signed-off-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
Reviewed-by: Milan Zamazal <mzamazal@redhat.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
On my setup, since commit fb8ad13d ("libcamera: software_isp: Move exposure+gain
to an algorithm module"), at start camera output stays very dark for dozen
of seconds, and then later slowly gets to normal. This is because existing
sensor exposure+gain settings are not used at start. We save initial
values in frameContext but in the agc algorithm we use IPA context.
Fix the problem by using in frameContext sensor values, since we already
use those in blc algorithm and change exposure type to int32_t to
unnecessary castings.
Signed-off-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
Reviewed-by: Milan Zamazal <mzamazal@redhat.com>
Tested-by: Robert Mader <robert.mader@collabora.com>
Tested-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Provide the GalaxyCore gc08a3 camera sensor properties and registration
with libipa for the gain code helpers.
Signed-off-by: Han-Lin Chen <hanlinchen@chromium.org>
Co-developed-by: Xing Gu <xinggu@chromium.org>
Signed-off-by: Xing Gu <xinggu@chromium.org>
Co-developed-by: Yudhistira Erlandinata <yerlandinata@chromium.org>
Signed-off-by: Yudhistira Erlandinata <yerlandinata@chromium.org>
Co-developed-by: Harvey Yang <chenghaoyang@chromium.org>
Signed-off-by: Harvey Yang <chenghaoyang@chromium.org>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Provide the GalaxyCore gc05a2 camera sensor properties and registration
with libipa for the gain code helpers.
Signed-off-by: Han-Lin Chen <hanlinchen@chromium.org>
Co-developed-by: Xing Gu <xinggu@chromium.org>
Signed-off-by: Xing Gu <xinggu@chromium.org>
Co-developed-by: Yudhistira Erlandinata <yerlandinata@chromium.org>
Signed-off-by: Yudhistira Erlandinata <yerlandinata@chromium.org>
Co-developed-by: Harvey Yang <chenghaoyang@chromium.org>
Signed-off-by: Harvey Yang <chenghaoyang@chromium.org>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Add method to set thread affinity to Thread class.
Signed-off-by: Han-Lin Chen <hanlinchen@chromium.org>
Co-developed-by: Harvey Yang <chenghaoyang@chromium.org>
Signed-off-by: Harvey Yang <chenghaoyang@chromium.org>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
V4L2 Controls support a wide variety of types not yet supported by the
ControlValue type system.
Extend the libcamera ControlValue types to support an explicit 16 bit
unsigned integer type, and map that to the corresponding
V4L2_CTRL_TYPE_U16 type within the v4l2_device support class.
It's used on some camera metadata that is of length 16-bits,
for example JPEG metadata headers.
Signed-off-by: Yudhistira Erlandinata <yerlandinata@chromium.org>
Co-developed-by: Harvey Yang <chenghaoyang@chromium.org>
Signed-off-by: Harvey Yang <chenghaoyang@chromium.org>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
