[v1,2/2] ipa: simple: data: Add OV2740 tuning file
diff mbox series

Message ID 20260507161103.3D1441EA006B@mailuser.phl.internal
State Superseded
Headers show
Series
  • ipa: simple: OV2740 tuning file and swstats sumShift cleanup
Related show

Commit Message

Javier Tia May 7, 2026, 4:03 p.m. UTC 
Add a tuning file for the OV2740 sensor calibrated from the Intel IPU6
AIQB binary (OV2740_CJFLE23_ADL.aiqb) shipped with the Lenovo ThinkPad
X1 Carbon Gen 10 (Alder Lake, JP2 module, Chicony CJFLE23 camera).

Black level is 0x40 at 10-bit (64 ADU), stored as the 16-bit value 4096
per the BlackLevel algorithm convention (value >> 8 = 16 at 8-bit scale).

AWB gain limits are derived from the minimum R/G and B/G chromaticities
across the 8 calibrated illuminants (2319 K to 6302 K), with a 10%
headroom margin: maxGainR=2.49, maxGainB=3.07.

Eight CCMs are extracted from the AIQB advanced color matrix records
(record id=25, float format), covering illuminants from 2319 K
(incandescent) to 6302 K (daylight).

Signed-off-by: Javier Tia <floss@jetm.me>
---
 src/ipa/simple/data/meson.build |  1 +
 src/ipa/simple/data/ov2740.yaml | 52 +++++++++++++++++++++++++++++++++
 2 files changed, 53 insertions(+)
 create mode 100644 src/ipa/simple/data/ov2740.yaml

Comments

Hans de Goede May 7, 2026, 7 p.m. UTC | #1 
Hi Javier,

On 7-May-26 18:03, Javier Tia wrote:
> Add a tuning file for the OV2740 sensor calibrated from the Intel IPU6
> AIQB binary (OV2740_CJFLE23_ADL.aiqb) shipped with the Lenovo ThinkPad
> X1 Carbon Gen 10 (Alder Lake, JP2 module, Chicony CJFLE23 camera).

Oh, you extracted these from the AIQB file that is very useful.

Can you share a script or some AIQB format documentation so we can
do the same for other sensors ?

Regards.

Hans




> 
> Black level is 0x40 at 10-bit (64 ADU), stored as the 16-bit value 4096
> per the BlackLevel algorithm convention (value >> 8 = 16 at 8-bit scale).
> 
> AWB gain limits are derived from the minimum R/G and B/G chromaticities
> across the 8 calibrated illuminants (2319 K to 6302 K), with a 10%
> headroom margin: maxGainR=2.49, maxGainB=3.07.
> 
> Eight CCMs are extracted from the AIQB advanced color matrix records
> (record id=25, float format), covering illuminants from 2319 K
> (incandescent) to 6302 K (daylight).
> 
> Signed-off-by: Javier Tia <floss@jetm.me>
> ---
>  src/ipa/simple/data/meson.build |  1 +
>  src/ipa/simple/data/ov2740.yaml | 52 +++++++++++++++++++++++++++++++++
>  2 files changed, 53 insertions(+)
>  create mode 100644 src/ipa/simple/data/ov2740.yaml
> 
> diff --git a/src/ipa/simple/data/meson.build b/src/ipa/simple/data/meson.build
> index 92795ee4..e3e4de74 100644
> --- a/src/ipa/simple/data/meson.build
> +++ b/src/ipa/simple/data/meson.build
> @@ -1,6 +1,7 @@
>  # SPDX-License-Identifier: CC0-1.0
>  
>  conf_files = files([
> +    'ov2740.yaml',
>      'uncalibrated.yaml',
>  ])
>  
> diff --git a/src/ipa/simple/data/ov2740.yaml b/src/ipa/simple/data/ov2740.yaml
> new file mode 100644
> index 00000000..da7e1efe
> --- /dev/null
> +++ b/src/ipa/simple/data/ov2740.yaml
> @@ -0,0 +1,52 @@
> +# SPDX-License-Identifier: CC0-1.0
> +# Calibrated from OV2740_CJFLE23_ADL.aiqb (Lenovo JP2 module, IPU6 ADL)
> +%YAML 1.1
> +---
> +version: 1
> +algorithms:
> +  - BlackLevel:
> +      blackLevel: 4096
> +  - Awb:
> +      maxGainR: 2.49
> +      maxGainB: 3.07
> +      speed: 0.25
> +  - Ccm:
> +      ccms:
> +        - ct: 2319
> +          ccm: [  1.5938, -0.1714, -0.4224,
> +                 -0.6134,  1.9612, -0.3478,
> +                 -0.4710, -1.8500,  3.3210 ]
> +        - ct: 2854
> +          ccm: [  1.6119, -0.3132, -0.2987,
> +                 -0.4418,  1.8227, -0.3809,
> +                 -0.1017, -1.3958,  2.4975 ]
> +        - ct: 2884
> +          ccm: [  1.7739, -0.6655, -0.1085,
> +                 -0.4113,  1.6619, -0.2506,
> +                 -0.0150, -1.1661,  2.1811 ]
> +        - ct: 3239
> +          ccm: [  1.8298, -0.6636, -0.1662,
> +                 -0.4086,  1.7373, -0.3287,
> +                 -0.0500, -1.0836,  2.1335 ]
> +        - ct: 3865
> +          ccm: [  1.8836, -0.7430, -0.1406,
> +                 -0.3653,  1.7000, -0.3348,
> +                 -0.0542, -0.8442,  1.8984 ]
> +        - ct: 4136
> +          ccm: [  1.9043, -0.8348, -0.0695,
> +                 -0.3241,  1.6389, -0.3148,
> +                  0.0262, -0.9593,  1.9332 ]
> +        - ct: 4939
> +          ccm: [  1.6371, -0.4490, -0.1881,
> +                 -0.2675,  1.6494, -0.3819,
> +                 -0.0245, -0.7782,  1.8026 ]
> +        - ct: 6302
> +          ccm: [  1.6401, -0.4418, -0.1984,
> +                 -0.2360,  1.7191, -0.4832,
> +                 -0.0248, -0.7221,  1.7469 ]
> +  - Adjust:
> +      gamma: 2.2
> +      contrast: 1.0
> +      saturation: 1.0
> +  - Agc:
> +...
Barnabás Pőcze May 8, 2026, 8:07 a.m. UTC | #2 
2026. 05. 07. 18:03 keltezéssel, Javier Tia írta:
> Add a tuning file for the OV2740 sensor calibrated from the Intel IPU6
> AIQB binary (OV2740_CJFLE23_ADL.aiqb) shipped with the Lenovo ThinkPad
> X1 Carbon Gen 10 (Alder Lake, JP2 module, Chicony CJFLE23 camera).
> 
> Black level is 0x40 at 10-bit (64 ADU), stored as the 16-bit value 4096
> per the BlackLevel algorithm convention (value >> 8 = 16 at 8-bit scale).
> 
> AWB gain limits are derived from the minimum R/G and B/G chromaticities
> across the 8 calibrated illuminants (2319 K to 6302 K), with a 10%
> headroom margin: maxGainR=2.49, maxGainB=3.07.
> 
> Eight CCMs are extracted from the AIQB advanced color matrix records
> (record id=25, float format), covering illuminants from 2319 K
> (incandescent) to 6302 K (daylight).
> 
> Signed-off-by: Javier Tia <floss@jetm.me>
> ---

This needs certain changes from https://patchwork.libcamera.org/project/libcamera/list/?series=5915,
but I don't think this is mentioned anywhere. I believe

   git pw patch apply 26659 --no-deps

is sufficient.

After that I can confirm that it does change the image. I'm seeing a lot of "pink"
areas with lights, but guess this is just an issue with the softisp.

But I'm curious to see the sensor controls in your case, e.g. in a certain scene I have

$ v4l2-ctl -d /dev/v4l-subdev4 -L | grep -E '(exposure|analogue_gain|vertical_blanking)'
            exposure 0x00980911 (int)    : min=4 max=1102 step=1 default=1102 value=1102 flags=has-min-max
   vertical_blanking 0x009e0901 (int)    : min=18 max=955 step=1 default=18 value=18 flags=has-min-max
       analogue_gain 0x009e0903 (int)    : min=128 max=1983 step=1 default=128 value=1983 flags=has-min-max

Unfortunately the vertical blanking is kept at its minimum, and thus the range of exposure
is not particularly big, so the agc algorithm has a tendency of maxing out the exposure
almost immediately, and then it operates with close-to-max analogue gain. I'm wondering
if the same thing happens in your case as well?


>   src/ipa/simple/data/meson.build |  1 +
>   src/ipa/simple/data/ov2740.yaml | 52 +++++++++++++++++++++++++++++++++
>   2 files changed, 53 insertions(+)
>   create mode 100644 src/ipa/simple/data/ov2740.yaml
> 
> diff --git a/src/ipa/simple/data/meson.build b/src/ipa/simple/data/meson.build
> index 92795ee4..e3e4de74 100644
> --- a/src/ipa/simple/data/meson.build
> +++ b/src/ipa/simple/data/meson.build
> @@ -1,6 +1,7 @@
>   # SPDX-License-Identifier: CC0-1.0
>   
>   conf_files = files([
> +    'ov2740.yaml',
>       'uncalibrated.yaml',
>   ])
>   
> diff --git a/src/ipa/simple/data/ov2740.yaml b/src/ipa/simple/data/ov2740.yaml
> new file mode 100644
> index 00000000..da7e1efe
> --- /dev/null
> +++ b/src/ipa/simple/data/ov2740.yaml
> @@ -0,0 +1,52 @@
> +# SPDX-License-Identifier: CC0-1.0
> +# Calibrated from OV2740_CJFLE23_ADL.aiqb (Lenovo JP2 module, IPU6 ADL)
> +%YAML 1.1
> +---
> +version: 1
> +algorithms:
> +  - BlackLevel:
> +      blackLevel: 4096
> +  - Awb:
> +      maxGainR: 2.49
> +      maxGainB: 3.07
> +      speed: 0.25
> +  - Ccm:
> +      ccms:
> +        - ct: 2319
> +          ccm: [  1.5938, -0.1714, -0.4224,
> +                 -0.6134,  1.9612, -0.3478,
> +                 -0.4710, -1.8500,  3.3210 ]
> +        - ct: 2854
> +          ccm: [  1.6119, -0.3132, -0.2987,
> +                 -0.4418,  1.8227, -0.3809,
> +                 -0.1017, -1.3958,  2.4975 ]
> +        - ct: 2884
> +          ccm: [  1.7739, -0.6655, -0.1085,
> +                 -0.4113,  1.6619, -0.2506,
> +                 -0.0150, -1.1661,  2.1811 ]
> +        - ct: 3239
> +          ccm: [  1.8298, -0.6636, -0.1662,
> +                 -0.4086,  1.7373, -0.3287,
> +                 -0.0500, -1.0836,  2.1335 ]
> +        - ct: 3865
> +          ccm: [  1.8836, -0.7430, -0.1406,
> +                 -0.3653,  1.7000, -0.3348,
> +                 -0.0542, -0.8442,  1.8984 ]
> +        - ct: 4136
> +          ccm: [  1.9043, -0.8348, -0.0695,
> +                 -0.3241,  1.6389, -0.3148,
> +                  0.0262, -0.9593,  1.9332 ]
> +        - ct: 4939
> +          ccm: [  1.6371, -0.4490, -0.1881,
> +                 -0.2675,  1.6494, -0.3819,
> +                 -0.0245, -0.7782,  1.8026 ]
> +        - ct: 6302
> +          ccm: [  1.6401, -0.4418, -0.1984,
> +                 -0.2360,  1.7191, -0.4832,
> +                 -0.0248, -0.7221,  1.7469 ]
> +  - Adjust:
> +      gamma: 2.2
> +      contrast: 1.0
> +      saturation: 1.0
> +  - Agc:
> +...
Kieran Bingham May 8, 2026, 9:31 a.m. UTC | #3 
Quoting Barnabás Pőcze (2026-05-08 09:07:26)
> 2026. 05. 07. 18:03 keltezéssel, Javier Tia írta:
> > Add a tuning file for the OV2740 sensor calibrated from the Intel IPU6
> > AIQB binary (OV2740_CJFLE23_ADL.aiqb) shipped with the Lenovo ThinkPad
> > X1 Carbon Gen 10 (Alder Lake, JP2 module, Chicony CJFLE23 camera).
> > 
> > Black level is 0x40 at 10-bit (64 ADU), stored as the 16-bit value 4096
> > per the BlackLevel algorithm convention (value >> 8 = 16 at 8-bit scale).
> > 
> > AWB gain limits are derived from the minimum R/G and B/G chromaticities
> > across the 8 calibrated illuminants (2319 K to 6302 K), with a 10%
> > headroom margin: maxGainR=2.49, maxGainB=3.07.
> > 
> > Eight CCMs are extracted from the AIQB advanced color matrix records
> > (record id=25, float format), covering illuminants from 2319 K
> > (incandescent) to 6302 K (daylight).
> > 
> > Signed-off-by: Javier Tia <floss@jetm.me>
> > ---
> 
> This needs certain changes from https://patchwork.libcamera.org/project/libcamera/list/?series=5915,
> but I don't think this is mentioned anywhere. I believe
> 
>    git pw patch apply 26659 --no-deps
> 
> is sufficient.
> 
> After that I can confirm that it does change the image. I'm seeing a lot of "pink"
> areas with lights, but guess this is just an issue with the softisp.

https://gitlab.freedesktop.org/camera/libcamera-softisp/-/merge_requests/1
has my most up to date branch for the AWB split and saturation fixes for
that topic, and the previous version on the list has has some good
review comments this week, so I'll try and update and respin a new
posting next week.

> But I'm curious to see the sensor controls in your case, e.g. in a certain scene I have
> 
> $ v4l2-ctl -d /dev/v4l-subdev4 -L | grep -E '(exposure|analogue_gain|vertical_blanking)'
>             exposure 0x00980911 (int)    : min=4 max=1102 step=1 default=1102 value=1102 flags=has-min-max
>    vertical_blanking 0x009e0901 (int)    : min=18 max=955 step=1 default=18 value=18 flags=has-min-max
>        analogue_gain 0x009e0903 (int)    : min=128 max=1983 step=1 default=128 value=1983 flags=has-min-max
> 
> Unfortunately the vertical blanking is kept at its minimum, and thus the range of exposure
> is not particularly big, so the agc algorithm has a tendency of maxing out the exposure
> almost immediately, and then it operates with close-to-max analogue gain. I'm wondering
> if the same thing happens in your case as well?

I think we need to fix this generically in libcamera as it's currently a
pipeline handler/IPA responsibility to manage frame rate and I bet it's
not implemented correctly in simple/softISP.

I suspect only RPi and RKISP1 are anywhere close to doing the right things
here.

I think we should probably move frame rate handling (and thus blanking
control) into the CameraSensor or CameraSensorHelper so that we don't
repeat code in each IPA, and make that usable by simple/softipa.


--
Kieran
Laurent Pinchart May 8, 2026, 9:37 a.m. UTC | #4 
On Fri, May 08, 2026 at 10:31:18AM +0100, Kieran Bingham wrote:
> Quoting Barnabás Pőcze (2026-05-08 09:07:26)
> > 2026. 05. 07. 18:03 keltezéssel, Javier Tia írta:
> > > Add a tuning file for the OV2740 sensor calibrated from the Intel IPU6
> > > AIQB binary (OV2740_CJFLE23_ADL.aiqb) shipped with the Lenovo ThinkPad
> > > X1 Carbon Gen 10 (Alder Lake, JP2 module, Chicony CJFLE23 camera).
> > > 
> > > Black level is 0x40 at 10-bit (64 ADU), stored as the 16-bit value 4096
> > > per the BlackLevel algorithm convention (value >> 8 = 16 at 8-bit scale).
> > > 
> > > AWB gain limits are derived from the minimum R/G and B/G chromaticities
> > > across the 8 calibrated illuminants (2319 K to 6302 K), with a 10%
> > > headroom margin: maxGainR=2.49, maxGainB=3.07.
> > > 
> > > Eight CCMs are extracted from the AIQB advanced color matrix records
> > > (record id=25, float format), covering illuminants from 2319 K
> > > (incandescent) to 6302 K (daylight).
> > > 
> > > Signed-off-by: Javier Tia <floss@jetm.me>
> > > ---
> > 
> > This needs certain changes from https://patchwork.libcamera.org/project/libcamera/list/?series=5915,
> > but I don't think this is mentioned anywhere. I believe
> > 
> >    git pw patch apply 26659 --no-deps
> > 
> > is sufficient.
> > 
> > After that I can confirm that it does change the image. I'm seeing a lot of "pink"
> > areas with lights, but guess this is just an issue with the softisp.
> 
> https://gitlab.freedesktop.org/camera/libcamera-softisp/-/merge_requests/1
> has my most up to date branch for the AWB split and saturation fixes for
> that topic, and the previous version on the list has has some good
> review comments this week, so I'll try and update and respin a new
> posting next week.
> 
> > But I'm curious to see the sensor controls in your case, e.g. in a certain scene I have
> > 
> > $ v4l2-ctl -d /dev/v4l-subdev4 -L | grep -E '(exposure|analogue_gain|vertical_blanking)'
> >             exposure 0x00980911 (int)    : min=4 max=1102 step=1 default=1102 value=1102 flags=has-min-max
> >    vertical_blanking 0x009e0901 (int)    : min=18 max=955 step=1 default=18 value=18 flags=has-min-max
> >        analogue_gain 0x009e0903 (int)    : min=128 max=1983 step=1 default=128 value=1983 flags=has-min-max
> > 
> > Unfortunately the vertical blanking is kept at its minimum, and thus the range of exposure
> > is not particularly big, so the agc algorithm has a tendency of maxing out the exposure
> > almost immediately, and then it operates with close-to-max analogue gain. I'm wondering
> > if the same thing happens in your case as well?
> 
> I think we need to fix this generically in libcamera as it's currently a
> pipeline handler/IPA responsibility to manage frame rate and I bet it's
> not implemented correctly in simple/softISP.
> 
> I suspect only RPi and RKISP1 are anywhere close to doing the right things
> here.
> 
> I think we should probably move frame rate handling (and thus blanking
> control) into the CameraSensor or CameraSensorHelper so that we don't
> repeat code in each IPA, and make that usable by simple/softipa.

I'm not sure yet where exactly it belongs to, but it should certainly
not be duplicated everywhere. The AGC algorithm from libipa is a
candidate, CameraSensorHelper may help too but it's only meant to
provide information about camera sensors, not to implement algorithms
and heuristics.
Kieran Bingham May 8, 2026, 9:48 a.m. UTC | #5 
Quoting Laurent Pinchart (2026-05-08 10:37:30)
> On Fri, May 08, 2026 at 10:31:18AM +0100, Kieran Bingham wrote:
> > Quoting Barnabás Pőcze (2026-05-08 09:07:26)
> > > 2026. 05. 07. 18:03 keltezéssel, Javier Tia írta:
> > > > Add a tuning file for the OV2740 sensor calibrated from the Intel IPU6
> > > > AIQB binary (OV2740_CJFLE23_ADL.aiqb) shipped with the Lenovo ThinkPad
> > > > X1 Carbon Gen 10 (Alder Lake, JP2 module, Chicony CJFLE23 camera).
> > > > 
> > > > Black level is 0x40 at 10-bit (64 ADU), stored as the 16-bit value 4096
> > > > per the BlackLevel algorithm convention (value >> 8 = 16 at 8-bit scale).
> > > > 
> > > > AWB gain limits are derived from the minimum R/G and B/G chromaticities
> > > > across the 8 calibrated illuminants (2319 K to 6302 K), with a 10%
> > > > headroom margin: maxGainR=2.49, maxGainB=3.07.
> > > > 
> > > > Eight CCMs are extracted from the AIQB advanced color matrix records
> > > > (record id=25, float format), covering illuminants from 2319 K
> > > > (incandescent) to 6302 K (daylight).
> > > > 
> > > > Signed-off-by: Javier Tia <floss@jetm.me>
> > > > ---
> > > 
> > > This needs certain changes from https://patchwork.libcamera.org/project/libcamera/list/?series=5915,
> > > but I don't think this is mentioned anywhere. I believe
> > > 
> > >    git pw patch apply 26659 --no-deps
> > > 
> > > is sufficient.
> > > 
> > > After that I can confirm that it does change the image. I'm seeing a lot of "pink"
> > > areas with lights, but guess this is just an issue with the softisp.
> > 
> > https://gitlab.freedesktop.org/camera/libcamera-softisp/-/merge_requests/1
> > has my most up to date branch for the AWB split and saturation fixes for
> > that topic, and the previous version on the list has has some good
> > review comments this week, so I'll try and update and respin a new
> > posting next week.
> > 
> > > But I'm curious to see the sensor controls in your case, e.g. in a certain scene I have
> > > 
> > > $ v4l2-ctl -d /dev/v4l-subdev4 -L | grep -E '(exposure|analogue_gain|vertical_blanking)'
> > >             exposure 0x00980911 (int)    : min=4 max=1102 step=1 default=1102 value=1102 flags=has-min-max
> > >    vertical_blanking 0x009e0901 (int)    : min=18 max=955 step=1 default=18 value=18 flags=has-min-max
> > >        analogue_gain 0x009e0903 (int)    : min=128 max=1983 step=1 default=128 value=1983 flags=has-min-max
> > > 
> > > Unfortunately the vertical blanking is kept at its minimum, and thus the range of exposure
> > > is not particularly big, so the agc algorithm has a tendency of maxing out the exposure
> > > almost immediately, and then it operates with close-to-max analogue gain. I'm wondering
> > > if the same thing happens in your case as well?
> > 
> > I think we need to fix this generically in libcamera as it's currently a
> > pipeline handler/IPA responsibility to manage frame rate and I bet it's
> > not implemented correctly in simple/softISP.
> > 
> > I suspect only RPi and RKISP1 are anywhere close to doing the right things
> > here.
> > 
> > I think we should probably move frame rate handling (and thus blanking
> > control) into the CameraSensor or CameraSensorHelper so that we don't
> > repeat code in each IPA, and make that usable by simple/softipa.
> 
> I'm not sure yet where exactly it belongs to, but it should certainly
> not be duplicated everywhere. The AGC algorithm from libipa is a
> candidate, CameraSensorHelper may help too but it's only meant to
> provide information about camera sensors, not to implement algorithms
> and heuristics.

FrameRate and blanking control is an aspect that applies to the camera
regardless of whether there is any AGC algorithm.

So I don't beleive this belongs in the AGC components. AGC should 'read'
the limits from the CameraSensor{,Helper} but they can't change it, only
work within the available parameters.

--
Kieran

> 
> -- 
> Regards,
> 
> Laurent Pinchart
Barnabás Pőcze May 8, 2026, 10:35 a.m. UTC | #6 
2026. 05. 08. 11:31 keltezéssel, Kieran Bingham írta:
> Quoting Barnabás Pőcze (2026-05-08 09:07:26)
>> 2026. 05. 07. 18:03 keltezéssel, Javier Tia írta:
>>> Add a tuning file for the OV2740 sensor calibrated from the Intel IPU6
>>> AIQB binary (OV2740_CJFLE23_ADL.aiqb) shipped with the Lenovo ThinkPad
>>> X1 Carbon Gen 10 (Alder Lake, JP2 module, Chicony CJFLE23 camera).
>>>
>>> Black level is 0x40 at 10-bit (64 ADU), stored as the 16-bit value 4096
>>> per the BlackLevel algorithm convention (value >> 8 = 16 at 8-bit scale).
>>>
>>> AWB gain limits are derived from the minimum R/G and B/G chromaticities
>>> across the 8 calibrated illuminants (2319 K to 6302 K), with a 10%
>>> headroom margin: maxGainR=2.49, maxGainB=3.07.
>>>
>>> Eight CCMs are extracted from the AIQB advanced color matrix records
>>> (record id=25, float format), covering illuminants from 2319 K
>>> (incandescent) to 6302 K (daylight).
>>>
>>> Signed-off-by: Javier Tia <floss@jetm.me>
>>> ---
>>
>> This needs certain changes from https://patchwork.libcamera.org/project/libcamera/list/?series=5915,
>> but I don't think this is mentioned anywhere. I believe
>>
>>     git pw patch apply 26659 --no-deps
>>
>> is sufficient.
>>
>> After that I can confirm that it does change the image. I'm seeing a lot of "pink"
>> areas with lights, but guess this is just an issue with the softisp.
> 
> https://gitlab.freedesktop.org/camera/libcamera-softisp/-/merge_requests/1

The awb changes here are not compatible with that, so I removed them.
After a quick try, I think I can say it improves the image, there do
not appear to be those pink saturated regions.


> has my most up to date branch for the AWB split and saturation fixes for
> that topic, and the previous version on the list has has some good
> review comments this week, so I'll try and update and respin a new
> posting next week.
> 
>> But I'm curious to see the sensor controls in your case, e.g. in a certain scene I have
>>
>> $ v4l2-ctl -d /dev/v4l-subdev4 -L | grep -E '(exposure|analogue_gain|vertical_blanking)'
>>              exposure 0x00980911 (int)    : min=4 max=1102 step=1 default=1102 value=1102 flags=has-min-max
>>     vertical_blanking 0x009e0901 (int)    : min=18 max=955 step=1 default=18 value=18 flags=has-min-max
>>         analogue_gain 0x009e0903 (int)    : min=128 max=1983 step=1 default=128 value=1983 flags=has-min-max
>>
>> Unfortunately the vertical blanking is kept at its minimum, and thus the range of exposure
>> is not particularly big, so the agc algorithm has a tendency of maxing out the exposure
>> almost immediately, and then it operates with close-to-max analogue gain. I'm wondering
>> if the same thing happens in your case as well?
> 
> I think we need to fix this generically in libcamera as it's currently a
> pipeline handler/IPA responsibility to manage frame rate and I bet it's
> not implemented correctly in simple/softISP.

I believe vertical blanking is not set at all. But even if I set it beforehand,
it gets reset somewhere along the way, so the sensor's `ControlInfoMap` will
store these lower exposure limits.


> 
> I suspect only RPi and RKISP1 are anywhere close to doing the right things
> here.
> 
> I think we should probably move frame rate handling (and thus blanking
> control) into the CameraSensor or CameraSensorHelper so that we don't
> repeat code in each IPA, and make that usable by simple/softipa.
> 
> 
> --
> Kieran
Javier Tia May 8, 2026, 4:55 p.m. UTC | #7 
Hi Hans,

On 7-May-26 19:00, johannes.goede@oss.qualcomm.com wrote:
> Oh, you extracted these from the AIQB file that is very useful.
> Can you share a script or some AIQB format documentation so we can
> do the same for other sensors ?

Sure. The AIQB files come from intel/ipu6-camera-hal on GitHub
(config/linux/ipu6ep/). The format is Intel's ia_mkn_record_header
chain starting at offset 0x50, where each record carries CCMs,
sensitivity, and chromaticity data keyed by name_id.

Posted v2 of this series with the parse_aiqb.py script as patch 3/3.
It walks the record chain and prints a ready-to-use libcamera YAML
block (CCMs, AWB gain limits, black level scaffolding):

  python3 utils/tuning/parse_aiqb.py OV2740_CJFLE23_ADL.aiqb

I also wrote up the format details and the full calibration workflow
on my blog, which Kieran might find useful too:

  https://jetm.github.io/blog/posts/ipu6-aiqb-calibration/

So far the script has only been exercised on the OV2740 ADL AIQB.
Other sensors should work if they use record name_id 25 (float CCMs
with CCT in Kelvin) or 18 (integer CCMs); the docstring has the
caveats. Black level still needs to come from the datasheet or kernel
driver - I have not found a reliable place for it inside the AIQB
chain.

Best,
Javier
Javier Tia May 8, 2026, 5:05 p.m. UTC | #8 
Hi Barnabás,

On Thu, May 08, 2026 at 12:35:55PM +0200, Barnabás Pőcze wrote:
> 2026. 05. 08. 11:31 keltezéssel, Kieran Bingham írta:
> > https://gitlab.freedesktop.org/camera/libcamera-softisp/-/merge_requests/1
>
> The awb changes here are not compatible with that, so I removed them.
> After a quick try, I think I can say it improves the image, there do
> not appear to be those pink saturated regions.

Glad to hear that confirms it - thanks for testing both branches.

> >> $ v4l2-ctl -d /dev/v4l-subdev4 -L | grep -E '(exposure|analogue_gain|vertical_blanking)'
> >>              exposure 0x00980911 (int)    : min=4 max=1102 step=1 default=1102 value=1102 flags=has-min-max
> >>     vertical_blanking 0x009e0901 (int)    : min=18 max=955 step=1 default=18 value=18 flags=has-min-max
> >>         analogue_gain 0x009e0903 (int)    : min=128 max=1983 step=1 default=128 value=1983 flags=has-min-max

Identical limits on my end - same exposure ceiling (1102) and vertical
blanking stuck at minimum. My gain happened to be at 128 (minimum) in
the brighter scene I tested:

$ v4l2-ctl -d /dev/v4l-subdev4 -L | grep -E '(exposure|analogue_gain|vertical_blanking)'
            exposure 0x00980911 (int)    : min=4 max=1102 step=1 default=1102 value=1102 flags=has-min-max
   vertical_blanking 0x009e0901 (int)    : min=18 max=955 step=1 default=18 value=18 flags=has-min-max
       analogue_gain 0x009e0903 (int)    : min=128 max=1983 step=1 default=128 value=128 flags=has-min-max

> > I think we need to fix this generically in libcamera as it's currently a
> > pipeline handler/IPA responsibility to manage frame rate and I bet it's
> > not implemented correctly in simple/softISP.
>
> I believe vertical blanking is not set at all. But even if I set it beforehand,
> it gets reset somewhere along the way, so the sensor's `ControlInfoMap` will
> store these lower exposure limits.

That matches what I see. The ControlInfoMap caching the lower limits
explains why the AGC ceiling stays low even after probing. Agree this
needs a generic fix as Kieran described, with the sensor/helper layer
owning blanking and the IPA only reading the resulting bounds.

Best,
Javier
Javier Tia May 8, 2026, 5:05 p.m. UTC | #9 
Hi Kieran,

On Fri, May 08, 2026 at 10:31:18AM +0100, Kieran Bingham wrote:
> https://gitlab.freedesktop.org/camera/libcamera-softisp/-/merge_requests/1
> has my most up to date branch for the AWB split and saturation fixes for
> that topic, and the previous version on the list has has some good
> review comments this week, so I'll try and update and respin a new
> posting next week.

Great, looking forward to it.

On the AIQB extraction: the format is a chain of ia_mkn_record_header
structures from Intel's ipu6-camera-hal[1]. The header definitions
there are enough to identify the record IDs (id=25 for float CCMs with
CCT in Kelvin, id=18 for integer CCMs, id=2 for general params). From
there it is straightforward to walk the chain and extract calibration
data.

I am sending v2 of the series with the parse_aiqb.py script as patch
3/3, and wrote up the format details and full calibration workflow on
my blog:

  https://jetm.github.io/blog/posts/ipu6-aiqb-calibration/

[1] https://github.com/intel/ipu6-camera-hal

Best,
Javier
Javier Tia May 9, 2026, 8:13 p.m. UTC | #10 
Hi Kieran,

I saw your note about migrating the simple IPA to use the common
libipa/awb algorithm with CCT-indexed predetermined balances. Is that
something you are already working on, or is there a piece I could pick
up? I am thinking the SoftAwbStats wrapper (adapting SwIspStats to the
AwbStats interface) or extending parse_aiqb.py to emit a
CCT-indexed colourGains curve alongside the CCMs.

Happy to wait and test once you post a series if you have this in hand.
Laurent Pinchart May 10, 2026, 5:03 p.m. UTC | #11 
On Sat, May 09, 2026 at 02:13:46PM -0600, Javier Tia wrote:
> Hi Kieran,
> 
> I saw your note about migrating the simple IPA to use the common
> libipa/awb algorithm with CCT-indexed predetermined balances. Is that
> something you are already working on, or is there a piece I could pick
> up?

https://patchwork.libcamera.org/project/libcamera/list/?series=5874

> I am thinking the SoftAwbStats wrapper (adapting SwIspStats to the
> AwbStats interface) or extending parse_aiqb.py to emit a
> CCT-indexed colourGains curve alongside the CCMs.
> 
> Happy to wait and test once you post a series if you have this in hand.
Javier Tia May 11, 2026, 4:33 p.m. UTC | #12 
Hi Laurent,

Thanks for the pointer.

On Sun, May 10, 2026 at 17:03:27 +0000, Laurent Pinchart wrote:
> > I saw your note about migrating the simple IPA to use the common
> > libipa/awb algorithm with CCT-indexed predetermined balances. Is that
> > something you are already working on, or is there a piece I could pick
> > up?
>
> https://patchwork.libcamera.org/project/libcamera/list/?series=5874

Got it - I will track series 5874 and rebase the OV2740 tuning on top
once it lands. The v3 OV2740 YAML I'm sending alongside this reply
already carries a colourGains block in the AwbGrey form, behind a
comment noting it has no effect until 5874 merges, so the file should
slot in without further changes.

Happy to test 5874 on the X1 Carbon hardware when you would like a
second set of eyes on the simple-IPA path.

Patch
diff mbox series 

diff --git a/src/ipa/simple/data/meson.build b/src/ipa/simple/data/meson.build
index 92795ee4..e3e4de74 100644
--- a/src/ipa/simple/data/meson.build
+++ b/src/ipa/simple/data/meson.build
@@ -1,6 +1,7 @@ 
 # SPDX-License-Identifier: CC0-1.0
 
 conf_files = files([
+    'ov2740.yaml',
     'uncalibrated.yaml',
 ])
 
diff --git a/src/ipa/simple/data/ov2740.yaml b/src/ipa/simple/data/ov2740.yaml
new file mode 100644
index 00000000..da7e1efe
--- /dev/null
+++ b/src/ipa/simple/data/ov2740.yaml
@@ -0,0 +1,52 @@ 
+# SPDX-License-Identifier: CC0-1.0
+# Calibrated from OV2740_CJFLE23_ADL.aiqb (Lenovo JP2 module, IPU6 ADL)
+%YAML 1.1
+---
+version: 1
+algorithms:
+  - BlackLevel:
+      blackLevel: 4096
+  - Awb:
+      maxGainR: 2.49
+      maxGainB: 3.07
+      speed: 0.25
+  - Ccm:
+      ccms:
+        - ct: 2319
+          ccm: [  1.5938, -0.1714, -0.4224,
+                 -0.6134,  1.9612, -0.3478,
+                 -0.4710, -1.8500,  3.3210 ]
+        - ct: 2854
+          ccm: [  1.6119, -0.3132, -0.2987,
+                 -0.4418,  1.8227, -0.3809,
+                 -0.1017, -1.3958,  2.4975 ]
+        - ct: 2884
+          ccm: [  1.7739, -0.6655, -0.1085,
+                 -0.4113,  1.6619, -0.2506,
+                 -0.0150, -1.1661,  2.1811 ]
+        - ct: 3239
+          ccm: [  1.8298, -0.6636, -0.1662,
+                 -0.4086,  1.7373, -0.3287,
+                 -0.0500, -1.0836,  2.1335 ]
+        - ct: 3865
+          ccm: [  1.8836, -0.7430, -0.1406,
+                 -0.3653,  1.7000, -0.3348,
+                 -0.0542, -0.8442,  1.8984 ]
+        - ct: 4136
+          ccm: [  1.9043, -0.8348, -0.0695,
+                 -0.3241,  1.6389, -0.3148,
+                  0.0262, -0.9593,  1.9332 ]
+        - ct: 4939
+          ccm: [  1.6371, -0.4490, -0.1881,
+                 -0.2675,  1.6494, -0.3819,
+                 -0.0245, -0.7782,  1.8026 ]
+        - ct: 6302
+          ccm: [  1.6401, -0.4418, -0.1984,
+                 -0.2360,  1.7191, -0.4832,
+                 -0.0248, -0.7221,  1.7469 ]
+  - Adjust:
+      gamma: 2.2
+      contrast: 1.0
+      saturation: 1.0
+  - Agc:
+...