[libcamera-devel] [PATCH v2 1/5] libcamera: properties: ColorFilterArrangement draft property

[Laurent Pinchart]

Hi David,

On Wed, Dec 30, 2020 at 10:00:07AM +0000, David Plowman wrote:
> Hi Jacopo
> 
> Thanks for that. Actually I think I was a bit confused too. I was
> thinking that the 3x16-bit was somehow supposed to include non-RAW
> sensors, but I guess it doesn't. Maybe Android invented it to account
> for those Foveon sensors that we had a few years back, which did give
> you R, G and B at each location, but were still RAW?
> 
> But anyway, I agree it will probably make sense to add a "no CFA"
> option for those monochrome RAW sensors at some point. In fact, I
> wonder if in future we may want to add that to our BayerFormat
> class... at which point "BayerFormat" isn't necessarily the right name
> any more. Oh dear! Anyway, that's a question for another time...

ColorFilterArray may be a better name. It depends on what the
BayerFormat class ends up being used for. If it's just a helper to
transpose the component ordering, it shouldn't be too much of an issue.
Android, in its android.sensor.info.colorFilterArrangement property,
differentiates monochrome from NIR. There's a slippery slope toards
exposing sensor frequency response information, which likely doesn't
belong to whatever BayerFormat will end up being.

In any case, it's a topic for later indeed.

> On Wed, 30 Dec 2020 at 09:38, Jacopo Mondi <jacopo at jmondi.org> wrote:
> > On Wed, Dec 30, 2020 at 08:59:31AM +0100, Jacopo Mondi wrote:
> > > On Tue, Dec 29, 2020 at 10:32:21PM +0000, David Plowman wrote:
> > > > On Tue, 29 Dec 2020 at 10:26, Jacopo Mondi <jacopo at jmondi.org> wrote:
> > > > > On Tue, Dec 29, 2020 at 09:25:14AM +0000, David Plowman wrote:
> > > > > > Hi Jacopo
> > > > > >
> > > > > > Thanks for this patch! Just one little question - I suppose Android
> > > > > > (and libcamera) have some other way of signalling a monochrome
> > > > > > sensor... I think I might have expected to find a
> > > > > > "monochrome/non-Bayer" option in the list?
> > > > >
> > > > > Please bare in mind this is a draft property, whose main purpose is
> > > > > to temporary close the gap with Android and its definition come
> > > > > straight from there.
> > > > >
> > > > > This property only makes sensor for RAW sensors, although there's a
> > > > > more generic 'RGB' value that sounds like a catch-all for non-Bayer
> > > > > sensors.
> > > > >
> > > > > Simply put: non-RAW sensor won't register this property at all.
> > > > > When we'll un-draft the property we can discuss if that makes sense
> > > > > at all as a choice, or we might want to have a more generic
> > > > > definition.
> > > > >
> > > > > Do you perhaps have any usage for such a more generic property in mind ?
> > > >
> > > > Not especially, my thoughts on the subject are only "draft" too!  :)
> > > >
> > > > I guess my only observations are that a monochrome ("no CFA at all")
> > > > format would probably be useful (it's still a RAW format, though not a
> > >
> > > My bad, I always thought 'mono-chrome' as a YUV sensor with only the Y
> > > channel being sent out.
> > >
> > > > Bayer one). Also, that single non-RAW format (3x16-bit RGB) seems a
> > > > bit lonely, for example YUV422 interleaved is probably more common,
> > > > but I doubt we want to list all the possible pixel formats all over
> > > > again, we have enough of that already!
> > >
> > > I'm not sure I follow. How does a processed format like YUV422 relates
> > > to the sensor's color filters arrangements ?
> >
> > Laurent helped clarify this to me, and yes, we probably need a
> > definition for monochrome going forward. I would however keep the draft
> > property version as close as possible to Android's definition and
> > expand it when un-drafting.

-- 
Regards,

Laurent Pinchart