| Age | Commit message (Collapse) | Author |
|---|
|
The black level determination, already present as a separate class, can
be moved to the prepared Algorithm processing structure. It is the
first of the current software ISP algorithms that is called in the stats
processing sequence, which means it is also the first one that should be
moved to the new structure. Stats processing starts with calling
Algorithm-based processing so the call order of the algorithms is
retained.
Movement of this algorithm is relatively straightforward because all it
does is processing stats.
The comment about getting black level from the tuning files is dropped.
The black level will be taken from CameraSensorHelper if available and
that will be implemented in one of the followup patches.
Black level is now recomputed on each stats processing. In a future
patch, after DelayedControls are used, this will be changed to recompute
the black level only after exposure/gain changes.
The black level depends on the sensor used, the computed value can be
reused in a followup capture sessions with the same sensor. Thus it is
sufficient to (re)set the initial value in BlackLevel::init.
Signed-off-by: Milan Zamazal <mzamazal@redhat.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
We are ready to introduce algorithms now. First, let's create
algorithms. The algorithms are not called yet, calls to them will be
added in followup patches.
The maximum number of contexts is set to the same value as in hardware
pipelines.
Signed-off-by: Milan Zamazal <mzamazal@redhat.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Software ISP image processing algorithms are currently defined in a
simplified way, different from other libcamera pipelines. This is not
good for several reasons:
- It makes the software ISP code harder to understand due to its
different structuring.
- Adding more algorithms may make the code harder to understand
generally.
- Mass libcamera code changes may not be easily applicable to software
ISP.
- Algorithm sharing with other pipelines is not easily possible.
This patch introduces basic software ISP IPA skeletons structured
similarly to the other pipelines. The newly added files are currently
not used or compiled and the general skeleton structures don't contain
anything particular. It is just a preparation step for a larger
refactoring and the code will be actually used and extended as needed in
followup patches.
Signed-off-by: Milan Zamazal <mzamazal@redhat.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@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>
|
|
Many build targets link with libipa and need libipa_includes. Group them
in a libipa_dep dependency object to simplify the users.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
Black may not be represented as 0 pixel value for given hardware, it may
be higher. If this is not compensated then various problems may occur
such as low contrast or suboptimal exposure.
The black pixel value can be either retrieved from a tuning file for the
given hardware, or automatically on the fly. The former is the right
and correct method, while the latter can be used when a tuning file is
not available for the given hardware. Since there is currently no
support for tuning files in software ISP, the automatic, hardware
independent way, is always used. Support for tuning files should be
added in future but it will require more work than this patch.
The patch looks at the image histogram and assumes that black starts
when pixel values start occurring on the left. A certain amount of the
darkest pixels is ignored; it doesn't matter whether they represent
various kinds of noise or are real, they are better to omit in any case
to make the image looking better. It also doesn't matter whether the
darkest pixels occur around the supposed black level or are spread
between 0 and the black level, the difference is not important.
An arbitrary threshold of 2% darkest pixels is applied; there is no
magic about that value.
The patch assumes that the black values for different colors are the
same and doesn't attempt any other non-primitive enhancements. It
cannot completely replace tuning files and simplicity, while providing
visible benefit, is its goal. Anything more sophisticated is left for
future patches.
A possible cheap enhancement, if needed, could be setting exposure +
gain to minimum values temporarily, before setting the black level. In
theory, the black level should be fixed but it may not be reached in all
images. For this reason, the patch updates black level only if the
observed value is lower than the current one; it should be never
increased.
The purpose of the patch is to compensate for hardware properties.
General image contrast enhancements are out of scope of this patch.
Stats are still gathered as an uncorrected histogram, to avoid any
confusion and to represent the raw image data. Exposure must be
determined after the black level correction -- it has no influence on
the sub-black area and must be correct after applying the black level
correction. The granularity of the histogram is increased from 16 to 64
to provide a better precision (there is no theory behind either of those
numbers).
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Milan Zamazal <mzamazal@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Milan Zamazal <mzamazal@redhat.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Define the Soft IPA main and event interfaces, add the Soft IPA
implementation.
The current src/ipa/meson.build assumes the IPA name to match the
pipeline name. For this reason "-Dipas=simple" is used for the
Soft IPA module.
Auto exposure/gain and AWB implementation by Dennis, Toon and Martti.
Auto exposure/gain targets a Mean Sample Value of 2.5 following
the MSV calculation algorithm from:
https://www.araa.asn.au/acra/acra2007/papers/paper84final.pdf
Use CameraSensorHelper to convert the analogue gain code read from the
camera sensor into real analogue gain value. In the future this makes
it possible to use faster AE/AGC algorithm. Right now the CameraSensorHelper
lets us use the full range of analogue gain values.
If there is no CameraSensorHelper for the camera sensor in use, a
warning log message is printed.
Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> # sc8280xp Lenovo x13s
Tested-by: Pavel Machek <pavel@ucw.cz>
Reviewed-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org>
Co-developed-by: Dennis Bonke <admin@dennisbonke.com>
Signed-off-by: Dennis Bonke <admin@dennisbonke.com>
Co-developed-by: Marttico <g.martti@gmail.com>
Signed-off-by: Marttico <g.martti@gmail.com>
Co-developed-by: Toon Langendam <t.langendam@gmail.com>
Signed-off-by: Toon Langendam <t.langendam@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
