On 11/30/18 16:16, Ville Syrjälä wrote: > 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. > Great. Let's try to keep drm and V4L2 in sync for this. It should be possible to convert from one to the other without having to do weird things. I'll try to pay attention to these patches, but just ping me if you want me to take a look at something. I put a lot of effort into the V4L2 colorspace documentation, trying to put all the information in one place, esp. all the formulas. Regards, Hans _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
