[libcamera-devel] CameraSensorInfo question

[Niklas Söderlund]

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