On Fri, Nov 30, 2018 at 03:48:00PM +0100, Hans Verkuil wrote: > On 11/30/18 15:29, Ville Syrjälä wrote: > > On Fri, Nov 30, 2018 at 03:20:59PM +0100, Andrzej Hajda wrote: > >> Hi Ville, > >> > >> As Christoph cannot respond till middle next week I can try to respond > >> in his absence, as I am familiar with the subject. > >> > >> On 30.11.2018 14:25, Ville Syrjälä wrote: > >>> On Fri, Nov 30, 2018 at 02:08:11PM +0100, Christoph Manszewski wrote: > >>>> Hi, > >>>> > >>>> I am looking for a way to export the color encoding and range selection > >>>> to user space. I came across those properties and am wondering, why > >>>> they are meant only for non RGB color encodings. Would it be okay, to > >>>> modify them and use with RGB formats as well? > >>> What you trying to do? Input limited range RGB data and expand to full > >>> range? > >> > >> > >> For example. But there are two more general questions, which > >> surprisingly we have not found answer for. > >> > >> 1. What color encoding and range drm should expect on its input RGB > >> buffers by default? > > > > RGB is just RGB. There is no encoding. It's assumed to be full range > > because no one really uses anything else. > > For simple desktop usage that's true. When dealing with video inputs, > this becomes much more complicated. > > > > >> > >> 2. How userspace should inform drm that given buffer has specified > >> non-default color encoding and range? > >> > >> > >> Hopefully this patch introduces such properties but only for YCbCr > >> formats, the question is what should be the best way to expand it to RGB > >> formats: > >> > >> A. Add another enums: DRM_COLOR_RGB_BT601 and friends. > > > > BT.601 specifies how to encoder RGB data as YCbCr. So without > > YCbCr BT.601 does not mean anything. Well, the standard does > > contain other things as well I suppose, but for the purposes > > of the color encoding prop only that one part is relevant. > > Ah, I misunderstood the meaning of DRM_COLOR_RGB_BT601. > This is the equivalent of V4L2_YCBCR_ENC_601, and that's indeed > only defined for Y'CbCr. But it is often (ab)used as an alias for > the SMPTE170M colorspace (used by SDTV). > > V4L2 has the following defines for colorspaces, transfer functions, > Y'CbCr (and HSV) encodings and quantization ranges: > > https://hverkuil.home.xs4all.nl/spec/uapi/v4l/colorspaces-defs.html Yeah, we're going to be introducing other properties to control colorspace and transfer function in kms as well. Actually some patches towards that have been floated a few times already. -- Ville Syrjälä Intel _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
