Add a new subpoject wrap file for the libpisp library located at
https://github.com/raspberrypi/libpisp

The libpisp library is used to configure the Raspberry Pi 5 Frontend
and Backend ISP components.

Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>

Add the relevant definitions for a 16-bit mono pixel and media-bus
format.

Signed-off-by: Naushir Patuck <naush@raspberrypi.com>

Add support for 16-bps (48-bpp) RGB output formats. These new formats
are define for the RGB and BGR ordering.

Signed-off-by: Naushir Patuck <naush@raspberrypi.com>

Add the Raspberry Pi 5 PiSP specific verification format:
- V4L2_PIX_FMT_RPI_BE

Add the Raspberry Pi 5 PiSP specific compressed Bayer format types 1/2:
- V4L2_PIX_FMT_PISP_COMP1_xxx
- V4L2_PIX_FMT_PISP_COMP2_xxx

Add the Raspberry Pi 5 PiSP Frontend and Backend config formats:
- V4L2_META_FMT_RPI_FE_CFG
- V4L2_META_FMT_RPI_BE_CFG

Add the Raspberry Pi 5 PiSP Frontend statistics format:
- V4L2_META_FMT_RPI_FE_STATS

Add 16-bit Bayer formats:
- MEDIA_BUS_FMT_Sxxx16_1X16

Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>

Add support for the following HDR modes in the Raspberry Pi IPA:
- Night mode
- Single exposure mode
- Multi-exposure (merged and unmerged)

The algorithm is updated to expect the HDR short channel to meter
explicitly for highlights. This means that it will not in general
under-expose the short channel more than is actually necessary.

When images don't have much saturation, it's good to detect this so
that some of the boost we want to apply to the dark areas can be
implemented as regular gain. This means we can then adjust the tone
curve less, leading to less flat looking images.

The impact on the HDR algorithm is then that this determines how we
build tonemaps dynamically. The highlights are more-or-less correct
now, so we have to build a power-type curve that gives us the
appropriately configured targets in the lower part of the histogram.

We allow the tuning file to supply the maximum spatial gain value,
rather than the whole curve (though it can supply this if it
wants). Some parameter defaults are tweaked to be generally better
across the range of our cameras.

Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>

The following member variable will be used by the derived IPAs in an
upcoming commit, so make them protected:

lensPresent_
monoSensor_
libcameraMetadata_

Signed-off-by: Naushir Patuck <naush@raspberrypi.com>

Add the Raspberry Pi 5 ISP (PiSP) pipeline handler to libcamera. To
include this pipeline handler in the build, set the following meson
option:

meson configure -Dpipelines=rpi/pisp

Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>

Add the Raspberry Pi 5 ISP (PiSP) IPA to libcamera. To include this IPA
in the build, set the following meson option:

meson configure -Dipas=rpi/pisp

Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>

The old ctt.py and alsc_only.py scripts are removed.

Instead of ctt.py use ctt_vc4.py or ctt_pisp.py, depending on your
target platform.

Instead of alsc_only.py use alsc_vc4.py or alsc_pisp.py, again
according to your platform.

Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>

Added the ability to tune the chromatic aberration correction
within the ctt. There are options for cac_only or to tune as part
of a larger tuning process. CTT will now recognise any files that
begin with "cac" as being chromatic aberration tuning files.

Signed-off-by: Ben Benson <ben.benson@raspberrypi.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>

Changed how users select which platform to tune for. Now users
specify a command line argument, '-t', to specify which target
platform.

Signed-off-by: Ben Benson <ben.benson@raspberrypi.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>

The various boilerplate parts of the tuning file are extended to
include the necessary extra bits for HDR, specifically:

* rpi.denoise has different configurations for HDR modes
* rpi.agc now has extra channels for HDR
* rpi.hdr parameters are added.

Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>

The IMX708 sensor driver advertises its module variants (narrow/wide angle lens,
IR block/pass) by modifying the media entity name string. So add duplicate
entries for each variant.

Signed-off-by: Nick Hollinghurst <nick.hollinghurst@raspberrypi.com>
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>

Look for the RAW mandatory stream flag in the pipeline handler config
file. If this flag is set, it guarantees that the application will
provide buffers for Unicam Image, so override the minUnicamBuffers and
minTotalUnicamBuffers config parameters in the following way:

- If startup drop frames are required, allocate at least 1 internal buffer.
- If no startup drop frames are required, do not allocate any internal buffers.

Look for the Output 0 mandatory stream flag in in the pipeline handler
config file. If this flag is set, it guarantees that the application
will provide buffers for the ISP, do not allocate any internal buffers
for the device.

Add a new rpi_apps.yaml pipeline handler config file that enables both
these flags.  To use the file, set the following env variable for a
custom build:

export LIBCAMERA_RPI_CONFIG_FILE=/usr/local/share/libcamera/pipeline/rpi/vc4/rpi_apps.yaml

or for a packaged install:

export LIBCAMERA_RPI_CONFIG_FILE=/usr/share/libcamera/pipeline/rpi/vc4/rpi_apps.yaml

Signed-off-by: Naushir Patuck <naush@raspberrypi.com>

Add a new control_ids_rpi.yaml file to hold the Raspberry Pi specific
vendor controls. This contains a single control PispConfigDumpFile that
will be used in the Pi 5 pipeline handler as a trigger to dump the
Backend configuration as a JSON file.

Signed-off-by: Naushir Patuck <naush@raspberrypi.com>

This allows the IPA to discover the correct black level values even
before any frames have been processed. This is important on the PiSP
platform where the front end black level blocks must be programmed in
advance.

Signed-off-by: David Plowman <david.plowman@raspberrypi.com>

This allows the IPA to get reasonable default colour gains before AWB
has run. This is particularly important on the PiSP platform where
these numbers are helpful in programming the Front End statistics
block in advance.

Signed-off-by: David Plowman <david.plowman@raspberrypi.com>

On the PiSP platform we have to program the Front End statistics
before we've have a chance to run any of the algorithms. So instead we
ask them for reasonable default values which we program in for the
first few frames.

Signed-off-by: David Plowman <david.plowman@raspberrypi.com>

Previously these were handled in the AGC/AEC exposure update
calculations by explicitly driving a higher digital gain to "cancel
out" any colour gains that were less than 1.

Now we're ignoring this in the AGC and leaving it to the IPA code to
normalise all the gains so that the smallest is 1. We don't regard
this as a "real" increase because one of the colour channels (just not
necessarily the green one) still gets the minimum gain possible.

We do, however, update the statistics calculations so that they
reflect any such digital gain increase, so that images are driven to
the correct level.

Signed-off-by: David Plowman <david.plowman@raspberrypi.com>

The delay context counter must be advanced even when we decide not to
run prepare/process. Otherwise, when we skip them at higher
framerates, the current IPA context counter will catch up and
overwrite the delay context.

It's safe to advance the counter because the metadata is always copied
forward a slot when we decide not to run the IPAs.

Signed-off-by: David Plowman <david.plowman@raspberrypi.com>

The maximum allowed digital gain is hard-coded to 4. Make it a
configurable parameter.

Signed-off-by: David Plowman <david.plowman@raspberrypi.com>

Much of the time we use the term "analogue gain" where we really mean
the combined analogue and digital gain (because the digital gain will
make up whatever the analogue gain can't deliver).

This commit replaces the use of "analogue gain" by just "gain" in
places where we really mean the combined gain. There are a couple of
principle areas:

1. Where we previously talked about the "fixedAnalaogueGain"
(including setting it "manually") this is now just the "fixedGain"
(because it always encompassed both analogue and digital gain).

Along with this, the setFixedShutter/Gain functions no longer update
the output status directly. Applications should wait in the usual way
for AGC/AEC changes to take effect, and this "shortcut" actually
doesn't fit well with the gain being the combined gain.

2. The divideUpExposure method is adjusted to be clearer that it's
setting the combined gain, and it's prepare() that will discover later
what the analogue gain actually delivered.

Signed-off-by: David Plowman <david.plowman@raspberrypi.com>

Previously we let prepare() do the work by comparing the desired total
exposure against the shutter time and analogue gain. This can cause
the image to "wink" at high framerates because we may skip running
prepare() to get the new digital gain even when the delayed AGC status
(which came out of an earlier call to process()) shows that a change
was required.

Now we're taking explicit control of the digital gain by calculating
it ourselves so that we can output it in the standard AgcStatus
object. This means that whenever the delayed AGC status changes, we
have the correct digital gain to go with it.

Signed-off-by: David Plowman <david.plowman@raspberrypi.com>

Here we update the digital gain handling to use the value computed by
process() in the AgcStatus, not the version that was previously in the
AgcPrepareStatus.

Because we apply this digital gain directly with no further
modification, we have to update it to reflect any exposure/gain
quantisation that happens (in IpaBase::applyAGC).

We must also run the new platformPrepareAgc() even when we're skipping
platformPrepareIsp(), which has been split out of the previous
platformPrepareIsp() implementation.

Signed-off-by: David Plowman <david.plowman@raspberrypi.com>

The digital gain now comes from the AgcStatus, not from the
AgcPrepareStatus.

Signed-off-by: David Plowman <david.plowman@raspberrypi.com>

All platforms are now using the digital gain from the AgcStatus, so
the AgcPrepareStatus and prepare() methods can be tidied up.

Signed-off-by: David Plowman <david.plowman@raspberrypi.com>