<div dir="ltr"><div dir="ltr">Hi Jacopo,<div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 23 Jun 2021 at 11:32, Jacopo Mondi <<a href="mailto:jacopo@jmondi.org">jacopo@jmondi.org</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 Wed, Jun 23, 2021 at 10:06:00AM +0100, Naushir Patuck wrote:<br>
> Hi Jacopo and David,<br>
><br>
> On Wed, 23 Jun 2021 at 09:12, Jacopo Mondi <<a href="mailto:jacopo@jmondi.org" target="_blank">jacopo@jmondi.org</a>> wrote:<br>
><br>
> <snip><br>
><br>
><br>
> > ><br>
> > > Are we saying that AeDisable means "stop adjusting the AEC/AGC<br>
> > > immediately, whether it's converged or not", but AeLock means "wait<br>
> > > until it's converged and then immediately stop adjusting the AEC/AGC"?<br>
> ><br>
> > If AeLock is set on a Converged state then yes, the values are not<br>
> > changed until the lock is lifted.<br>
> ><br>
> > Does the transition table repoted here helps ?<br>
> ><br>
> > <a href="https://developer.android.com/reference/android/hardware/camera2/CaptureResult#CONTROL_AE_STATE" rel="noreferrer" target="_blank">https://developer.android.com/reference/android/hardware/camera2/CaptureResult#CONTROL_AE_STATE</a><br>
> ><br>
> > Thanks<br>
> >    j<br>
> ><br>
><br>
> Having a brief look at the above document, I think<br>
> Jacopo's description makes<br>
> sense now.  Enabling AeLock locks the current AE computed values, whether<br>
> the algorithm has converged or not.  However, with AeLock set to on, other<br>
> controls are effectively ignored by the AE (e.g. aePrecaptureTrigger, maybe<br>
> other things as well).  Not sure why this is the case, as the application<br>
> surely<br>
> knows what state it wants the AE to be in...?<br>
<br>
So my previous example is slightly wrong, as the AeLock was meant to<br>
be set only once the AE has converged, not in request #0.<br>
<br>
><br>
> We don't deal with pre-capture sequences in RPi AE, so for us AeLock and<br>
> AeDisable are actually the same thing.  Thinking about it, even with a<br>
> pre-capture<br>
> sequence, we could probably say the same.  This may also be the case for<br>
> other vendor AE algorithms, but Android makes these states explicit.<br>
<br>
I think that's fine.<br>
<br>
That's more of a philosophical question, but I don't think we should<br>
try to impose all the IPA implementation to behave exactly the same,<br>
as that would impede the implementation of the most advanced features.<br>
The means the most performant application won't behave exactly the<br>
same between different platform, but I think at least in the controls<br>
definition we should try to get to the minimum common denominator that<br>
satisfies most needs. After all I think Android does the same, the<br>
definition is there for all platforms, but each implementation is<br>
slightly different and indeed it's usually the phone manufacturer<br>
provided camera app that actually makes use of the most advanced<br>
features, while a generic camera app is usually limited to the<br>
simplest use cases.<br>
<br>
For this specific use case (the AECG lock/state/enable), let me try to<br>
summarize how we could move forward:<br>
<br>
- Replace controls::AeLocked with a more descriptive AeState where the<br>
  current 'locked' is represented by the 'Converged' state.<br>
- Introduce controls::AeLock (which for RPi won't be supported)<br>
- We have controls::AeEnable which more or less maps to<br>
  android.AeMode. AeMode has more states which include control of the<br>
  flash. We do not strictly have to support it now afaict but moving<br>
  controls::AeMode from being a boolean on/off to a list of states<br>
  might help that transition to happen in future.<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Do you agree with my understanding here ?<br></blockquote><div><br></div><div>That all sounds good to me, but I would like David to have his say as</div><div>well.  It will probably be the case that our IPA will treat controls::AeLock</div><div>the same as our "Paused" state.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
The controls::AeLocked -> controls::AeState[Converged] will require us<br>
and the corresponding RPi camera app update to happen synchronously<br>
even if I admit I don't know how you distribute libcamera. IOW, are the<br>
camera apps compiled against the most recent master or against a<br>
frozen version? So that master can freely advance and the app updates can<br>
follow later once you update the version of libcamera you ship.<br></blockquote><div><br></div><div>We currently track master, so will have to update our apps separately when this</div><div>change goes through.  Eventually, we will freeze versions in our distribution to</div><div>avoid breakages, but we are not there yet.</div><div> <br></div><div>Regards,</div><div>Naush</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
><br>
>  Or it could be that I've just completely misunderstood that document :-)<br>
<br>
The fact we all keep asking that to ourselves makes me wonder if we're<br>
all a bunch of idiots or if we're actually exploring rather new<br>
territories in the open camera support landscape. I think time will<br>
tell :)<br>
<br>
Thanks<br>
   j<br>
<br>
PS As you might have noticed we're actually in the process of<br>
addressing the most advanced controls that android requires for<br>
high-end devices, so expect this kind of discussions to happen again<br>
in future :)<br>
<br>
><br>
> Naush<br>
</blockquote></div></div>