[libcamera-devel] ScalerCrop control and camera modes

[David Plowman]

Indeed, I think pretty much all our controls are handled by IPAs so
the simple "don't do anything" means they get preserved automatically.
ScalerCrop is a bit different in that the PH deals with it.

To be honest, I can see an argument that says "resetting it when you
reconfigure" is a simple behaviour that is easily understood. If you
want to preserve it, you need to pass a value with your call to start.
I possibly have a slight preference for this because (a) it's easily
understood and (b) it's what the code does now (!), but I feel we
should probably make a conscious decision.

David

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