Re: [RFC] New class for low level sensors controls?

[Sakari Ailus <sakari.ailus@iki.fi>]

On Thu, Sep 08, 2011 at 11:51:06AM +0200, Laurent Pinchart wrote:
> Hi Sakari,

Hi Laurent,

> On Tuesday 06 September 2011 14:22:27 Sakari Ailus wrote:
> > On Tue, Sep 06, 2011 at 01:41:11PM +0200, Laurent Pinchart wrote:
> > > On Tuesday 06 September 2011 13:36:53 Sakari Ailus wrote:
> > > > Hi all,
> > > > 
> > > > We are beginning to have raw bayer image sensor drivers in the
> > > > mainline. Typically such sensors are not controlled by general purpose
> > > > applications but e.g. require a camera control algorithm framework in
> > > > user space. This needs to be implemented in libv4l for general purpose
> > > > applications to work properly on this kind of hardware.
> > > > 
> > > > These sensors expose controls such as
> > > > 
> > > > - Per-component gain controls. Red, blue, green (blue) and green (red)
> > > > 
> > > >   gains.
> > > > 
> > > > - Link frequency. The frequency of the data link from the sensor to the
> > > > 
> > > >   bridge.
> > > > 
> > > > - Horizontal and vertical blanking.
> > > 
> > > Other controls often found in bayer sensors are black level compensation
> > > and test pattern.
> > > 
> > > > None of these controls are suitable for use of general purpose
> > > > applications (let alone the end user!) but for the camera control
> > > > algorithms.
> > > > 
> > > > We have a control class called V4L2_CTRL_CLASS_CAMERA for camera
> > > > controls. However, the controls in this class are relatively high
> > > > level controls which are suitable for end user. The algorithms in the
> > > > libv4l or a webcam could implement many of these controls whereas I
> > > > see that only V4L2_CID_EXPOSURE_ABSOLUTE might be implemented by raw
> > > > bayer sensors.
> > > > 
> > > > My question is: would it make sense to create a new class of controls
> > > > for the low level sensor controls in a similar fashion we have a
> > > > control class for the flash controls?
> > > 
> > > I think it would, but I'm not sure how we should name that class.
> > > V4L2_CTRL_CLASS_SENSOR is tempting, but many of the controls that will be
> > > found there (digital gains, black leverl compensation, test pattern, ...)
> > > can also be found in ISPs or other hardware blocks.
> > 
> > I don't think ISPs typically implement test patterns. Do you know of any?
> 
> Not from the top of my head, but I don't think it would be too uncommon.
> 
> > Should we separate controls which clearly apply to sensors only from the
> > rest?
> > 
> > For sensors only:
> > 
> > - Analog gain(s)
> > - Horizontal and vertical blanking
> > - Link frequency
> > - Test pattern
> > 
> > The following can be implemented also on ISPs:
> > 
> > - Per-component gains
> > - Black level compensation
> > 
> > Do we have more to add to the list?
> 
> Not right now.
> 
> > If we keep the two the same class, I could propose the following names:
> > 
> > V4L2_CTRL_CLASS_LL_CAMERA (for low level camera)
> > V4L2_CTRL_CLASS_SOURCE
> > V4L2_CTRL_CLASS_IMAGE_SOURCE
> > 
> > The last one would be a good name for the sensor control class, as far as I
> > understand some are using tuners with the OMAP 3 ISP these days. For the
> > another one, I propose V4L2_CTRL_CLASS_ISP.
> 
> The issue with ISP is that pretty much any digital-based control can fall into 
> that class.
> 
> Maybe we should group controls by what they do, instead of the kind of 
> component that implements them ?

Sounds like a good idea. The two could fit into these classes:

- image capture control and
- digital image processing.

What do you think?

-- 
Sakari Ailus
e-mail: sakari.ailus@iki.fi	jabber/XMPP/Gmail: sailus@retiisi.org.uk