[2/3] libcamera: controls: Define a new core Hue control

23646 diff mbox series

From: "van Veen, Stephan" <stephan.vanveen@karlstorz.com>

Define a new control to support configuration of Hue adjustments when
supported by the available platform.

Signed-off-by: van Veen, Stephan <stephan.vanveen@karlstorz.com>
[Kieran: Split control addition and implementation and refactor commit
messages]
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>

---

Open questions

How should we standardise the units on this control? Should this be a
scale of -1, 0, +1 and scaled to the capability of the hardware by the
IPA? Or should we standardise on similar units from a colour wheel and
use values in degrees (for RKISP1 use case this would be -90,0,+87.188).

As the RKISP1 makes a phase shift adjustment, is this expected to be
similar on other pipelines? Or should we also expect anything that would
expose a full 360 degree explicit hue? (I assume not now I write that
:D)

Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
---
 src/libcamera/control_ids_core.yaml | 10 ++++++++++
 1 file changed, 10 insertions(+)

On Tue, Jun 24, 2025 at 06:12:22PM +0100, Kieran Bingham wrote:
> From: "van Veen, Stephan" <stephan.vanveen@karlstorz.com>
> 
> Define a new control to support configuration of Hue adjustments when
> supported by the available platform.
> 
> Signed-off-by: van Veen, Stephan <stephan.vanveen@karlstorz.com>
> [Kieran: Split control addition and implementation and refactor commit
> messages]
> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
> 
> ---
> 
> Open questions
> 
> How should we standardise the units on this control? Should this be a
> scale of -1, 0, +1 and scaled to the capability of the hardware by the
> IPA? Or should we standardise on similar units from a colour wheel and
> use values in degrees (for RKISP1 use case this would be -90,0,+87.188).

A value in degrees seem more standard.

> As the RKISP1 makes a phase shift adjustment, is this expected to be
> similar on other pipelines? Or should we also expect anything that would
> expose a full 360 degree explicit hue? (I assume not now I write that
> :D)

I wonder why the rkisp1 limits the adjustement to [-90, +90[ range. Any
insight ?

> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
> ---
>  src/libcamera/control_ids_core.yaml | 10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/src/libcamera/control_ids_core.yaml b/src/libcamera/control_ids_core.yaml
> index 028919ef3d3e..58abf8434eae 100644
> --- a/src/libcamera/control_ids_core.yaml
> +++ b/src/libcamera/control_ids_core.yaml
> @@ -1281,4 +1281,14 @@ controls:
>  
>          The FrameWallClock control can only be returned in metadata.
>  
> +  - Hue:
> +      type: float
> +      direction: inout
> +      description:  |
> +        Specify a fixed hue parameter.
> +
> +        Positive values (up to 1.0) produce an increase of the hue angle up to
> +        90 degrees; negative values (up to -1.0) produce a decrease of the hue
> +        angle down to -90 degrees.
> +
>  ...