| Age | Commit message (Collapse) | Author |
|---|
|
These specific controls are part of the sensor device, so rename them
appropriately.
Signed-off-by: Naushir Patuck <naush@raspberrypi.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>
|
|
Replace manual resource destruction with std::unique_ptr<> where
applicable. This removes the need for several destructors.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
Replace manual construction of V4L2VideoDevice and V4L2Subdevide with
the fromEntityName() helper where possible. The returned pointer is
managed as a std::unique_ptr<>, which simplifies the VimcCameraData
destructor.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
The CameraSensor instance stored in RPiCameraData::sensor_ is allocated
dynamically and never deleted. Fix the memory leak by storing it in a
std::unique_ptr<>.
Fixes: 740fd1b62f67 ("libcamera: pipeline: Raspberry Pi pipeline handler")
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
C++17 has a std::size() function that returns the size of a C-style
array. Use it instead of the custom ARRAY_SIZE macro.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Umang Jain <email@uajain.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The auto keyword facilitates writing code. It avoids typing out very
long types, which can make the code more readable, but it can also have
a negative impact on readability as it requires the reader (including
reviewers) to look up the type of the variable.
Replace one occurrence of auto with the explicit type where doing so
doesn't require a long type name.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The ChromeOS camera service, which is the current main user of the
Android Camera HAL, fails to start if the pixel array properties are
not registered.
As the sensor driver for the Soraka test device have not yet been
updated to report their pixel array properties through the V4L2
selection API, temporary fix the gap by re-establishing the default
properties values removed by commit 1889cdc2e91c ("android: camera_device:
Initialize pixel array properties")
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Previously the CamHelper was returning the number of frames to drop
(on account of AGC/AWB converging). This wasn't really appropriate,
it's better for the algorithms to do it as they know how many frames
they might need.
The CamHelper::HideFramesStartup method should now just be returning
the number of frames to hide because they're bad/invalid in some way,
not worrying about the AGC/AWB. For many sensors, the correct value
for this is zero. But the ov5647 needs updating as it must return 2.
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>
|
|
colour gains
When the AWB is started from "cold" with fixed colour gains, we try to
estimate the colour temperature this corresponds to (if a calibrated
CT curve was supplied). When fixed colour gains are set after the AWB
has been running, we leave the CT estimate alone, as the one we have
is probably sensible.
This estimated colour is passed out in the metadata for other
algorithms - notably ALSC - to use.
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>
|
|
Add a method to the piecewise linear function (Pwl) class to compute
the inverse of a given Pwl. If the input function is non-monotonic we
can only produce a best effort "pseudo" inverse, and we signal this to
the caller.
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 add a GetConvergenceFrames method to the AwbAlgorithm class which
can be called when the AWB is started from scratch. It suggests how
many frames should be dropped before displaying any (while the AWB
converges).
The Raspberry Pi specific implementation makes this customisable from
the tuning file.
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 add a GetConvergenceFrames method to the AgcAlgorithm class which
can be called when the AGC is started from scratch. It suggests how
many frames should be dropped before displaying any (while the AGC
converges).
The Raspberry Pi specific implementation makes this customisable from
the tuning file.
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>
|
|
configure
The number of frames to drop (not display) is passed back now from the
start method, not configure. This means applications have a chance to
set fixed exposure/gain before starting the camera and this can affect
the frame drop count that is returned.
Note how we need to be able to tell the very first time we start the
camera from subsequent restarts, hence addition of the "firstStart_"
flag.
Both the IPA implementation file and the pipeline handler need
matching modifications.
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>
|
|
Camera::start
The ScalerCrop control is handled by the pipeline handler, not the
IPA, so must be handled explicitly in the Camera::start method. The
ScalerCrop code used when processing requests has been factored out to
make it easy to reuse.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
This reorders Camera3Configs before executing
CameraConfiguration::validate() to make it easier for the Camera
to satisfy the Android framework request.
Signed-off-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Umang Jain <email@uajain.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Add blank line and fix compilation on gcc 7.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Use the newly introduced Camera3StreamConfig to associate the
Android requested streams with the associated StreamConfiguration
in a vector of configurations.
This change prepares to sort the vector of configuration before using
it to configure the Camera and populate the streams_ vector.
No functional changes intended.
Signed-off-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Umang Jain <email@uajain.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Camera3StreamConfig is a new class to store camera3_stream and
types with associated StreamConfiguration.
Signed-off-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Umang Jain <email@uajain.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The fromEntityName() function returns a pointer to a newly allocated
V4L2Device instance, which must be deleted by the caller. This opens the
door to memory leaks. Return a unique pointer instead, which conveys the
API semantics better than a sentence in the documentation.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The fromEntityName() function returns a pointer to a newly allocated
V4L2Subdevice instance, which must be deleted by the caller. This opens
the door to memory leaks. Return a unique pointer instead, which conveys
the API semantics better than a sentence in the documentation.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Forward any controls passed into the pipeline handler to the IPA.
The IPA then sets up the Raspberry Pi controller with these settings
appropriately, and passes back any V4L2 sensor controls that need
to be applied.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Tested-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
This change allows controls passed into PipelineHandler::start to be
forwarded onto IPAInterface::start(). We also add a return channel if the
pipeline handler must action any of these controls, e.g. setting the
analogue gain or shutter speed in the sensor device.
The IPA interface wrapper isn't addressed as it will soon be replaced by
a new mechanism to handle IPC.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Tested-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Applications now have the ability to pass in controls that need to be
applied on startup, rather than doing it through Request where there might
be some frames of delay in getting the controls applied.
This commit adds the ability to pass in a set of libcamera controls into
the pipeline handlers through the pipeline_handler::start() method. These
controls are provided by the application through the camera::start()
public API.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Tested-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
If the IPA fails during configuration, return an error flag to the
pipeline handler and fail the use case gracefully.
At present, the IPA configuration can fail for the following reasons:
- The sensor is not recognised, and fails to open a CamHelper object.
- The pipeline handler did not pass in controls for the ISP and sensor.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The Android camera device HAL3 specification does not require a
camera to go through any explicit close() call between configurations.
It is legitimate for a camera to be configured, a number of requests
processed and then re-configured again without any explicit stop.
The libcamera Android camera HAL starts the Camera at the first handled
request, and only stops it at camera close time. This means that two
camera configuration attempts in the same streaming session are only
interleaved by capture requests handling.
The libcamera::Camera state machine requires the Camera to be stopped
before any configuration take place, and this currently doesn't happen.
Fix this by stopping the camera and the associated worker thread if
a configuration attempt is performed while the Camera is in running
state.
This patch fixes cros_camera_test:
Camera3PreviewTest/Camera3SinglePreviewTest.Camera3BasicPreviewTest/0
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Initialize pixel array properties in the Android camera HAL
inspecting the camera properties.
If the camera does not provide any suitable property, not static
metadata is registered to the Android framework.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Initialize pixel array properties 'PixelArraySize' and
'PixelArrayActiveAreas' by inspecting the V4L2 CROP_BOUNDS and
CROP_DEFAULT selection targets.
The properties are registered only if the sensor subdevice support
the above mentioned selection targets.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Break out initialization to its own function in preparation to
add more properties.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The CameraSensorInfo::analogCrop top-left corner is defined relatively
to the sensor active area.
The analogCrop rectangle is constucted by retrieving the V4L2
selection target V4L2_SEL_TGT_CROP which is instead defined relatively
to the whole sensor's pixel array size.
Adjust the the analogCrop rectangle subtracting from its top-left corner
the active area distance from the full pixel array.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Make sure the 'camera3_capture_request_t *' provided to
CameraDevice::processCaptureRequest() is valid before attempting to
access it.
This patch fixes cros_camera_test:
Camera3FrameTest/Camera3InvalidRequestTest.NullOrUnconfiguredRequest/*
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The CameraDevice::getStaticMetadata() function populates the
entries for Android's static metadata by walking the ControlInfo
supported values reported by the libcamera pipeline.
The number of entries to be passed to Android is computed using the
vector's size which is initialized at vector creation time to the
maximum number of available entries.
In order to report the correct number of metadata do not create the
vector with the largest possible number of elements but only reserve
space for them using std::vector::reserve() which does not modify the
vector's size.
This patch fixes cros_camera_test:
Camera3DeviceTest/Camera3DeviceDefaultSettings.ConstructDefaultSettings/1
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The exposure times in the exposure modes were causing AGC oscillations
because the algorithm was demanding long unachievable exposure times
but, without working sensor metadata, thought it was getting them when
actually it was not. We fix it by making the exposure profile request
only achievable exposure times, as we do for the ov5647 tuning.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Setting these controls "fixes" them and the AE may not change them;
setting them back to zero returns them to the control of the AE
algorithm.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
AE/AGC "disabled" is now handled better by the algorithm for itself,
so it no longer needs to be "resumed" before setting fixed shutter or
gain values.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.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>
|
|
AGC, when paused, sets the last exposure/gain it wrote to be its
"fixed" values and will therefore continue to return them. When
resumed, we clear them so that both will float again.
This approach is better because AGC can be paused and we can
subsequently change (for example) the exposure and the gain won't
float again.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.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>
|
|
When both gain and shutter have been directly specified, do not filter
slowly towards those target values, but adopt them immediately. This
should match user expectations better.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The qcam log prints one message per frame, which is pretty verbose. This
feature is useful for debugging, but not necessarily as a default
option. Silence it by default, and add a -v/--verbose command line
parameter to make the log verbose.
While this could have been handled manually by checking a verbose flag
when printing the message, the feature is instead integrated with the Qt
log infrastructure to make it more flexible. Messages printed by
qDebug() are now silenced by default and controlled by the -v/--verbose
argument.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The top file description comment was incorrectly copied from the cam
application. Fix it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Let's try not to mix draft controls and regular controls.
Draft controls are unstable by definition, and removing or adding them
should not impact the enumeration of stable controls.
Keep draft controls at the end of the control_ids.yaml file and
add a comment to make clear where the draft controls section begins.
Acked-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The description text lists "stillraw" as a stream role option. This is
incorrect, it should be listed as "raw" instead.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
With the recent change in the bayer/embedded buffer matching code,
a condition would make the bayer buffer be requeued back to the device,
even though it could potentially be queued for matching. This would
cause unnecessary frame drops as sync would be lost.
The fix is to ensure the bayer buffer only gets requeued if the embedded
data buffer queue is not empty, i.e. the buffer truly is orphaned.
Additionally, we do this test before deciding to flush any of the two
queues of all their buffers.
Fixes: 909882b (pipeline: raspberrypi: Rework bayer/embedded data buffer matching)
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Tested-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Tested-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Introduce a pipeline model that lists the operations applied by the
camera pipeline. This is a first step towards defining explicitly how
the camera processes images, and how the libcamera controls affect the
processing.
The initial list of operations is meant to be expanded, and possibly
refactored (a block diagram should also be considered to make this
easier to read). How the controls affect the pipeline is largely missing
at this stage, with only a short explanation of the digital zoom to show
how this is meant to be documented. More documentation will be added
over time.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Fricke <sebastian.fricke.linux@gmail.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
A few grammatical errors remain in the Control class documentation.
Fix them.
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Previously we required that the sensor absolutely reaches the target
exposure, but this can fail if frame rates or analogue gains are
limited. Instead insist only that we get several frames with the same
exposure time, analogue gain and that the algorithm's target exposure
hasn't changed either.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Acked-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
partly saturated images
When parts of an image saturate then the image brightness no longer
increases linearly with increased exposure/gain. Having calculated a
linear gain value it's better then to try it, allowing for saturating
regions, and if necessary increase the gain some more. We repeat this
several times.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Acked-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
constructor
Use memset in the constructor for embedded structures, it is tidier
and initialises everything. We use the initialiser list for other
members.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Acked-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
SwitchMode
When an application has specified fixed exposure time and/or gain they
must be programmed into the sensor immediately, even before the sensor
has been started. For this to happen they must be written into the
image metadata when the SwitchMode method is invoked.
We also make the default exposure/gain, when nothing has been set,
customisable in the tuning file.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Acked-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The Awb class now implements a SwitchMode method which outputs its
AwbStatus for other algorithms to read, should they be interested.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Acked-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Introduce a function to fetch the AwbStatus (fetchAwbStatus), and call
it unconditionally at the top of Prepare so that both Prepare and
Process know thereafter that it's been done.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Acked-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Previously the calculation computed Y for each region before returning
the weighted average, which "baked in" the over-importance of small
statistics regions. The revised calculation will treat all pixels
equally when the region weights are the same, making it easier to
use. With the previous scheme, proper "average" metering was difficult
to implement.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Acked-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The method formerly known as divvyupExposure is given a more
understandable name.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Acked-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
