[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <e30ee10b-d846-d2f0-65ae-1b556ff636bc@xs4all.nl>
Date: Mon, 20 Mar 2017 11:48:49 +0100
From: Hans Verkuil <hverkuil@...all.nl>
To: Ville Syrjälä <ville.syrjala@...ux.intel.com>,
Brian Starkey <brian.starkey@....com>
Cc: "Sharma, Shashank" <shashank.sharma@...el.com>,
Local user for Liviu Dudau <liviu.dudau@....com>,
dri-devel@...ts.freedesktop.org, linux-media@...r.kernel.org,
linux-kernel@...r.kernel.org, mihail.atanassov@....com,
"Cyr, Aric" <Aric.Cyr@....com>,
"Wentland, Harry" <Harry.Wentland@....com>,
Alex Deucher <alexdeucher@...il.com>
Subject: Re: DRM Atomic property for color-space conversion
On 03/17/2017 03:09 PM, Ville Syrjälä wrote:
> On Fri, Mar 17, 2017 at 10:33:15AM +0000, Brian Starkey wrote:
>> For not-programmable hardware, would a second "DEGAMMA_FIXED" property
>> make sense, which is an enum type exposing what curves are supported?
>> (with analogous GAMMA_FIXED as well)
>
> Hmm. I suppose we could make it a bit more explicit like that.
> Not sure how we'd specify those though. Just BT.709, BT.2020, etc. and
> perhaps just something like 'Gamma 2.2' if it's a pure gamma curve?
> Someone who is more familiar with the subject could probably propose
> a better naming scheme.
Just as a reference, this is how V4L2 describes colorspace information:
https://www.linuxtv.org/downloads/v4l-dvb-apis-new/uapi/v4l/colorspaces.html
Sections 2.4-2.6 are all about that.
Note: pure gamma functions (i.e. Gamma 2.2) are not defined since we do not
support hardware that needs that. Should that be needed in the future, then
we would add that to the xfer_func defines.
Regards,
Hans
Powered by blists - more mailing lists