<div dir="ltr"><div dir="ltr">Hi Laurent,<div><br></div></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 26 Nov 2020 at 13:03, Laurent Pinchart <<a href="mailto:laurent.pinchart@ideasonboard.com">laurent.pinchart@ideasonboard.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Naush,<br>
<br>
On Thu, Nov 26, 2020 at 10:37:47AM +0000, Naushir Patuck wrote:<br>
> On Thu, 26 Nov 2020 at 10:20, Laurent Pinchart wrote:<br>
> > On Wed, Nov 25, 2020 at 11:36:40AM +0000, David Plowman wrote:<br>
> > > The exposure times in the exposure modes were causing AGC oscillations<br>
> > > because the algorithm was demanding long unachievable exposure times<br>
> > > but, without working sensor metadata, thought it was getting them when<br>
> > > actually it was not. We fix it by making the exposure profile request<br>
> > > only achievable exposure times, as we do for the ov5647 tuning.<br>
> ><br>
> > This looks good to me, and I assume it will still work with sensor<br>
> > embedded data, as unachievable exposure times are, well, unachievable<br>
> > :-)<br>
> ><br>
> > Is the process to select shutter values documented in the RPi camera<br>
> > documentation, or the tuning tool ? If someone wants to bring up a new<br>
> > sensor, how can we ensure a similar bug will not creep in ?<br>
> <br>
> My work on FPS control does fix this problem in a generic way for<br>
> non-embedded data sensors. This is done by ensuring we only send exposure<br>
> values that will be validated based on vblank limits, thereby ensuring the<br>
> return path (without embedded data) will be given the same values used by<br>
> the sensor device. For embedded data sensors, it all "just works", hence<br>
> our preference to use it where available ;-)<br>
<br>
Wouldn't algorithms still be able to do a better job when splitting<br>
sensitivity control between exposure time and gain if they know<br>
beforehand what exposure times are achievable, instead of waiting for<br>
the embedded data to report the actual value later ? </blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Regards,</div><div>Naush</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">My concern here is<br>
that I don't see any reason why it would be desirable to specify<br>
unachievable shutter times in the tuning parameters, so we should try to<br>
avoid it, especially if it can degrade performances. Making sure we<br>
document this properly would be a good first step.<br></blockquote><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> > > Signed-off-by: David Plowman <<a href="mailto:david.plowman@raspberrypi.com" target="_blank">david.plowman@raspberrypi.com</a>><br>
> ><br>
> > Reviewed-by: Laurent Pinchart <<a href="mailto:laurent.pinchart@ideasonboard.com" target="_blank">laurent.pinchart@ideasonboard.com</a>><br>
> ><br>
> > > ---<br>
> > > src/ipa/raspberrypi/data/imx219.json | 4 ++--<br>
> > > 1 file changed, 2 insertions(+), 2 deletions(-)<br>
> > ><br>
> > > diff --git a/src/ipa/raspberrypi/data/imx219.json b/src/ipa/raspberrypi/data/imx219.json<br>
> > > index b03a7beb..212f8b9a 100644<br>
> > > --- a/src/ipa/raspberrypi/data/imx219.json<br>
> > > +++ b/src/ipa/raspberrypi/data/imx219.json<br>
> > > @@ -133,7 +133,7 @@<br>
> > > {<br>
> > > "shutter":<br>
> > > [<br>
> > > - 100, 10000, 30000, 60000, 120000<br>
> > > + 100, 10000, 30000, 30000, 30000<br>
> > > ],<br>
> > > "gain":<br>
> > > [<br>
> > > @@ -144,7 +144,7 @@<br>
> > > {<br>
> > > "shutter":<br>
> > > [<br>
> > > - 100, 5000, 10000, 20000, 120000<br>
> > > + 100, 5000, 10000, 20000, 30000<br>
> > > ],<br>
> > > "gain":<br>
> > > [<br>
<br>
-- <br>
Regards,<br>
<br>
Laurent Pinchart<br>
</blockquote></div></div>