| 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>
|
|
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>
|
|
The algorithm computes R/G and B/G colour ratio statistics which we
should not allow to go to zero because there is clearly no gain you
could apply to R or B to equalise them. Instead flag such regions as
having "insufficient data" in the normal manner.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
This commit implements EOS handling for events sent to the libcamerasrc
element by the send_event method (which can happen when pressing
Ctrl-C while running gst-launch-1.0 -e, see below). EOS events from
downstream elements returning GST_FLOW_EOS are not considered here.
To archive this add a function for the send_event method which handles
the GST_EVENT_EOS event. This function will set an atomic to the
received event and push this EOS event to all source pads in the running
task.
Also set the GST_ELEMENT_FLAG_SOURCE flag to identify libcamerasrc as a
source element which enables it to receive EOS events sent to the
(pipeline) bin containing it. This in turn enables libcamerasrc
to receive EOS events, for example, from gst-launch-1.0 with
the -e (--eos-on-shutdown) flag applied.
Bug: https://bugs.libcamera.org/show_bug.cgi?id=91
Signed-off-by: Jaslo Ziska <jaslo@ziska.de>
Acked-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
Add a bunch of logging messages that have come in handy debugging
various issues with the pipeline handler code.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Correct a crash in CameraSensor::init() when trying to set the
V4L2_CID_HBLANK control on sensor not implementing this control. The
HBLANK sensor not being mandatory for non-RAW sensors, it can happen
that the sensor does not expose this control. Perform check against
availability of the control prior to usage in order to avoid the crash.
Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
If no ISP output streams are configured, the ISP output count is skipped
for the the low res stream, and causes the drop frame logic to fail
because of a count mismatch. This in-turn stops any requests from
completing correctly.
Fix this by ensuring the low res output is counted correctly when no ISP
output streams are configured.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The entityControls variable is unused, remove it.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
We add an HdrMode control (to enable and disable HDR processing)
and an HdrChannel, which indicates what kind of HDR frame (short, long
or medium) has just arrived.
Currently the HdrMode supports the following values:
* Off - no HDR processing at all.
* MultiExposureUnmerged - frames at multiple different exposures are
produced, but not merged together. They are returned "as is".
* MultiExposure - frames at multiple different exposures are merged
to create HDR images.
* SingleExposure - multiple frames all at the same exposure are
merged to create HDR images.
* Night - multiple frames will be combined to create "night mode"
images.
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>
|
|
We need to be able to do things like enable/disable AGC for all the
channels, so most of the AGC controls are updated to be applied to all
channels. There are a couple of exceptions, such as setting explicit
shutter/gain values, which apply only to channel 0.
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>
|
|
AWB writes this out during prepare, so we may as well read it in AGC
prepare as well. Reading it in process is wrong on the PiSP platform
because process runs before prepare, so the AWB status won't be there
(on vc4 it made no difference).
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>
|
|
Since noise control handling differs between the VC4 and PiSP IPAs,
move the current denoise control handler from ipa base into the vc4 IPA
derived class.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
"Fast desaturation" is a technique that can help the AGC algorithm to
desaturate images more quickly when they are very
over-exposed. However, it uses digital gain to do this which can
confuse our HDR techniques. Therefore make it optional.
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>
|
|
This was being re-read in order to determine what LSC gains had been
applied. We can just retrieve these numbers from the prevAsyncResults_
instead.
This will also enable other future algorithms to manipulate the LSC
tables in the alsc.status, without it breaking the core ALSC algorithm
here.
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>
|
|
We can perform some of the local contrast adjustment using global
gains in the LSC table. We can vary the amount of gain according to
the measured brightness of that image region.
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>
|
|
Now that the transformFromOrientation() function isn't used outside of
transform.cpp, make it static to remove it from the public API.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
|
|
The transformToOrientation() function is called from
Orientation operator*(const Orientation &o, const Transform &t);
only. Fold the code in the caller and drop the transformToOrientation()
function to drop what can be considered as an ill-defined operation from
the API.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
|
|
The cached rotationTransform_ value is used in computeTransform() only,
to compute the mounting orientation. Cache the mounting orientation
instead, removing the need for the intermediate conversion of the
rotation to a transform.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
|
|
Add a '--orientation|-o' option to the Python version of the cam test
application to set an orientation to the image stream.
Supported values are:
- rot0: no rotation
- rot180: rotate 180 degrees
- flip: vertical flip
- mirror: horizontal flip
Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Add a '--orientation|-o' option to the cam test application to set
an orientation to the image stream.
Supported values are the ones obtained by applying flips to the camera
sensor:
- rot0: no rotation
- rot180: rotate 180 degrees
- flip: vertical flip
- mirror: horizontal flip
Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Replace the usage of CameraConfiguration::transform with the newly
introduced CameraConfiguration::orientation.
Rework and rename the CameraSensor::validateTransform(transform) to
CameraSensor::computeTransform(orientation), that given the desired
image orientation computes the Transform that pipeline handlers should
apply to the sensor to obtain it.
Port all pipeline handlers to use the newly introduced function.
This commit breaks existing applications as it removes the public
CameraConfiguration::transform in favour of
CameraConfiguration::orientation.
Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Define an enumeration type for Orientation and expose the
CameraConfiguration::orientation property in place of
CameraConfiguration::transform.
Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Add two operations that allows to combine Transform with Orientation.
- Transform operator/(const Orientation &o1, const Orientation &o2)
allows to easily get back the Transform that needs to be applied to
Orientation2 to get Orientation1
- Orientation operator*(const Orientation &o, const Transform &t)
allows to apply a Transform to an Orientation and obtain the
combination of the two
These two operations allow applications to use Transforms to
manipulate the Orientation inside the CameraConfiguration, if they
wish.
Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The current definition of operator*(Transform t1, Transform t0) follows
the function composition notion, where t0 is applied first then t1 is
applied last.
In order to introduce operator*(Orientation, Transform) where a
Transform is applied on top of an Orientation, invert the operand order
of operator*(Transform, Transform) so that usage of operator* with both
Orientation and Transform can be made associative.
For example:
Orientation o;
Transform t = t1 * t2
Orientation o1 = o * t
= o * (t1 * t2) = (o * t1) * t2 = o * t1 * t2
Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Add two helper functions to the transform.cpp file that allows to
convert to and from an Orientation.
Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Specify in the documentation that properties::Rotation specifies the
mounting rotation of the camera module. This avoids confusion with the
image orientation which is instead expressed by
CameraConfiguration::orientation.
For this reason, do not compensate the Rotation property when
initializing the CameraSensor class but report the value of
V4L2_CID_CAMERA_SENSOR_ROTATION or 0 if the control is not available.
Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.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 figures in Documentation/rotation/ to document the plane
transformations defined by the Orientation enumeration.
Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Introduce the Orientation enumeration which describes the possible 2D
transformations that can be applied to an image using two basic plane
transformations.
Add to the CameraConfiguration class a new member 'orientation' which is
used to specify the image orientation in the memory buffers delivered to
applications.
The enumeration values follow the ones defined by the EXIF specification at
revision 2.32, Tag 274 'orientation'.
The newly introduced field is meant to replace
CameraConfiguration::transform which is not removed yet not to break
compilation.
Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The rotationTransform_ depends on a V4L2 control whose value does not
change for the whole lifetime of the camera.
Instead of re-calculating it everytime the camera is configured, cache
it at properties initialization time.
Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Qt supports RGB565 natively; add support for the format by mapping
the libcamera format to Qt's representation of it.
Signed-off-by: Daniel Scally <dan.scally@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
If the pipeline runs out of embedded data buffers, then it will pass
the frame to the IPA without the metadata. The IPA then has to use the
delayed controls as inputs to the algorithms. This can cause problems
with the subsequent algorithms if the sensor did not action the
controls, especially with the autofocus as that doesn't have controls
which can be passed in lieu of the metadata.
Reduce the likelihood of this by increasing the number of embedded data
buffers, as they are small so a generous number can be allocated.
Signed-off-by: William Vinnicombe <william.vinnicombe@raspberrypi.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Whenever the AGC active channels are changed, start with the first
channel listed. This allows applications to rely on a particular channel
being generated first. For example, multi-exposure HDR always wants the
short channel first.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The code was inadvertently overwriting the caller's StatisticsPtr,
meaning that subsequent algorithms would get the wrong image
statistics when AGC channels changed.
This could be fix using std::ref, though I find the C-style pointer
fix easier to understand!
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Some use cases may require stronger, or different, denosie settings to
others. For example, the way frames are accumulated during single
exposure HDR means that we may want stronger denoise.
This commit adds such support for different configurations that can be
defined in the tuning file.
Older tuning files, or files where there is only a single
configuration, load only the "normal" denoise configuration.
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 enableCe() function enables or disables adaptive contrast
enhancement and the restoreCe() function sets it back to its normal
state (which is what was read from the tuning file).
In future, algorithms like HDR might want to take over tonemapping
functions, so any dynamic behaviour here would upset them.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Add a small "stable region" parameter (defaulting to 2%) within which
the AGC will not adjust the exposure it requests. It allows
applications to configure the AGC to avoid continual micro-adjustments
of exposure values if they are somehow sensitive to it.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
This allows them to be accessed by the pipeline handlers when needed.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Move the handling of Bayer order changes due to flips to run before
platformValidate(). This removes the need for this code to be split
between platformValidate() and validate() as it is right now.
Also add some validation to ensure the vc4 pipeline handler only
supports CSI2 packing or no packing.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Record if additional software downscaling is needed for a particular
stream in the RPi::Stream class. Additional software downscaling may be
needed if the user required downscale factor is greater than what the
ISP hardware is capable of.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Add new CAC, HDR, Saturation and Tonemapping algorithms.
Add a new Denoise algorithm that handles spatial/temporal/colour denoise
through one interface. With this change, the old SDN algorithm is now
considered deprecated and a warning message will be displayed if it is
enabled.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Prepare the AWB algorithm to support the PiSP hardware. The key change
is to factor in the LS correction in the AWB zone statistics. This is
different from VC4 where the LS correction happens before statistics
gathering.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Prepare the ALSC algorithm to support the PiSP hardware. The key change
is to avoid factoring out the WB correction in the AWB zone statistics.
Add the ALSC correction to the global metadata so that AWB can use it to
factor the gains back in for the AWB calculations.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Add an entry to Controller::HardwareConfig describing the PiSP hardware
for the IPA and controller algorithms to use.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Add a new boolean field (statsInline) to Controller::HardwareConfigMap.
This field indicates where the statistics are generated in the hardware
ISP pipeline. For statsInline == true, statistics are generated before
the frame is processed (e.g. the PiSP case), and statsInline == false
indicates statistics are generated after the frame is processed (e.g.
the VC4 case).
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
