[libcamera-devel] [PATCH 3/3] src: ipa: raspberrypi: Fix initial AGC oscillation for imx219 sensor

[Naushir Patuck]

Hi Laurent,

On Thu, 26 Nov 2020 at 13:03, Laurent Pinchart <
laurent.pinchart at ideasonboard.com> wrote:

> Hi Naush,
>
> On Thu, Nov 26, 2020 at 10:37:47AM +0000, Naushir Patuck wrote:
> > On Thu, 26 Nov 2020 at 10:20, Laurent Pinchart wrote:
> > > On Wed, Nov 25, 2020 at 11:36:40AM +0000, David Plowman wrote:
> > > > The exposure times in the exposure modes were causing AGC
> oscillations
> > > > because the algorithm was demanding long unachievable exposure times
> > > > but, without working sensor metadata, thought it was getting them
> when
> > > > actually it was not. We fix it by making the exposure profile request
> > > > only achievable exposure times, as we do for the ov5647 tuning.
> > >
> > > This looks good to me, and I assume it will still work with sensor
> > > embedded data, as unachievable exposure times are, well, unachievable
> > > :-)
> > >
> > > Is the process to select shutter values documented in the RPi camera
> > > documentation, or the tuning tool ? If someone wants to bring up a new
> > > sensor, how can we ensure a similar bug will not creep in ?
> >
> > My work on FPS control does fix this problem in a generic way for
> > non-embedded data sensors. This is done by ensuring we only send exposure
> > values that will be validated based on vblank limits, thereby ensuring
> the
> > return path (without embedded data) will be given the same values used by
> > the sensor device. For embedded data sensors, it all "just works", hence
> > our preference to use it where available ;-)
>
> Wouldn't algorithms still be able to do a better job when splitting
> sensitivity control between exposure time and gain if they know
> beforehand what exposure times are achievable, instead of waiting for
> the embedded data to report the actual value later ?


Yes, this would certainly help.  In practise we make do with digital gain
to make up the difference in the Raspberry Pi AGC.  This is again tied into
the whole subject of framerate control.  At the end of the day, framerate
(and vblank time) is what limits the shutter times available to use.  Once
we have framerates available to play with, these can be passed into the AGC
algorithm to restrict exposure times.

However, this will not stop a user from setting up exposure profiles that
request larger shutter speeds than what is achievable given fps
constraints.  In these cases, the user will not get what he wants, unless
he sets the framerate appropriately.

Regards,
Naush



> My concern here is
> that I don't see any reason why it would be desirable to specify
> unachievable shutter times in the tuning parameters, so we should try to
> avoid it, especially if it can degrade performances. Making sure we
> document this properly would be a good first step.
>




>
> > > > Signed-off-by: David Plowman <david.plowman at raspberrypi.com>
> > >
> > > Reviewed-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
> > >
> > > > ---
> > > >  src/ipa/raspberrypi/data/imx219.json | 4 ++--
> > > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/src/ipa/raspberrypi/data/imx219.json
> b/src/ipa/raspberrypi/data/imx219.json
> > > > index b03a7beb..212f8b9a 100644
> > > > --- a/src/ipa/raspberrypi/data/imx219.json
> > > > +++ b/src/ipa/raspberrypi/data/imx219.json
> > > > @@ -133,7 +133,7 @@
> > > >              {
> > > >                  "shutter":
> > > >                  [
> > > > -                    100, 10000, 30000, 60000, 120000
> > > > +                    100, 10000, 30000, 30000, 30000
> > > >                  ],
> > > >                  "gain":
> > > >                  [
> > > > @@ -144,7 +144,7 @@
> > > >              {
> > > >                  "shutter":
> > > >                  [
> > > > -                    100, 5000, 10000, 20000, 120000
> > > > +                    100, 5000, 10000, 20000, 30000
> > > >                  ],
> > > >                  "gain":
> > > >                  [
>
> --
> Regards,
>
> Laurent Pinchart
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libcamera.org/pipermail/libcamera-devel/attachments/20201126/bc26b846/attachment.htm>