[libcamera-devel] CameraSensorInfo question

Jacopo Mondi jacopo at jmondi.org
Thu Aug 6 15:12:24 CEST 2020


Hello,

   let me reply to the second part of the question

On Thu, Aug 06, 2020 at 12:19:50PM +0200, Niklas Söderlund wrote:
> Hi David,
>
> On 2020-08-06 09:10:23 +0100, David Plowman wrote:
> > Hi everyone
> >
> > Please excuse the rather random question!
> >
> > I notice that Camera::name() has disappeared, replaced by
> > Camera::id(). That's fine, only I was using Camera::name() to get the
> > simple "user-facing" name of my sensor, such as just "imx477". Of
> > course I can still parse that out of the new id, it's hardly
> > difficult, but...
> >
> > I also notice that the thing I want is available in the
> > CameraSensorInfo (the "model" field).  Is there any reason why we
> > don't make the CameraSensorInfo available to applications, for
> > instance by copying it into the CameraConfiguration during the
> > Camera::configure call. I appreciate that applications don't usually
> > need to know that stuff, though on the other hand making information
> > available can be generally helpful, I think. (You might also guess
> > that I have some ulterior motives here, relating to digital zoom!!)

I know why you're asking this one, as you would like to get access to
the analogCrop rectangle for digital zoom ? :)

CameraSensorInfo is meant to be passed between pipeline handlers and
IPA, as it contains values that have to be retrieved from the the
sensor's sub-device after it has been configured. Moving it to be part
of a CameraConfiguration would require applying those settings at
validate() time, which shouldn't go an configure hardware.

I still think we should better expose immutable properties only in a
CameraConfiguration, which might indeed depends on the requested
stream configurations, but do not require going to the hardware to be
collected. I understand is a thin line as, in example frame durations
will depend on the mode applied to the sensor, and I know we have a
SUBDEV_TRY interface we could exploit, so we might actually end doing
that anyway, but I would be cautious in considering it a solution we
should consider as a first attempt..

> >
> > Any thoughts on the matter?
>
> As you have discover the Camera::id() is not well suited as a
> user-friendly name. Instead applications should create user-friendly
> name from controls and other information retrieved from a Camera.
>
> For example the sensor model as you point out could be useful for some
> applications while for others the location (Front, Back) of the camera
> would make more sens. For some a combination of the two or other
> information would best serve there use-case. Also the need to be able to
> localize the user facing name needs to be considered for some use-cases.
>
> You are correct that it's not possible for applications to get the
> sensor model information in what's available in the master branch today.
> This should of course be fixed and I hope to be able to do so in the
> near future. I wish to update the cam and qcam utilities to create
> friendly names from model + location as an example.
>
> I don't think parsing the string from id() is a good idea. As the
> documentation tries to explain it's a string without a fixed format so
> if you create a parser that works for your sensor and use-case that
> would likely fail for others.
>
> --
> Regards,
> Niklas Söderlund
> _______________________________________________
> libcamera-devel mailing list
> libcamera-devel at lists.libcamera.org
> https://lists.libcamera.org/listinfo/libcamera-devel


More information about the libcamera-devel mailing list