| Message ID | c6a502b4-4193-40a6-8cfa-62a19bfb5011@opendigital.cc |
|---|---|
| State | New |
| Headers | show |
| Series |
|
| Related | show |
Hi Stuart On Wed, Mar 25, 2026 at 10:31:45AM +0100, Stuart J Mackintosh wrote: > From ae84819121c206dd352c5e24942c1170ff7c6819 Mon Sep 17 00:00:00 2001 > From: Stuart J Mackintosh <sjm@opendigital.cc> > Date: Wed, 25 Mar 2026 10:19:05 +0100 > Subject: [PATCH] ipa: libipa: camera_sensor_helper: Add OV01A10 There is something going on with the way you submitted the patch as 'git am' is not able to apply it. it seem you copied the patch in an email message ? Could you check Documentation/contributing.rst and use git-send-email ? > > Add a CameraSensorHelper for the OmniVision OV01A10 image sensor, > used in Dell XPS 13 and other laptops with the Intel IPU6 camera > subsystem. > > The analogue gain model is derived from the V4L2 control range > reported by the sensor driver. The minimum gain code is 256 with > a step of 1, giving the linear model: > > gain = code / 256 Following this line of reasoning, the max gain code in the driver is said to be 0x3fff which would give a max gain of x64 which seems quite high (however I surely can't rule out it is correct). > > This corresponds to AnalogueGainLinear{ 1, 0, 0, 256 }, consistent > with the pattern used by other OmniVision sensors in this file. Are we going by reasoning just looking at the min/max ? Aren't there other sources that migh confirm the analogue gain model is actually a linear one ? Have you tried manually increasing the analogue gain and validate you get a linear response ? > > The black level of 0x40 at 10 bits (4096 scaled to 16 bits) was > confirmed by dark frame measurement with the lens covered. Great > > Without this helper, libcamera's AGC algorithm cannot convert between > gain codes and real gain values, causing auto-exposure oscillation and > the following warning: > > IPASoft: Failed to create camera sensor helper for ov01a10 > > Signed-off-by: Stuart J Mackintosh <sjm@opendigital.cc> > --- > Note: Colour calibration (CCM) for this sensor is not yet available. > A tuning file exists at /usr/share/libcamera/ipa/simple/ov01a10.yaml > but contains no calibrated parameters. This is deferred to a follow-up > contribution once calibration data is available. That would be nice! Do you plan to generate the CCM values yourself ? Thanks j > > src/ipa/libipa/camera_sensor_helper.cpp | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > diff --git a/src/ipa/libipa/camera_sensor_helper.cpp > b/src/ipa/libipa/camera_sensor_helper.cpp > index e3e3e535..72466867 100644 > --- a/src/ipa/libipa/camera_sensor_helper.cpp > +++ b/src/ipa/libipa/camera_sensor_helper.cpp > @@ -653,6 +653,18 @@ public: > }; > REGISTER_CAMERA_SENSOR_HELPER("imx708", CameraSensorHelperImx708) > +class CameraSensorHelperOv01a10 : public CameraSensorHelper > +{ > +public: > + CameraSensorHelperOv01a10() > + { > + /* From dark frame measurement: 0x40 at 10bits. */ > + blackLevel_ = 4096; > + gain_ = AnalogueGainLinear{ 1, 0, 0, 256 }; > + } > +}; > +REGISTER_CAMERA_SENSOR_HELPER("ov01a10", CameraSensorHelperOv01a10) > + > class CameraSensorHelperOv2685 : public CameraSensorHelper > { > public: > -- > 2.47.3 > > > -- > Stuart J Mackintosh > > Business & digital technology consultant > > Open Digital Consulting Co > > Open Digital Consulting Co Logo > > UK: +44 20 36 27 90 40 > > FR: +33 1 89 48 00 40 > > Email: sjm@opendigital.cc <mailto:sjm@opendigital.cc> > > Web: https://opendigital.cc <https://opendigital.cc> > > IM: xmpp:sjm@opendigital.cc <xmpp:sjm@opendigital.cc> >
Hi Jacopo, On 25/03/2026 17:02, Jacopo Mondi wrote: > Hi Stuart > > On Wed, Mar 25, 2026 at 10:31:45AM +0100, Stuart J Mackintosh wrote: >> From ae84819121c206dd352c5e24942c1170ff7c6819 Mon Sep 17 00:00:00 2001 >> From: Stuart J Mackintosh<sjm@opendigital.cc> >> Date: Wed, 25 Mar 2026 10:19:05 +0100 >> Subject: [PATCH] ipa: libipa: camera_sensor_helper: Add OV01A10 > There is something going on with the way you submitted the patch > as 'git am' is not able to apply it. it seem you copied the patch in > an email message ? > > Could you check Documentation/contributing.rst and use git-send-email ? Yes - I haven't used this method before, I am used to making PR's, so learning on this one. I will configure |git send-email| and resubmit. >> Add a CameraSensorHelper for the OmniVision OV01A10 image sensor, >> used in Dell XPS 13 and other laptops with the Intel IPU6 camera >> subsystem. >> >> The analogue gain model is derived from the V4L2 control range >> reported by the sensor driver. The minimum gain code is 256 with >> a step of 1, giving the linear model: >> >> gain = code / 256 > Following this line of reasoning, the max gain code in the driver is > said to be 0x3fff which would give a max gain of x64 which seems quite > high (however I surely can't rule out it is correct). The upstream kernel driver defines |OV01A10_ANAL_GAIN_MAX = 0x3fff| = 16383, giving a maximum of 63.99x. My running kernel (6.12.74+deb13) reports max=65535 via V4L2, which appears to be an older driver version predating a recent fix. The gain model is correct regardless - only the clamp value differs.(AI) >> This corresponds to AnalogueGainLinear{ 1, 0, 0, 256 }, consistent >> with the pattern used by other OmniVision sensors in this file. > Are we going by reasoning just looking at the min/max ? Aren't > there other sources that migh confirm the analogue gain model is > actually a linear one ? > > Have you tried manually increasing the analogue gain and validate you > get a linear response ? The kernel driver writes the analogue gain register directly without scaling: |cci_write(ov01a10->regmap, OV01A10_REG_ANALOG_GAIN, ctrl->val, NULL)|. The minimum |OV01A10_ANAL_GAIN_MIN = 0x100| = 256 represents unity gain, consistent with Q8 fixed-point where |gain = register_value / 256|. This is the same fixed-point convention used for digital gain, where |OV01A10_DGTL_GAIN_DEFAULT = 1024| represents unity with a 6-bit fractional part. (AI) >> Without this helper, libcamera's AGC algorithm cannot convert between >> gain codes and real gain values, causing auto-exposure oscillation and >> the following warning: >> >> IPASoft: Failed to create camera sensor helper for ov01a10 >> >> Signed-off-by: Stuart J Mackintosh<sjm@opendigital.cc> >> --- >> Note: Colour calibration (CCM) for this sensor is not yet available. >> A tuning file exists at /usr/share/libcamera/ipa/simple/ov01a10.yaml >> but contains no calibrated parameters. This is deferred to a follow-up >> contribution once calibration data is available. > That would be nice! Do you plan to generate the CCM values yourself ? Yes, that is my intention once I have worked out a reasonable calibration approach. A little more background - I am using a Dell XPS and it generally works with Debian, the biggest problem being this camera so I am committed to chipping away at it until it is usable. This patch already makes a big difference and I am keen to get the fixes upstream. I am using AI to assist this work and marked the generated statements with (AI); I am not CPP experienced. What would help me is to know the recommended way to capture frames at a fixed analogue gain value on an IPU6 platform, bypassing the AGC, to help validate the gain parameters? Any guidance that you might have with diagnostics is welcome. Best wishes, Stuart. > > Thanks > j > >> src/ipa/libipa/camera_sensor_helper.cpp | 12 ++++++++++++ >> 1 file changed, 12 insertions(+) >> >> diff --git a/src/ipa/libipa/camera_sensor_helper.cpp >> b/src/ipa/libipa/camera_sensor_helper.cpp >> index e3e3e535..72466867 100644 >> --- a/src/ipa/libipa/camera_sensor_helper.cpp >> +++ b/src/ipa/libipa/camera_sensor_helper.cpp >> @@ -653,6 +653,18 @@ public: >> }; >> REGISTER_CAMERA_SENSOR_HELPER("imx708", CameraSensorHelperImx708) >> +class CameraSensorHelperOv01a10 : public CameraSensorHelper >> +{ >> +public: >> + CameraSensorHelperOv01a10() >> + { >> + /* From dark frame measurement: 0x40 at 10bits. */ >> + blackLevel_ = 4096; >> + gain_ = AnalogueGainLinear{ 1, 0, 0, 256 }; >> + } >> +}; >> +REGISTER_CAMERA_SENSOR_HELPER("ov01a10", CameraSensorHelperOv01a10) >> + >> class CameraSensorHelperOv2685 : public CameraSensorHelper >> { >> public: >> -- >> 2.47.3 >> >> >> -- >> Stuart J Mackintosh >> >> Business & digital technology consultant >> >> Open Digital Consulting Co >> >> Open Digital Consulting Co Logo >> >> UK: +44 20 36 27 90 40 >> >> FR: +33 1 89 48 00 40 >> >> Email:sjm@opendigital.cc <mailto:sjm@opendigital.cc> >> >> Web:https://opendigital.cc <https://opendigital.cc> >> >> IM:xmpp:sjm@opendigital.cc <xmpp:sjm@opendigital.cc> >>
Hi Stuart, Jacopo, Stuart, thank you for your interest in this. When I had a XPS 13 on loan I've made a set of calibration images of its sensor: https://fedorapeople.org/~jwrdegoede/sensor-calibration/dell-xps13-9320-ov01a10/ You can use those with the rkisp1.py found under utils/tuning/rkisp1.py to try and generate a CCM for the camera-module. Note at the moment there are some know issues with the CCM handling in the software ISP which we are working on fixing. So you could give this a try, but you will likely get neon-purple colors in brightly lit areas. This is a known issue. On 25-Mar-26 17:02, Jacopo Mondi wrote: > Hi Stuart > > On Wed, Mar 25, 2026 at 10:31:45AM +0100, Stuart J Mackintosh wrote: >> From ae84819121c206dd352c5e24942c1170ff7c6819 Mon Sep 17 00:00:00 2001 >> From: Stuart J Mackintosh <sjm@opendigital.cc> >> Date: Wed, 25 Mar 2026 10:19:05 +0100 >> Subject: [PATCH] ipa: libipa: camera_sensor_helper: Add OV01A10 > > There is something going on with the way you submitted the patch > as 'git am' is not able to apply it. it seem you copied the patch in > an email message ? > > Could you check Documentation/contributing.rst and use git-send-email ? > >> >> Add a CameraSensorHelper for the OmniVision OV01A10 image sensor, >> used in Dell XPS 13 and other laptops with the Intel IPU6 camera >> subsystem. >> >> The analogue gain model is derived from the V4L2 control range >> reported by the sensor driver. The minimum gain code is 256 with >> a step of 1, giving the linear model: >> >> gain = code / 256 > > Following this line of reasoning, the max gain code in the driver is > said to be 0x3fff which would give a max gain of x64 which seems quite > high (however I surely can't rule out it is correct). I think this is a driver bug, almost all ov-sensors seem to have a fractional gain with 4 bits for the non fractional parts and either 7 or 8 bits for the fraction. With the non-fractional part starting at 1 for 1.0 . So based on that and other ov sensor drivers I think the driver is buggy and the maximum should be 0xf80, 0xf80 rather then 0xfff because, well that is what other omnivision sensor drivers do, I guess something goes funky in the hw for gains > 15.5 ? A maximum gain of 15.5 sounds much more realistic IMHO. So I think we need to fix the kernel driver to make the maximum 0x780. >> This corresponds to AnalogueGainLinear{ 1, 0, 0, 256 }, consistent >> with the pattern used by other OmniVision sensors in this file. > > Are we going by reasoning just looking at the min/max ? Aren't > there other sources that migh confirm the analogue gain model is > actually a linear one ? > > Have you tried manually increasing the analogue gain and validate you > get a linear response ? When I did the calibration images under controlled lighting conditions I checked the influence of the gain control on the 18% grey square (monitoring that square with camshark) of the macbeth chart and it seemed linear. This also matches other known ov sensors. Regards, Hans p.s. Stuart many of us have a wariness about over-use of AI, often just throwing a lot of things at the wall and seeing what looks like it might work, without rhyme or reason. Or what people call AI slop. Note this first submission does not seem to be AI slop at all! And your disclosure of using of AI is appreciated but please be careful with your use of AI.
On 25/03/2026 18:44, johannes.goede@oss.qualcomm.com wrote: > Hi Stuart, Jacopo, > > Stuart, thank you for your interest in this. > > When I had a XPS 13 on loan I've made a set of calibration images > of its sensor: > > https://fedorapeople.org/~jwrdegoede/sensor-calibration/dell-xps13-9320-ov01a10/ > > You can use those with the rkisp1.py found under utils/tuning/rkisp1.py > to try and generate a CCM for the camera-module. Thanks Hans - yes, this is really useful, I will see if I can generate CCM. > Note at the moment there are some know issues with the CCM handling > in the software ISP which we are working on fixing. > > So you could give this a try, but you will likely get neon-purple > colors in brightly lit areas. This is a known issue. Noted - that still is likely better than what I have now. > On 25-Mar-26 17:02, Jacopo Mondi wrote: >> Hi Stuart >> >> On Wed, Mar 25, 2026 at 10:31:45AM +0100, Stuart J Mackintosh wrote: >>> From ae84819121c206dd352c5e24942c1170ff7c6819 Mon Sep 17 00:00:00 2001 >>> From: Stuart J Mackintosh<sjm@opendigital.cc> >>> Date: Wed, 25 Mar 2026 10:19:05 +0100 >>> Subject: [PATCH] ipa: libipa: camera_sensor_helper: Add OV01A10 >> There is something going on with the way you submitted the patch >> as 'git am' is not able to apply it. it seem you copied the patch in >> an email message ? >> >> Could you check Documentation/contributing.rst and use git-send-email ? >> >>> Add a CameraSensorHelper for the OmniVision OV01A10 image sensor, >>> used in Dell XPS 13 and other laptops with the Intel IPU6 camera >>> subsystem. >>> >>> The analogue gain model is derived from the V4L2 control range >>> reported by the sensor driver. The minimum gain code is 256 with >>> a step of 1, giving the linear model: >>> >>> gain = code / 256 >> Following this line of reasoning, the max gain code in the driver is >> said to be 0x3fff which would give a max gain of x64 which seems quite >> high (however I surely can't rule out it is correct). > I think this is a driver bug, almost all ov-sensors seem to have > a fractional gain with 4 bits for the non fractional parts > and either 7 or 8 bits for the fraction. With the non-fractional > part starting at 1 for 1.0 . > > So based on that and other ov sensor drivers I think the driver > is buggy and the maximum should be 0xf80, 0xf80 rather then 0xfff > because, well that is what other omnivision sensor drivers do, > I guess something goes funky in the hw for gains > 15.5 ? > > A maximum gain of 15.5 sounds much more realistic IMHO. > > So I think we need to fix the kernel driver to make the maximum > 0x780. That correlates with my observations and will see if I can get a kernel driver fix submitted to fix to cap the maximum at 0x780. The sensor helper patch itself is unaffected as it only defines the gain formula, not the clamp value (AI). >>> This corresponds to AnalogueGainLinear{ 1, 0, 0, 256 }, consistent >>> with the pattern used by other OmniVision sensors in this file. >> Are we going by reasoning just looking at the min/max ? Aren't >> there other sources that migh confirm the analogue gain model is >> actually a linear one ? >>> Have you tried manually increasing the analogue gain and validate you >> get a linear response ? > When I did the calibration images under controlled lighting conditions > I checked the influence of the gain control on the 18% grey square > (monitoring that square with camshark) of the macbeth chart and it > seemed linear. This also matches other known ov sensors. Thank you for confirming the linearity. This answers the question raised by Jacopo and supports the gain model in the patch (AI). > p.s. > > Stuart many of us have a wariness about over-use of AI, often just > throwing a lot of things at the wall and seeing what looks like it > might work, without rhyme or reason. Or what people call AI slop. > > Note this first submission does not seem to be AI slop at all! AI is neither artificial or intelligent, so it isn't AI slop but human slop. Like plastic, it is invaluable in many places but unhealthy if it is used for everything. > And your disclosure of using of AI is appreciated but please be > careful with your use of AI. I work with various Open Source foundations and working on the development of AI policies. Apart from etiquette / contributor problems (quality,quantity,volume) and security, the main issue is licences and the ambiguity of provenance. It is a valuable tool that requires careful handling. Best wishes, Stuart. > > > >
Hi Stuart On Wed, Mar 25, 2026 at 05:28:14PM +0100, Stuart J Mackintosh wrote: > Hi Jacopo, > > On 25/03/2026 17:02, Jacopo Mondi wrote: > > Hi Stuart > > > > On Wed, Mar 25, 2026 at 10:31:45AM +0100, Stuart J Mackintosh wrote: > > > From ae84819121c206dd352c5e24942c1170ff7c6819 Mon Sep 17 00:00:00 2001 > > > From: Stuart J Mackintosh<sjm@opendigital.cc> > > > Date: Wed, 25 Mar 2026 10:19:05 +0100 > > > Subject: [PATCH] ipa: libipa: camera_sensor_helper: Add OV01A10 > > There is something going on with the way you submitted the patch > > as 'git am' is not able to apply it. it seem you copied the patch in > > an email message ? > > > > Could you check Documentation/contributing.rst and use git-send-email ? > > Yes - I haven't used this method before, I am used to making PR's, so > learning on this one. I will configure |git send-email| and resubmit. > > > > Add a CameraSensorHelper for the OmniVision OV01A10 image sensor, > > > used in Dell XPS 13 and other laptops with the Intel IPU6 camera > > > subsystem. > > > > > > The analogue gain model is derived from the V4L2 control range > > > reported by the sensor driver. The minimum gain code is 256 with > > > a step of 1, giving the linear model: > > > > > > gain = code / 256 > > Following this line of reasoning, the max gain code in the driver is > > said to be 0x3fff which would give a max gain of x64 which seems quite > > high (however I surely can't rule out it is correct). > > The upstream kernel driver defines |OV01A10_ANAL_GAIN_MAX = 0x3fff| = 16383, > giving a maximum of 63.99x. My running kernel (6.12.74+deb13) reports > max=65535 via V4L2, which appears to be an older driver version predating a > recent fix. The gain model is correct regardless - only the clamp value > differs.(AI) > Yes, the max gain has been changed by Hans in 109e0feacaeca5ec2dd71d7d17c73232ce5cbddc "media: i2c: ov01a10: Fix analogue gain range" However, this still is this part of the commit message which puzzels me The minimum gain of 0x100 is correct. Setting bits 8-11 to 0x0 results in the same gain values as setting these bits to 0x1, with bits 0-7 still increasing the gain when going from 0x000 - 0x0ff in the exact same range as when going from 0x100 - 0x1ff. I don't get what "Setting bits 8-11 to 0x0 results n the same gain values as setting these bits to 0x1" part. I should ask Hans > > > This corresponds to AnalogueGainLinear{ 1, 0, 0, 256 }, consistent > > > with the pattern used by other OmniVision sensors in this file. > > Are we going by reasoning just looking at the min/max ? Aren't > > there other sources that migh confirm the analogue gain model is > > actually a linear one ? > > > > Have you tried manually increasing the analogue gain and validate you > > get a linear response ? > > The kernel driver writes the analogue gain register directly without > scaling: |cci_write(ov01a10->regmap, OV01A10_REG_ANALOG_GAIN, ctrl->val, > NULL)|. The minimum |OV01A10_ANAL_GAIN_MIN = 0x100| = 256 represents unity > gain, consistent with Q8 fixed-point where |gain = register_value / 256|. > This is the same fixed-point convention used for digital gain, where > |OV01A10_DGTL_GAIN_DEFAULT = 1024| represents unity with a 6-bit fractional > part. (AI) This almost make sense, if max is 0x3fff and x1 = 0100 we're looking at a register in Q6.8 format. Howver the fact writes the value unscaled doesn't mean anything, userspace is expected to do the coversion/scaling/whatever between the gain value and the gain code > > > > Without this helper, libcamera's AGC algorithm cannot convert between > > > gain codes and real gain values, causing auto-exposure oscillation and > > > the following warning: > > > > > > IPASoft: Failed to create camera sensor helper for ov01a10 > > > > > > Signed-off-by: Stuart J Mackintosh<sjm@opendigital.cc> > > > --- > > > Note: Colour calibration (CCM) for this sensor is not yet available. > > > A tuning file exists at /usr/share/libcamera/ipa/simple/ov01a10.yaml > > > but contains no calibrated parameters. This is deferred to a follow-up > > > contribution once calibration data is available. > > That would be nice! Do you plan to generate the CCM values yourself ? > > Yes, that is my intention once I have worked out a reasonable calibration > approach. > > A little more background - I am using a Dell XPS and it generally works with > Debian, the biggest problem being this camera so I am committed to chipping > away at it until it is usable. This patch already makes a big difference and > I am keen to get the fixes upstream. I am using AI to assist this work and > marked the generated statements with (AI); I am not CPP experienced. Thanks for pointing it out > > What would help me is to know the recommended way to capture frames at a > fixed analogue gain value on an IPU6 platform, bypassing the AGC, to help > validate the gain parameters? Any guidance that you might have with > diagnostics is welcome. Not an expert of softIsp and I don't know what controls it offers you but I think using camshark is the easiest way. Point your camera to some grey background where the RGB components are almost balanced. Disable AEGC and manually increase the analogue gain starting from 1x, the response in brightness you get should be linear if your model is correct. Don't expect perfect results but you should be able to see if you have big jumps in brightness that do not corresponds to a linear increment of the gain value. > > Best wishes, > > Stuart. > > > > > > Thanks > > j > > > > > src/ipa/libipa/camera_sensor_helper.cpp | 12 ++++++++++++ > > > 1 file changed, 12 insertions(+) > > > > > > diff --git a/src/ipa/libipa/camera_sensor_helper.cpp > > > b/src/ipa/libipa/camera_sensor_helper.cpp > > > index e3e3e535..72466867 100644 > > > --- a/src/ipa/libipa/camera_sensor_helper.cpp > > > +++ b/src/ipa/libipa/camera_sensor_helper.cpp > > > @@ -653,6 +653,18 @@ public: > > > }; > > > REGISTER_CAMERA_SENSOR_HELPER("imx708", CameraSensorHelperImx708) > > > +class CameraSensorHelperOv01a10 : public CameraSensorHelper > > > +{ > > > +public: > > > + CameraSensorHelperOv01a10() > > > + { > > > + /* From dark frame measurement: 0x40 at 10bits. */ > > > + blackLevel_ = 4096; > > > + gain_ = AnalogueGainLinear{ 1, 0, 0, 256 }; > > > + } > > > +}; > > > +REGISTER_CAMERA_SENSOR_HELPER("ov01a10", CameraSensorHelperOv01a10) > > > + > > > class CameraSensorHelperOv2685 : public CameraSensorHelper > > > { > > > public: > > > -- > > > 2.47.3 > > > > > > > > > -- > > > Stuart J Mackintosh > > > > > > Business & digital technology consultant > > > > > > Open Digital Consulting Co > > > > > > Open Digital Consulting Co Logo > > > > > > UK: +44 20 36 27 90 40 > > > > > > FR: +33 1 89 48 00 40 > > > > > > Email:sjm@opendigital.cc <mailto:sjm@opendigital.cc> > > > > > > Web:https://opendigital.cc <https://opendigital.cc> > > > > > > IM:xmpp:sjm@opendigital.cc <xmpp:sjm@opendigital.cc> > > > > -- > > Stuart J Mackintosh > > Business & digital technology consultant > > Open Digital Consulting Co > > Open Digital Consulting Co Logo > > UK: +44 20 36 27 90 40 > > FR: +33 1 89 48 00 40 > > Email: sjm@opendigital.cc > > Web: https://opendigital.cc > > IM: xmpp:sjm@opendigital.cc
Hi Hans On Wed, Mar 25, 2026 at 06:44:53PM +0100, johannes.goede@oss.qualcomm.com wrote: > Hi Stuart, Jacopo, > > Stuart, thank you for your interest in this. > > When I had a XPS 13 on loan I've made a set of calibration images > of its sensor: > > https://fedorapeople.org/~jwrdegoede/sensor-calibration/dell-xps13-9320-ov01a10/ > > You can use those with the rkisp1.py found under utils/tuning/rkisp1.py > to try and generate a CCM for the camera-module. > > Note at the moment there are some know issues with the CCM handling > in the software ISP which we are working on fixing. > > So you could give this a try, but you will likely get neon-purple > colors in brightly lit areas. This is a known issue. > > On 25-Mar-26 17:02, Jacopo Mondi wrote: > > Hi Stuart > > > > On Wed, Mar 25, 2026 at 10:31:45AM +0100, Stuart J Mackintosh wrote: > >> From ae84819121c206dd352c5e24942c1170ff7c6819 Mon Sep 17 00:00:00 2001 > >> From: Stuart J Mackintosh <sjm@opendigital.cc> > >> Date: Wed, 25 Mar 2026 10:19:05 +0100 > >> Subject: [PATCH] ipa: libipa: camera_sensor_helper: Add OV01A10 > > > > There is something going on with the way you submitted the patch > > as 'git am' is not able to apply it. it seem you copied the patch in > > an email message ? > > > > Could you check Documentation/contributing.rst and use git-send-email ? > > > >> > >> Add a CameraSensorHelper for the OmniVision OV01A10 image sensor, > >> used in Dell XPS 13 and other laptops with the Intel IPU6 camera > >> subsystem. > >> > >> The analogue gain model is derived from the V4L2 control range > >> reported by the sensor driver. The minimum gain code is 256 with > >> a step of 1, giving the linear model: > >> > >> gain = code / 256 > > > > Following this line of reasoning, the max gain code in the driver is > > said to be 0x3fff which would give a max gain of x64 which seems quite > > high (however I surely can't rule out it is correct). > > I think this is a driver bug, almost all ov-sensors seem to have > a fractional gain with 4 bits for the non fractional parts > and either 7 or 8 bits for the fraction. With the non-fractional > part starting at 1 for 1.0 . As said in the previous reply, 0x3fff means a Q6.8 format which is unusual at best. > > So based on that and other ov sensor drivers I think the driver > is buggy and the maximum should be 0xf80, 0xf80 rather then 0xfff > because, well that is what other omnivision sensor drivers do, Feels like we're guessing a little too much here. Can't we ask the driver's author who presumably has a datasheet to clarify ? > I guess something goes funky in the hw for gains > 15.5 ? > > A maximum gain of 15.5 sounds much more realistic IMHO. > > So I think we need to fix the kernel driver to make the maximum > 0x780. f80 you mean ? > > >> This corresponds to AnalogueGainLinear{ 1, 0, 0, 256 }, consistent > >> with the pattern used by other OmniVision sensors in this file. > > > > Are we going by reasoning just looking at the min/max ? Aren't > > there other sources that migh confirm the analogue gain model is > > actually a linear one ? > > > Have you tried manually increasing the analogue gain and validate you > > get a linear response ? > > When I did the calibration images under controlled lighting conditions > I checked the influence of the gain control on the 18% grey square > (monitoring that square with camshark) of the macbeth chart and it > seemed linear. This also matches other known ov sensors. Ah see, that makes me more confident in accepting this patch! > > Regards, > > Hans > > > p.s. > > Stuart many of us have a wariness about over-use of AI, often just > throwing a lot of things at the wall and seeing what looks like it > might work, without rhyme or reason. Or what people call AI slop. > > Note this first submission does not seem to be AI slop at all! > > And your disclosure of using of AI is appreciated but please be > careful with your use of AI. Indeed, and I appreciate it was made clear. Unfortunately this still makes me wonder if the discussion I'm having is with someone which understand what he wrote or with someone simply proxying an LLM response to the list. Not saying that's the case, at all, but I feel like AI could help understanding some topics by giving pointers and guidance, but once a person has absorbed that understanding it should be the one producing a useful reply out of it, otherwise the quality of the discussion quickly degrades. Again, a general thought, not specifically on this discussion. > > >
On 26/03/2026 09:53, Jacopo Mondi wrote: >> Stuart many of us have a wariness about over-use of AI, often just >> throwing a lot of things at the wall and seeing what looks like it >> might work, without rhyme or reason. Or what people call AI slop. >> >> Note this first submission does not seem to be AI slop at all! >> >> And your disclosure of using of AI is appreciated but please be >> careful with your use of AI. > Indeed, and I appreciate it was made clear. > > Unfortunately this still makes me wonder if the discussion I'm having > is with someone which understand what he wrote or with someone simply > proxying an LLM response to the list. Not saying that's the case, at > all, but I feel like AI could help understanding some topics by giving > pointers and guidance, but once a person has absorbed that > understanding it should be the one producing a useful reply out of > it, otherwise the quality of the discussion quickly degrades. Thanks for bringing this up. It is a significant debate across most communities that I am part of right now and currently drafting AI policy for one. I am human - you can phone me, or look at my linkedin page (which isn't quite up to date) - whatever this might prove. Also talk to anyone you know from the Perl community. AI (I really don't like that term) is a powerful computing tool that helps me accelerate my understand the details of this particular issue. Having spent years working on hardware, and 30 years in Open Source (starting when changing an IRQ on an eth meant kernel recompile in the 0.9x series) I am confident that I have capability to do this without AI, but don't have capacity. This Dell laptop has been unusable for 2 years because of the camera issue, and AI can help get it resolved. The real issue here is people and provenance;if I was a long-standing member of this community and we had interactions over the years, it would be less of a concern for you but as someone who dropped in a couple of days ago, it is reasonable to be concerned (note xz case). AI slop is human slop, and any patch over 30 or so lines can easily fall in to that category, it is hard to review and puts pressure on the existing community. I have tried hard to state where AI has helped with my diagnostic, and as you will see by my reply to the thread, this next one has more AI and less me in it - I am sensitive to how this may be received, but also feel that, cautiously, it can help get this problem sorted out. Best wishes, Stuart.
Hi Jacopo, On 26/03/2026 09:40, Jacopo Mondi wrote: > Hi Stuart > > On Wed, Mar 25, 2026 at 05:28:14PM +0100, Stuart J Mackintosh wrote: >> Hi Jacopo, >> >> On 25/03/2026 17:02, Jacopo Mondi wrote: >>> Hi Stuart >>> >>> On Wed, Mar 25, 2026 at 10:31:45AM +0100, Stuart J Mackintosh wrote: >>>> From ae84819121c206dd352c5e24942c1170ff7c6819 Mon Sep 17 00:00:00 2001 >>>> From: Stuart J Mackintosh<sjm@opendigital.cc> >>>> Date: Wed, 25 Mar 2026 10:19:05 +0100 >>>> Subject: [PATCH] ipa: libipa: camera_sensor_helper: Add OV01A10 >>> There is something going on with the way you submitted the patch >>> as 'git am' is not able to apply it. it seem you copied the patch in >>> an email message ? >>> >>> Could you check Documentation/contributing.rst and use git-send-email ? >> Yes - I haven't used this method before, I am used to making PR's, so >> learning on this one. I will configure |git send-email| and resubmit. >> >>>> Add a CameraSensorHelper for the OmniVision OV01A10 image sensor, >>>> used in Dell XPS 13 and other laptops with the Intel IPU6 camera >>>> subsystem. >>>> >>>> The analogue gain model is derived from the V4L2 control range >>>> reported by the sensor driver. The minimum gain code is 256 with >>>> a step of 1, giving the linear model: >>>> >>>> gain = code / 256 >>> Following this line of reasoning, the max gain code in the driver is >>> said to be 0x3fff which would give a max gain of x64 which seems quite >>> high (however I surely can't rule out it is correct). >> The upstream kernel driver defines |OV01A10_ANAL_GAIN_MAX = 0x3fff| = 16383, >> giving a maximum of 63.99x. My running kernel (6.12.74+deb13) reports >> max=65535 via V4L2, which appears to be an older driver version predating a >> recent fix. The gain model is correct regardless - only the clamp value >> differs.(AI) >> > Yes, the max gain has been changed by Hans in > 109e0feacaeca5ec2dd71d7d17c73232ce5cbddc "media: i2c: ov01a10: Fix > analogue gain range" Thank you - I can see that commit sets the max to 0x3fff. My running kernel predates it (AI). > However, this still is this part of the commit message which puzzels > me > > The minimum gain of 0x100 is correct. Setting bits 8-11 to 0x0 results > in the same gain values as setting these bits to 0x1, with bits 0-7 > still increasing the gain when going from 0x000 - 0x0ff in the exact > same range as when going from 0x100 - 0x1ff. > > I don't get what "Setting bits 8-11 to 0x0 results n the same gain > values as setting these bits to 0x1" part. I should ask Hans The kernel commit by Hans clarifies this: the hardware mirrors gain codes 0x000-0x0ff onto the same range as 0x100-0x1ff, so the minimum is correctly set to 0x100 to avoid the mirrored region. The Q6.8 model holds from 0x100 upwards - gain = code / 256, with unity at 0x100 and maximum of 63.99x at 0x3fff (AI). >>>> This corresponds to AnalogueGainLinear{ 1, 0, 0, 256 }, consistent >>>> with the pattern used by other OmniVision sensors in this file. >>> Are we going by reasoning just looking at the min/max ? Aren't >>> there other sources that migh confirm the analogue gain model is >>> actually a linear one ? >>> >>> Have you tried manually increasing the analogue gain and validate you >>> get a linear response ? >> The kernel driver writes the analogue gain register directly without >> scaling: |cci_write(ov01a10->regmap, OV01A10_REG_ANALOG_GAIN, ctrl->val, >> NULL)|. The minimum |OV01A10_ANAL_GAIN_MIN = 0x100| = 256 represents unity >> gain, consistent with Q8 fixed-point where |gain = register_value / 256|. >> This is the same fixed-point convention used for digital gain, where >> |OV01A10_DGTL_GAIN_DEFAULT = 1024| represents unity with a 6-bit fractional >> part. (AI) > This almost make sense, if max is 0x3fff and x1 = 0100 we're looking > at a register in Q6.8 format. > > Howver the fact writes the value unscaled doesn't mean anything, > userspace is expected to do the coversion/scaling/whatever between the > gain value and the gain code Understood - I should not have used the unscaled write as evidence. The Q6.8 interpretation is the correct reasoning, and Hans confirmed linear behaviour from his Macbeth chart testing on the same sensor (AI). >> What would help me is to know the recommended way to capture frames at a >> fixed analogue gain value on an IPU6 platform, bypassing the AGC, to help >> validate the gain parameters? Any guidance that you might have with >> diagnostics is welcome. > Not an expert of softIsp and I don't know what controls it offers you > but I think using camshark is the easiest way. Camshark has overhead and beyond my capacity today. It would make sense for me if this was something I was doing more often. For the gain linearity question, Hans's Macbeth chart testing on the same sensor combined with the Q6.8 register format documented in the kernel driver provides sufficient evidence for the model (AI). Best wishes, Stuart. > >> Best wishes, >> >> Stuart. >> >> >>> Thanks >>> j >>> >>>> src/ipa/libipa/camera_sensor_helper.cpp | 12 ++++++++++++ >>>> 1 file changed, 12 insertions(+) >>>> >>>> diff --git a/src/ipa/libipa/camera_sensor_helper.cpp >>>> b/src/ipa/libipa/camera_sensor_helper.cpp >>>> index e3e3e535..72466867 100644 >>>> --- a/src/ipa/libipa/camera_sensor_helper.cpp >>>> +++ b/src/ipa/libipa/camera_sensor_helper.cpp >>>> @@ -653,6 +653,18 @@ public: >>>> }; >>>> REGISTER_CAMERA_SENSOR_HELPER("imx708", CameraSensorHelperImx708) >>>> +class CameraSensorHelperOv01a10 : public CameraSensorHelper >>>> +{ >>>> +public: >>>> + CameraSensorHelperOv01a10() >>>> + { >>>> + /* From dark frame measurement: 0x40 at 10bits. */ >>>> + blackLevel_ = 4096; >>>> + gain_ = AnalogueGainLinear{ 1, 0, 0, 256 }; >>>> + } >>>> +}; >>>> +REGISTER_CAMERA_SENSOR_HELPER("ov01a10", CameraSensorHelperOv01a10) >>>> + >>>> class CameraSensorHelperOv2685 : public CameraSensorHelper >>>> { >>>> public: >>>> -- >>>> 2.47.3 >>>> >>>> >>>> -- >>>> Stuart J Mackintosh >>>> >>>> Business & digital technology consultant >>>> >>>> Open Digital Consulting Co >>>> >>>> Open Digital Consulting Co Logo >>>> >>>> UK: +44 20 36 27 90 40 >>>> >>>> FR: +33 1 89 48 00 40 >>>> >>>> Email:sjm@opendigital.cc <mailto:sjm@opendigital.cc> >>>> >>>> Web:https://opendigital.cc <https://opendigital.cc> >>>> >>>> IM:xmpp:sjm@opendigital.cc <xmpp:sjm@opendigital.cc> >>>> >> -- >> >> Stuart J Mackintosh >> >> Business & digital technology consultant >> >> Open Digital Consulting Co >> >> Open Digital Consulting Co Logo >> >> UK: +44 20 36 27 90 40 >> >> FR: +33 1 89 48 00 40 >> >> Email:sjm@opendigital.cc >> >> Web:https://opendigital.cc >> >> IM:xmpp:sjm@opendigital.cc
Hi Stuart, On Fri, Mar 27, 2026 at 07:04:53AM +0100, Stuart J Mackintosh wrote: > Hi Jacopo, > > > On 26/03/2026 09:40, Jacopo Mondi wrote: > > Hi Stuart > > > > On Wed, Mar 25, 2026 at 05:28:14PM +0100, Stuart J Mackintosh wrote: > > > Hi Jacopo, > > > > > > On 25/03/2026 17:02, Jacopo Mondi wrote: > > > > Hi Stuart > > > > > > > > On Wed, Mar 25, 2026 at 10:31:45AM +0100, Stuart J Mackintosh wrote: > > > > > From ae84819121c206dd352c5e24942c1170ff7c6819 Mon Sep 17 00:00:00 2001 > > > > > From: Stuart J Mackintosh<sjm@opendigital.cc> > > > > > Date: Wed, 25 Mar 2026 10:19:05 +0100 > > > > > Subject: [PATCH] ipa: libipa: camera_sensor_helper: Add OV01A10 > > > > There is something going on with the way you submitted the patch > > > > as 'git am' is not able to apply it. it seem you copied the patch in > > > > an email message ? > > > > > > > > Could you check Documentation/contributing.rst and use git-send-email ? > > > Yes - I haven't used this method before, I am used to making PR's, so > > > learning on this one. I will configure |git send-email| and resubmit. > > > > > > > > Add a CameraSensorHelper for the OmniVision OV01A10 image sensor, > > > > > used in Dell XPS 13 and other laptops with the Intel IPU6 camera > > > > > subsystem. > > > > > > > > > > The analogue gain model is derived from the V4L2 control range > > > > > reported by the sensor driver. The minimum gain code is 256 with > > > > > a step of 1, giving the linear model: > > > > > > > > > > gain = code / 256 > > > > Following this line of reasoning, the max gain code in the driver is > > > > said to be 0x3fff which would give a max gain of x64 which seems quite > > > > high (however I surely can't rule out it is correct). > > > The upstream kernel driver defines |OV01A10_ANAL_GAIN_MAX = 0x3fff| = 16383, > > > giving a maximum of 63.99x. My running kernel (6.12.74+deb13) reports > > > max=65535 via V4L2, which appears to be an older driver version predating a > > > recent fix. The gain model is correct regardless - only the clamp value > > > differs.(AI) > > > > > Yes, the max gain has been changed by Hans in > > 109e0feacaeca5ec2dd71d7d17c73232ce5cbddc "media: i2c: ov01a10: Fix > > analogue gain range" > > Thank you - I can see that commit sets the max to 0x3fff. My running kernel > predates it (AI). > > > However, this still is this part of the commit message which puzzels > > me > > > > The minimum gain of 0x100 is correct. Setting bits 8-11 to 0x0 results > > in the same gain values as setting these bits to 0x1, with bits 0-7 > > still increasing the gain when going from 0x000 - 0x0ff in the exact > > same range as when going from 0x100 - 0x1ff. > > > > I don't get what "Setting bits 8-11 to 0x0 results n the same gain > > values as setting these bits to 0x1" part. I should ask Hans > > The kernel commit by Hans clarifies this: the hardware mirrors gain codes > 0x000-0x0ff onto the same range as 0x100-0x1ff, so the minimum is correctly > set to 0x100 to avoid the mirrored region. The Q6.8 model holds from 0x100 > upwards - gain = code / 256, with unity at 0x100 and maximum of 63.99x at > 0x3fff (AI). I really can't parse this, sorry. What does it mean "mirrors gain codes" ?? I've re-read the commit message a few times The minimum gain of 0x100 is correct. Setting bits 8-11 to 0x0 results in the same gain values as setting these bits to 0x1, with bits 0-7 still increasing the gain when going from 0x000 - 0x0ff in the exact same range as when going from 0x100 - 0x1ff. and I interpret it as the relative gain increase is identical in the 0x000-0x0ff and 0x100-0x1ff range. I'm not sure what the above "Setting bits 8-11 to 0x0 results in the same gain values as setting these bits to 0x1" part means though. We have Hans in the thread, he knows for sure :) > > > > > > This corresponds to AnalogueGainLinear{ 1, 0, 0, 256 }, consistent > > > > > with the pattern used by other OmniVision sensors in this file. > > > > Are we going by reasoning just looking at the min/max ? Aren't > > > > there other sources that migh confirm the analogue gain model is > > > > actually a linear one ? > > > > > > > > Have you tried manually increasing the analogue gain and validate you > > > > get a linear response ? > > > The kernel driver writes the analogue gain register directly without > > > scaling: |cci_write(ov01a10->regmap, OV01A10_REG_ANALOG_GAIN, ctrl->val, > > > NULL)|. The minimum |OV01A10_ANAL_GAIN_MIN = 0x100| = 256 represents unity > > > gain, consistent with Q8 fixed-point where |gain = register_value / 256|. > > > This is the same fixed-point convention used for digital gain, where > > > |OV01A10_DGTL_GAIN_DEFAULT = 1024| represents unity with a 6-bit fractional > > > part. (AI) > > This almost make sense, if max is 0x3fff and x1 = 0100 we're looking > > at a register in Q6.8 format. > > > > Howver the fact writes the value unscaled doesn't mean anything, > > userspace is expected to do the coversion/scaling/whatever between the > > gain value and the gain code > > Understood - I should not have used the unscaled write as evidence. The Q6.8 > interpretation is the correct reasoning, and Hans confirmed linear behaviour > from his Macbeth chart testing on the same sensor (AI). > > > > > What would help me is to know the recommended way to capture frames at a > > > fixed analogue gain value on an IPU6 platform, bypassing the AGC, to help > > > validate the gain parameters? Any guidance that you might have with > > > diagnostics is welcome. > > Not an expert of softIsp and I don't know what controls it offers you > > but I think using camshark is the easiest way. > > Camshark has overhead and beyond my capacity today. It would make sense for > me if this was something I was doing more often. > If you want to do tuning camshark is the best option and the setup is pretty easy Thanks j > For the gain linearity question, Hans's Macbeth chart testing on the same > sensor combined with the Q6.8 register format documented in the kernel > driver provides sufficient evidence for the model (AI). > > > Best wishes, > > Stuart. > > > > > > > > > Best wishes, > > > > > > Stuart. > > > > > > > > > > Thanks > > > > j > > > > > > > > > src/ipa/libipa/camera_sensor_helper.cpp | 12 ++++++++++++ > > > > > 1 file changed, 12 insertions(+) > > > > > > > > > > diff --git a/src/ipa/libipa/camera_sensor_helper.cpp > > > > > b/src/ipa/libipa/camera_sensor_helper.cpp > > > > > index e3e3e535..72466867 100644 > > > > > --- a/src/ipa/libipa/camera_sensor_helper.cpp > > > > > +++ b/src/ipa/libipa/camera_sensor_helper.cpp > > > > > @@ -653,6 +653,18 @@ public: > > > > > }; > > > > > REGISTER_CAMERA_SENSOR_HELPER("imx708", CameraSensorHelperImx708) > > > > > +class CameraSensorHelperOv01a10 : public CameraSensorHelper > > > > > +{ > > > > > +public: > > > > > + CameraSensorHelperOv01a10() > > > > > + { > > > > > + /* From dark frame measurement: 0x40 at 10bits. */ > > > > > + blackLevel_ = 4096; > > > > > + gain_ = AnalogueGainLinear{ 1, 0, 0, 256 }; > > > > > + } > > > > > +}; > > > > > +REGISTER_CAMERA_SENSOR_HELPER("ov01a10", CameraSensorHelperOv01a10) > > > > > + > > > > > class CameraSensorHelperOv2685 : public CameraSensorHelper > > > > > { > > > > > public: > > > > > -- > > > > > 2.47.3 > > > > > > > > > > > > > > > -- > > > > > Stuart J Mackintosh > > > > > > > > > > Business & digital technology consultant > > > > > > > > > > Open Digital Consulting Co > > > > > > > > > > Open Digital Consulting Co Logo > > > > > > > > > > UK: +44 20 36 27 90 40 > > > > > > > > > > FR: +33 1 89 48 00 40 > > > > > > > > > > Email:sjm@opendigital.cc <mailto:sjm@opendigital.cc> > > > > > > > > > > Web:https://opendigital.cc <https://opendigital.cc> > > > > > > > > > > IM:xmpp:sjm@opendigital.cc <xmpp:sjm@opendigital.cc> > > > > > > > > -- > > > > > > Stuart J Mackintosh > > > > > > Business & digital technology consultant > > > > > > Open Digital Consulting Co > > > > > > Open Digital Consulting Co Logo > > > > > > UK: +44 20 36 27 90 40 > > > > > > FR: +33 1 89 48 00 40 > > > > > > Email:sjm@opendigital.cc > > > > > > Web:https://opendigital.cc > > > > > > IM:xmpp:sjm@opendigital.cc > -- > > Stuart J Mackintosh > > Business & digital technology consultant > > Open Digital Consulting Co > > Open Digital Consulting Co Logo > > UK: +44 20 36 27 90 40 > > FR: +33 1 89 48 00 40 > > Email: sjm@opendigital.cc > > Web: https://opendigital.cc > > IM: xmpp:sjm@opendigital.cc
On 27/03/2026 09:27, Jacopo Mondi wrote: >>>>>> Add a CameraSensorHelper for the OmniVision OV01A10 image sensor, >>>>>> used in Dell XPS 13 and other laptops with the Intel IPU6 camera >>>>>> subsystem. >>>>>> >>>>>> The analogue gain model is derived from the V4L2 control range >>>>>> reported by the sensor driver. The minimum gain code is 256 with >>>>>> a step of 1, giving the linear model: >>>>>> >>>>>> gain = code / 256 >>>>> Following this line of reasoning, the max gain code in the driver is >>>>> said to be 0x3fff which would give a max gain of x64 which seems quite >>>>> high (however I surely can't rule out it is correct). >>>> The upstream kernel driver defines |OV01A10_ANAL_GAIN_MAX = 0x3fff| = 16383, >>>> giving a maximum of 63.99x. My running kernel (6.12.74+deb13) reports >>>> max=65535 via V4L2, which appears to be an older driver version predating a >>>> recent fix. The gain model is correct regardless - only the clamp value >>>> differs.(AI) >>>> >>> Yes, the max gain has been changed by Hans in >>> 109e0feacaeca5ec2dd71d7d17c73232ce5cbddc "media: i2c: ov01a10: Fix >>> analogue gain range" >> Thank you - I can see that commit sets the max to 0x3fff. My running kernel >> predates it (AI). >> >>> However, this still is this part of the commit message which puzzels >>> me >>> >>> The minimum gain of 0x100 is correct. Setting bits 8-11 to 0x0 results >>> in the same gain values as setting these bits to 0x1, with bits 0-7 >>> still increasing the gain when going from 0x000 - 0x0ff in the exact >>> same range as when going from 0x100 - 0x1ff. >>> >>> I don't get what "Setting bits 8-11 to 0x0 results n the same gain >>> values as setting these bits to 0x1" part. I should ask Hans >> The kernel commit by Hans clarifies this: the hardware mirrors gain codes >> 0x000-0x0ff onto the same range as 0x100-0x1ff, so the minimum is correctly >> set to 0x100 to avoid the mirrored region. The Q6.8 model holds from 0x100 >> upwards - gain = code / 256, with unity at 0x100 and maximum of 63.99x at >> 0x3fff (AI). > I really can't parse this, sorry. What does it mean "mirrors gain > codes" ?? > > I've re-read the commit message a few times > > The minimum gain of 0x100 is correct. Setting bits 8-11 to 0x0 results > in the same gain values as setting these bits to 0x1, with bits 0-7 > still increasing the gain when going from 0x000 - 0x0ff in the exact > same range as when going from 0x100 - 0x1ff. > > and I interpret it as the relative gain increase is identical in the > 0x000-0x0ff and 0x100-0x1ff range. I'm not sure what the above > > "Setting bits 8-11 to 0x0 results in the same gain values as setting > these bits to 0x1" > > part means though. > > We have Hans in the thread, he knows for sure :) I don't fully understand the register behaviour below 0x100 either. Hans or the original driver author should clarify, as they have the datasheet. What we do know is that the minimum of 0x100 is established and the Q6.8 formula gain = code / 256 is correct from that point upwards. (AI-assisted) >> Camshark has overhead and beyond my capacity today. It would make sense for >> me if this was something I was doing more often. >> > If you want to do tuning camshark is the best option and the setup is > pretty easy Ok - lets see if the weekend allows me time to set up camshark. I do find it a surprise that this standard cam in an XPS of a few years old has such problems, particularly when it came with Ubuntu installed. It seems that there may have been custom drivers from Intel to work around the issue. Might Intel have internal documentation or contacts that could help with the sensor delays and the gain max register behaviour, as it is their hardware? Best wishes, Stuart. > > Thanks > j > >>>>> >>>>>> src/ipa/libipa/camera_sensor_helper.cpp | 12 ++++++++++++ >>>>>> 1 file changed, 12 insertions(+) >>>>>> >>>>>> diff --git a/src/ipa/libipa/camera_sensor_helper.cpp >>>>>> b/src/ipa/libipa/camera_sensor_helper.cpp >>>>>> index e3e3e535..72466867 100644 >>>>>> --- a/src/ipa/libipa/camera_sensor_helper.cpp >>>>>> +++ b/src/ipa/libipa/camera_sensor_helper.cpp >>>>>> @@ -653,6 +653,18 @@ public: >>>>>> }; >>>>>> REGISTER_CAMERA_SENSOR_HELPER("imx708", CameraSensorHelperImx708) >>>>>> +class CameraSensorHelperOv01a10 : public CameraSensorHelper >>>>>> +{ >>>>>> +public: >>>>>> + CameraSensorHelperOv01a10() >>>>>> + { >>>>>> + /* From dark frame measurement: 0x40 at 10bits. */ >>>>>> + blackLevel_ = 4096; >>>>>> + gain_ = AnalogueGainLinear{ 1, 0, 0, 256 }; >>>>>> + } >>>>>> +}; >>>>>> +REGISTER_CAMERA_SENSOR_HELPER("ov01a10", CameraSensorHelperOv01a10) >>>>>> + >>>>>> class CameraSensorHelperOv2685 : public CameraSensorHelper >>>>>> { >>>>>> public: >>>>>> -- >>>>>> 2.47.3 >>>>>> >>>>>> >>>>>> -- >>>>>> Stuart J Mackintosh >>>>>> >>>>>> Business & digital technology consultant >>>>>> >>>>>> Open Digital Consulting Co >>>>>> >>>>>> Open Digital Consulting Co Logo >>>>>> >>>>>> UK: +44 20 36 27 90 40 >>>>>> >>>>>> FR: +33 1 89 48 00 40 >>>>>> >>>>>> Email:sjm@opendigital.cc <mailto:sjm@opendigital.cc> >>>>>> >>>>>> Web:https://opendigital.cc <https://opendigital.cc> >>>>>> >>>>>> IM:xmpp:sjm@opendigital.cc <xmpp:sjm@opendigital.cc> >>>>>> >>>> -- >>>> >>>> Stuart J Mackintosh >>>> >>>> Business & digital technology consultant >>>> >>>> Open Digital Consulting Co >>>> >>>> Open Digital Consulting Co Logo >>>> >>>> UK: +44 20 36 27 90 40 >>>> >>>> FR: +33 1 89 48 00 40 >>>> >>>> Email:sjm@opendigital.cc >>>> >>>> Web:https://opendigital.cc >>>> >>>> IM:xmpp:sjm@opendigital.cc >> -- >> >> Stuart J Mackintosh >> >> Business & digital technology consultant >> >> Open Digital Consulting Co >> >> Open Digital Consulting Co Logo >> >> UK: +44 20 36 27 90 40 >> >> FR: +33 1 89 48 00 40 >> >> Email:sjm@opendigital.cc >> >> Web:https://opendigital.cc >> >> IM:xmpp:sjm@opendigital.cc
Hello Stuart, On Fri, Mar 27, 2026 at 07:04:42AM +0100, Stuart J Mackintosh wrote: > On 26/03/2026 09:53, Jacopo Mondi wrote: > >> Stuart many of us have a wariness about over-use of AI, often just > >> throwing a lot of things at the wall and seeing what looks like it > >> might work, without rhyme or reason. Or what people call AI slop. > >> > >> Note this first submission does not seem to be AI slop at all! > >> > >> And your disclosure of using of AI is appreciated but please be > >> careful with your use of AI. > > Indeed, and I appreciate it was made clear. > > > > Unfortunately this still makes me wonder if the discussion I'm having > > is with someone which understand what he wrote or with someone simply > > proxying an LLM response to the list. Not saying that's the case, at > > all, but I feel like AI could help understanding some topics by giving > > pointers and guidance, but once a person has absorbed that > > understanding it should be the one producing a useful reply out of > > it, otherwise the quality of the discussion quickly degrades. > > Thanks for bringing this up. It is a significant debate across most > communities that I am part of right now and currently drafting AI policy > for one. > > I am human - you can phone me, or look at my linkedin page (which isn't > quite up to date) - whatever this might prove. Also talk to anyone you > know from the Perl community. > > AI (I really don't like that term) is a powerful computing tool that > helps me accelerate my understand the details of this particular issue. > Having spent years working on hardware, and 30 years in Open Source > (starting when changing an IRQ on an eth meant kernel recompile in the > 0.9x series) I am confident that I have capability to do this without > AI, but don't have capacity. > > This Dell laptop has been unusable for 2 years because of the camera > issue, and AI can help get it resolved. > > The real issue here is people and provenance;if I was a long-standing > member of this community and we had interactions over the years, it > would be less of a concern for you but as someone who dropped in a > couple of days ago, it is reasonable to be concerned (note xz case). > > AI slop is human slop, and any patch over 30 or so lines can easily fall > in to that category, it is hard to review and puts pressure on the > existing community. > > > I have tried hard to state where AI has helped with my diagnostic, and > as you will see by my reply to the thread, this next one has more AI and > less me in it - I am sensitive to how this may be received, but also > feel that, cautiously, it can help get this problem sorted out. For what it's worth, I recently came accross https://kusma.xyz/blog/2026/03/26/open-source-and-ai/. This summarizes pretty well my own opinion on the topic. My desire to engage with contributions where part of the code, documentation or e-mails has been written by an LLM is zero.
> For what it's worth, I recently came accross > https://kusma.xyz/blog/2026/03/26/open-source-and-ai/. This summarizes > pretty well my own opinion on the topic. My desire to engage with > contributions where part of the code, documentation or e-mails has been > written by an LLM is zero. Thanks for the link - I hadn't seen this. I find myself aligned with most of the points made on the link that you shared and agree that most do not have satisfactory answers at this point. I do feel that the Open Source communities are best placed to find the answers, because business interest is strongly pushing the use of AI and at the current pace, the corporates will be setting the rules. In a community that I am closely connected with, the debate is playing out currently which touches on some of these points: https://github.com/Perl/perl5/pull/24321 What I am sure of is that there will be no shortage of tensions about this for quite some time to come.
diff --git a/src/ipa/libipa/camera_sensor_helper.cpp b/src/ipa/libipa/camera_sensor_helper.cpp index e3e3e535..72466867 100644 --- a/src/ipa/libipa/camera_sensor_helper.cpp +++ b/src/ipa/libipa/camera_sensor_helper.cpp @@ -653,6 +653,18 @@ public: }; REGISTER_CAMERA_SENSOR_HELPER("imx708", CameraSensorHelperImx708) +class CameraSensorHelperOv01a10 : public CameraSensorHelper +{ +public: + CameraSensorHelperOv01a10() + { + /* From dark frame measurement: 0x40 at 10bits. */ + blackLevel_ = 4096; + gain_ = AnalogueGainLinear{ 1, 0, 0, 256 }; + } +}; +REGISTER_CAMERA_SENSOR_HELPER("ov01a10", CameraSensorHelperOv01a10) + class CameraSensorHelperOv2685 : public CameraSensorHelper { public: -- 2.47.3