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

[David Plowman]

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

Best regards
David

On Wed, 30 Dec 2020 at 09:38, Jacopo Mondi <jacopo at jmondi.org> wrote:
>
> Hi David,
>
> On Wed, Dec 30, 2020 at 08:59:31AM +0100, Jacopo Mondi wrote:
> > Hi David,
> >
> > On Tue, Dec 29, 2020 at 10:32:21PM +0000, David Plowman wrote:
> > > Hi Jacopo
> > >
> > > Thanks for the reply!
> > >
> > > On Tue, 29 Dec 2020 at 10:26, Jacopo Mondi <jacopo at jmondi.org> wrote:
> > > >
> > > > Hi David,
> > > >
> > > > 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.
>
> Thanks
>   j