[libcamera-devel] [PATCH 0/1] DigitalGain control

[Jacopo Mondi]

Hi David,

On Mon, Nov 23, 2020 at 07:40:33AM +0000, David Plowman wrote:
> Morning all
>
> Can I give this one its little weekly nudge? Thanks  :)

Sorry for having you nudgin us for three weeks :(

I'll try to provide feedback on the integration with the Control
framework. I have less valuable comments on the control semantic
itself, so I'll skip that part.

>

[snip]

> >>>
> >>> Hi everyone
> >>>
> >>> I wanted to raise a topic on which there was already some discussion a
> >>> few weeks back, prompted by my noticing a gap in the metadata that we
> >>> provide with images.
> >>>
> >>> My observation was that I couldn't correctly set the ISO value in my
> >>> JPEG files because we don't report how much digital gain has been
> >>> supplied by the image processing pipeline. To address this problem, it
> >>> seemed as good a way as any actually to include a proposal for a new
> >>> DigitalGain control (see the associated patch). Nevertheless, I think
> >>> there's a discussion to be had first. Notably:
> >>>
> >>> * Should we let the pipeline report a single global "digital gain"
> >>>   value or, given that different gains may be applied to the colour
> >>>   channels, should we report three gain values instead?
> >>>
> >>> * In the Pi world I'd like this to be a read-only control, i.e. you
> >>>   can't force the pipeline digital gain to a particular value, as our
> >>>   AGC doesn't work like that. But there may be platforms that do allow
> >>>   you to set the digital gain.

Libcamera does not enforce (yet) controls being read-only. What I mean
is that, in example, we don't have a flag in the yaml definition that
restrict the control from being written by applications.

But metadata are read-only by definition and for your case it is
enough not to advertise digital gain in the Camera's ControlInfoMap
controlInfo_ to prevent application from setting DigitalGain in a
Request.

Question is now it it is useful to report a ControlInfoMap of
supported metadata and their limits. Anyway that should not block you
from reporting DigitalGain like you now report other metadata.

> >>>
> >>> * You could imagine this being "per-stream". I think it's another case
> >>>   of "practically everyone will just want a single value", though
> >>>   technically you might be able to imagine some platform and use-cases
> >>>   where different outputs might reflect different digital gains.

I feel the same way as I felt for ScalerCrop: we should be able to
report it per stream, but there's no reason to block the definition of
a new control waiting for that feature to eventually land.

> >>>
> >>> * There's a question about digital gain being applied by the sensor
> >>>   itself, but I'm inclined to view that as a separate topic. The issue
> >>>   at hand, at least for me, is being able to distinguish the gain
> >>>   applied by the sensor, and which we see in the raw frames, from that
> >>>   applied by the ISP, which appears in the JPEGs.

As long as it is made clear in the Control definition, and we don't
make it very hard to find a non-conflicting name for the sensor's
digital gain I think it's fine.

Thanks
  j

> >>>
> >>> You may have other comments too - so everyone's thoughts would be much
> >>> appreciated.
> >>>
> >>> Thanks!
> >>> David
> >>>
> >>> David Plowman (1):
> >>>   libcamera: controls: Add DigitalGain control
> >>>
> >>>  src/libcamera/control_ids.yaml | 11 +++++++++++
> >>>  1 file changed, 11 insertions(+)
> >>>
> >>> --
> >>> 2.20.1
> >>>
> _______________________________________________
> libcamera-devel mailing list
> libcamera-devel at lists.libcamera.org
> https://lists.libcamera.org/listinfo/libcamera-devel