The LSP autoformatter doesn't like some of the current formatting, let's
make it happier. Note that not all of its suggestions were accepted
because readability is preferred and adjusting .clang-format may not be
easy or possible.
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>
The libcamera_generated_ipa_headers variable, containing the list of
generated IPA headers, is listed in the sources of IPA modules, as well
as IPA tests. This was done to ensure that the modules and tests get
rebuilt when the generate IPA headers change. However, the dependency is
already handled through the libcamera_private dependency object,
specified for all those modules and tests. There's no need to list the
IPA generated headers as sources. Drop them.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
The PipelineHandlerFactoryBase class has a name that is propagated to
the PipelineHandler instance it creates.
In present implementation, this name comes from the
REGISTER_PIPELINE_HANDLER registration macro. It corresponds to the
stringified name of the PipelineHandler derived class. Therefore,
PipelineHandler factories and instances names can be quite long such as
"PipelineHandlerRkISP1".
A libcamera user may have to explicitly refer to a PipelineHandler name
for configuration purpose: one usage of the name can be to define a
pipeline handlers match list and their priorities. It is desired, for
user convenience, to use a short name to designate a pipeline handler.
Reusing the short pipeline names already defined in the meson option
files is an existing and consistent way of naming pipelines.
This change adds an explicit name parameter to the
REGISTER_PIPELINE_HANDLER registration macro. That parameter is used to
define the name of a pipeline handler factory, instead of the current
pipeline handler class name.
Each pipeline registration is updated accordingly. The short name
assigned corresponds to the pipeline directory name in the source tree.
It is consistent with pipelines names used in meson.
Changing the pipeline name has an impact on the IPA modules: each module
defines a IPAModuleInfo structure. This structure has a pipelineName
member defining the pipeline handler name it shall match with.
Therefore, each internal IPA module definition has to be changed to have
its IPAModuleInfo pipelineName name updated with the short pipeline
handler name.
In addition to this pipelineName member, the IPAModuleInfo structure
also has a name member, associated to the IPA module name. Having
renamed the pipelines to a short name, the pipeline name and the IPA
module names of the IPAModuleInfo structure are the same: for in-tree
IPA, they correspond to the respective pipeline and IPA subdirectories
in the source tree. However the IPA name could be different, for
instance with a close source IPA implementation built out-of-tree. Thus,
it makes sense to keep the IPA name in that structure, as the 2
definitions may not always be redundant.
Signed-off-by: Julien Vuillaumier <julien.vuillaumier@nxp.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
[Kieran: Adjust for clang-format style fix, reformat commitmsg]
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Source files in libcamera start by a comment block header, which
includes the file name and a one-line description of the file contents.
While the latter is useful to get a quick overview of the file contents
at a glance, the former is mostly a source of inconvenience. The name in
the comments can easily get out of sync with the file name when files
are renamed, and copy & paste during development have often lead to
incorrect names being used to start with.
Readers of the source code are expected to know which file they're
looking it. Drop the file name from the header comment blocks in all
remaining locations that were not caught by the automated script as they
are out of sync with the file name.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
Source files in libcamera start by a comment block header, which
includes the file name and a one-line description of the file contents.
While the latter is useful to get a quick overview of the file contents
at a glance, the former is mostly a source of inconvenience. The name in
the comments can easily get out of sync with the file name when files
are renamed, and copy & paste during development have often lead to
incorrect names being used to start with.
Readers of the source code are expected to know which file they're
looking it. Drop the file name from the header comment block.
The change was generated with the following script:
----------------------------------------
dirs="include/libcamera src test utils"
declare -rA patterns=(
['c']=' \* '
['cpp']=' \* '
['h']=' \* '
['py']='# '
['sh']='# '
)
for ext in ${!patterns[@]} ; do
files=$(for dir in $dirs ; do find $dir -name "*.${ext}" ; done)
pattern=${patterns[${ext}]}
for file in $files ; do
name=$(basename ${file})
sed -i "s/^\(${pattern}\)${name} - /\1/" "$file"
done
done
----------------------------------------
This misses several files that are out of sync with the comment block
header. Those will be addressed separately and manually.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
In preparation for switching to a derivation of AgcMeanLuminance, add
a function to parse and store the statistics for easy retrieval in an
overriding estimateLuminance() function.
Now that we have a MeanLuminanceAgc class that centralises our AEGC
algorithm, derive the IPU3's Agc class from it and plumb in the
necessary framework to enable it to be used. For simplicity's sake
this commit switches the algorithm to use the derived class, but
does not remove the bespoke functions at this time.
Reviewed-by: Stefan Klug <stefan.klug@ideasonboard.com>
Signed-off-by: Daniel Scally <dan.scally@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Meson uses tags to sort installed files in categories, and makes it
possible to install a subset of the files using the '--tags' argument to
'meson install'. This is typically used by distributions to split the
runtime, development and documentation files into separate packages.
By default, meson tries to guess the correct tag for installed files,
but can't always do so properly. Mark the install targets that meson
can't guess with the correct install_tag.
As the feature has been introduced in meson 0.60, bump the minimum meson
version. The latest LTS release of all major distributions that
libcamera currently targets ship a recent enough meson version.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
The current IPA build files require a flat directory structure for the
IPAs. Modify the build files to remove this restriction and allow a
directory structure such as:
src/ipa
|- raspberrypi
|- common
|- cam_helpers
|- controller
|- vc4
|- rkisp1
|- ipu3
where each subdir (e.g. raspberrypi/common, raspberrypi/cam_helper) has
its own meson.build file. Such a directory structure will be introduced
for the Raspberry Pi IPA in a future commit.
Signed-off-by: Naushir Patuck <naush@raspberrypi.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>
The CameraSensor class validates that the sensor driver in use supports
the controls required for IPA modules to work correctly.
For in-tree IPA modules, whose pipeline handlers already use
CameraSensor there's no need to validate such controls again.
Remove controls validation from the IPU3 and RkISP1 IPA modules and rely
on CameraSensor doing that at initialization time.
The list of mandatory controls is expanded to add V4L2_CID_ANALOGUE_GAIN
without which IPA modules cannot function.
The new requirement only applies to RAW sensors, platforms like UVC and
Simple are not impacted by this change.
While at it, expand the sensor driver requirements documentation to
include V4L2_ANALOGUE_GAIN in the list of mandatory controls a sensor
driver has to support.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reorder functions in the base ipa::Algorithm and its derived classes to
match the calling order: queueRequest(), prepare() and process(). This
makes the code flow easier to read. No functional change intended.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Fill the frame metadata in the AGC and AWB algorithm's prepare()
function. This removes the need to fill metadata manually in the IPA
module's processStatsBuffer() function.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Extend the Algorithm::process() function with a metadata control list,
to be filled by individual algorithms with frame metadata. Update the
rkisp1 and ipu3 IPA modules accordingly, and drop the dead code in the
IPARkISP1::prepareMetadata() function while at it.
This only creates the infrastructure, filling metadata in individual
algorithms will be handled separately.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Add fields for minimum and maximum line length (in units of pixels) to
the IPACameraSensorInfo structure. This replaces the existing lineLength
field.
Update the ipu3, raspberrypi and rkisp1 IPAs to use
IPACameraSensorInfo::minLineLength instead of
IPACameraSensorInfo::lineLength, as logically we will always want to use
the fastest sensor readout by default.
Since the IPAs now use minLineLength for their calculations, set the
starting value of the V4L2_CID_HBLANK control to its minimum in
CameraSensor::init().
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Tested-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
The REGISTER_CAMERA_SENSOR_HELPER() macro defines a class type that
inherits from the CameraSensorHelperFactory class, and implements a
constructor and createInstance() function. Replace the code generation
through macro with the C++ equivalent, a class template, as done by the
Algorithm factory.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Xavier Roumegue <xavier.roumegue@oss.nxp.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
The IPAFrameContext documentation has a spurious Doxygen \struct
statement that is not needed, and uses a \struct instead of a \var in
another location. Fix both issues. This doesn't cause any change in the
generated documentation.
Note that the Doxygen output for IPAFrameContext is incorrect,
documentation is missing for all members. This is caused by using "."
instead of "::" in our documentation, which we currently do because the
correct syntax produces Doxygen warnings (and still incorrect output).
See https://github.com/doxygen/doxygen/issues/9343.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
The introduction of the FCQueue in the IPU3 inadvertently introduced a
bug which cleared the initialisation of the session configuration
immediately after some parameters had been set.
Furthermore, it cleared and never re-initialised the sensor line
duration property, which was previously only set during the call to
init().
Move the clearing of the contexts from the updateSessionConfiguration()
call to the earliest opportunity in configure(), and immediately
re-initialise the sensor parameters.
Bug: https://bugs.libcamera.org/show_bug.cgi?id=151
Fixes: 85c5c47325 ("ipa: ipu3: Use the FCQueue")
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Call the Algorithm::queueRequest() function of all algorithms when a
request is queued, to pass the request controls to the algorithms. We
can now drop the copy of the control list stored in IPAFrameContext as
it isn't used anymore.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Inherit from the base FrameContext class in the IPU3 IPAFrameContext.
This allows dropping the frame member, which is now stored in the base
class.
As the frame member of the base FrameContext class is private, the check
that accesses it in IPAIPU3::processStatsBuffer() would fail to compile.
As it won't be relevant anymore with the upcoming switch to the FCQueue
class, drop 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>
Frame contexts will become the core component of IPA modules, always
available to functions of the algorithms. To indicate and prepare for
this, turn the frame context pointer passed to Algorithm::process() into
a reference.
The RkISP1 IPA module doesn't use frame contexts yet, so pass a dummy
context for now.
While at it, drop an unneeded [[maybe_unused]] from Agc::process() and
add a missing parameter documentation for the frameContext argument to
Awb::process().
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Fix various issues in Doxygen comment blocks:
- \param requires an [in] or [out] tag
- \param must come before the body of the documetation
- Drop leftover \param for argument that has been removed
- Rename coarseSearchStep to kCoarseSearchStep
- White space and line wrap
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Replace the manual instantiation of algorithms with an automatic
mechanism based on a tuning data file, provided by the Module base
class. This brings the IPU3 IPA module in line with the RkISP1 IPA
module.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Add a tuning data file for uncalibrated sensors, picked by the pipeline
handler when no sensor-specific tuning file is available. The file lists
the 5 algorithms currently instantiated by the IPA module.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
libipa defines an abstract Algorithm class template that is specialized
by IPA modules. IPA modules then instantiate and manage algorithms
internally, without help from libipa. With ongoing work on tuning data
support for the RkISP1, and future similar work for the IPU3, more code
duplication for algorithms management is expected.
To address this and share code between multiple IPA modules, introduce a
new Module class template that will define and manage top-level concepts
for the IPA module.
The Module class template needs to be specialized with the same types as
the Algorithm class. To avoid manual specialization of both classes,
store the types in the Module class, and replace the template arguments
of the Algorithm class with a single Module argument from which the
other types are retrieved.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
The factor used right now in the IPU3 is 8192, as a multiplier of the
estimated gain. This is wrong, as the isp is adding 1.0 to the gain
applied, ie Pout = { Pin * (1 + Gx) }.
Fix it, and to ease the reading, introduce a small helper function.
Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Instead of having one frame context constantly being updated,
this patch aims to introduce per-frame IPAFrameContext which
are stored in a ring buffer. Whenever a request is queued, a new
IPAFrameContext is created and inserted into the ring buffer.
The IPAFrameContext structure itself has been slightly extended
to store a frame id and a ControlList for incoming frame
controls (sent in by the application). The next step would be to
read and set these controls whenever the request is actually queued
to the hardware.
Since now we are working in multiples of IPAFrameContext, the
Algorithm::process() will actually take in a IPAFrameContext pointer
(as opposed to a nullptr while preparing for this change).
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Currently we have a single structure of IPAFrameContext but
subsequently, we shall have a ring buffer (or similar) container
to keep IPAFrameContext structures for each frame.
It would be a hassle to query out the frame context required for
process() (since they will reside in a ring buffer) by the IPA
for each process. Hence, prepare the process() libipa template to
accept a particular IPAFrameContext early on.
As for this patch, we shall pass in the pointer as nullptr, so
that the changes compile and keep working as-is.
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Currently, IPAFrameContext consolidates the values computed by the
active state of the algorithms, along with the values applied on
the sensor.
Moving ahead, we want to have a frame context associated with each
incoming request (or frame to be captured). This shouldn't necessarily
be tied to "active state" of the algorithms hence:
- Rename current IPAFrameContext -> IPAActiveState
This will now reflect the latest active state of the algorithms and
has nothing to do with any frame-related ops/values.
- Re-instate IPAFrameContext with a sub-structure 'sensor' currently
storing the exposure and gain value.
Adapt the various access to the frame context to the new changes
as described above.
Subsequently, the re-instated IPAFrameContext will be extended to
contain a frame number and ControlList to remember the incoming
request controls provided by the application. A ring-buffer will
be introduced to store these frame contexts for a certain number
of frames.
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
A not initialized frame ignore counter (ignoreCounter_) makes the AF
function not work since the ignore counter may start from a random
negative number. The counter was set to kIgnoreFrame when AF is in
prepare stage.
Signed-off-by: Kate Hsuan <hpa@redhat.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Provide enforcement of the selection of the block_{width,height}_log2
parameters to the capabilities of the hardware.
While this selection is currently hardcoded to the minimum, providing
the restriction now allows for further dynamic sizing in the future and
documents the restrictions directly in code, making use of the already
existing constants.
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
The IPAIPU3 interface currently uses event-type based structures in
order to communicate with the pipeline-handler (and vice-versa).
Replace the event based structures with dedicated functions associated
to each operation.
The translated naming scheme of actions to signals are:
ActionSetSensorControls => setSensorControls
ActionParamFilled => paramsBufferReady
ActionMetadataReady => metadataReady
The translated naming scheme of events to dedicated functions are:
EventProcessControls => queueRequest()
EventStatReady => processStatsBuffer()
EventFillParams => fillParamsBuffer()
The dedicated functions are called from pipeline-handler to the IPA
using IPC. These functions run asynchronously and when completed,
the IPA emits the respective signals as stated above in the translated
naming scheme.
The EventProcessControls is translated to queueRequest() to bring
symmetry to the IPU3 interface with other IPA interfaces.
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Milan ZamazalandLaurent Pinchart
Julien VuillaumierandKieran Bingham
Daniel ScallyandKieran Bingham
Jacopo MondiandLaurent Pinchart
Naushir PatuckandLaurent Pinchart
Jacopo Mondi
Marvin SchmidtandLaurent Pinchart
Jean-Michel Hautbois
Umang JainandKieran Bingham
Kate HsuanandKieran Bingham