<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, 11 Jan 2023 at 15:55, Jacopo Mondi via libcamera-devel <<a href="mailto:libcamera-devel@lists.libcamera.org">libcamera-devel@lists.libcamera.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 David<br>
<br>
On Wed, Jan 11, 2023 at 01:27:31PM +0000, David Plowman via libcamera-devel wrote:<br>
> Hi everyone<br>
><br>
> A little question about what happens to the ScalerCrop control when we<br>
> switch between camera modes (i.e. call configure). Paying particular<br>
> attention to the case when the two camera modes have different sensor<br>
> crops (and therefore a different FoV), should the ScalerCrop be<br>
> preserved or not?<br>
<br>
How is a Control "preserved" between streaming sessions ?<br>
<br>
Are you wondering if the ScalerCrop set by an application during a<br>
streaming session should be retained by the pipeline handler after a<br>
[stop - configure] sequence and re-applied at start() time without<br>
application's intervention ?<br>
<br>
If that's the case, are there other controls preserved between<br>
reconfigurations or do you have any in mind ?<br></blockquote><div><br></div><div>Most controls destined for the IPA currently preserve value between<br>reconfigurations.  For example, ExposureTime, AnalogueGain, Brightness,<br>Contrast, ColourGains, etc. all apply the same settings regardless of mode.  In<br>fact, I cannot think of a control (apart from ScalerCrop) that is not preserved<br>between reconfigurations!<br></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>
> I think we could go either way.<br>
><br>
> If the ScalerCrop is preserved that's fine, but you have to handle the<br>
> case where the previous ScalerCrop is not entirely available in the<br>
> new mode. You also have to consider how an application would reset the<br>
> ScalerCrop so as to switch from a mode with a limited FoV to one with<br>
> a larger FoV.<br>
><br>
> If the ScalerCrop isn't preserved that's fine too, but you have to<br>
> consider how an application would preserve the ScalerCrop if it wanted<br>
> to.<br>
><br>
> In many respects I don't think there's much difference, applications<br>
> would (sometimes) have to specify the ScalerCrop they want when they<br>
> call start. But which do we think is the most desirable behaviour? On<br>
> the Pi, by not having thought about it, we are implementing the second<br>
> alternative (ScalerCrop not preserved).<br>
><br>
> Thoughts?<br>
><br>
> Thanks!<br>
> David<br>
</blockquote></div></div>