[libcamera-devel] CameraSensorInfo question

[David Plowman]

HI Jacopo

On Thu, 6 Aug 2020 at 14:08, Jacopo Mondi <jacopo at jmondi.org> wrote:
>
> 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 ? :)

Hehe. Actually it's the outputSize that I want! If I can find that,
then the rest of digital zoom is, I think, reasonably
straightforward...

Best regards
David

>
> 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