Hi David, On Fri, Aug 06, 2021 at 09:15:09AM +0100, David Plowman wrote: > Hi Sakari, Laurent > > Thanks for the various comments and discussion. It did prompt me to > have some second thoughts about some of the details here, as follows. > > These controls are aimed specifically at sensors that do some kind of > on-board "demosaic / remosaic" process, for instance to produce > standard Bayer patterns from non-standard ones. As such the principal > requirement is for the sensor to know what "grey" looks like, which we > tell it by sending it the red and blue gains from the white balance > algorithm. (This obviously enables it to reduce colour aliasing during > the processing that it does.) > > So perhaps the comparison here should be with the existing > V4L2_CID_RED/BLUE_BALANCE controls. I'm not sure that it really > matters exactly what the colours of the pixels on the sensor really > are, it's knowing what "grey" looks like that is important. Any new > controls could be quite cumbersome to use if you have to figure out > what the underlying pixel arrangement looks like, it certainly feels > much easier to refer simply to red/blue pixels, leaving the driver to > deal with its own internal idiosyncrasies. I think I missed these are the gains of the Bayer pattern components, and by definition you'll be only setting the gains of those components that are sent out by the sensor. So there wouldn't be other components around, just these four. > > Having said that, the particular sensor I have exposes a gain for each > of the four Bayer channels, even though I find myself ignoring the > green ones!! > > Anyway, I certainly feel I could go either way on this one - do you > have any more thoughts on the matter? I'm leaning towards a single array control with specified, mbus code independent order of components. You should add this control is applicable to Bayer pattern output only. That leaves it easily extendable later on. -- Kind regards, Sakari Ailus
