linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Brian Starkey <brian.starkey@arm.com>
Cc: dri-devel@lists.freedesktop.org, linux-media@vger.kernel.org,
	linux-kernel@vger.kernel.org, mihail.atanassov@arm.com,
	liviu.dudau@arm.com
Subject: Re: DRM Atomic property for color-space conversion
Date: Mon, 30 Jan 2017 15:35:13 +0200	[thread overview]
Message-ID: <20170130133513.GO31595@intel.com> (raw)
In-Reply-To: <20170127172324.GB12018@e106950-lin.cambridge.arm.com>

On Fri, Jan 27, 2017 at 05:23:24PM +0000, Brian Starkey wrote:
> Hi,
> 
> We're looking to enable the per-plane color management hardware in
> Mali-DP with atomic properties, which has sparked some conversation
> around how to handle YCbCr formats.
> 
> As it stands today, it's assumed that a driver will implicitly "do the
> right thing" to display a YCbCr buffer.
> 
> YCbCr data often uses different gamma curves and signal ranges (e.g.
> BT.609, BT.701, BT.2020, studio range, full-range), so its desirable
> to be able to explicitly control the YCbCr to RGB conversion process
> from userspace.
> 
> We're proposing adding a "CSC" (color-space conversion) property to
> control this - primarily per-plane for framebuffer->pipeline CSC, but
> perhaps one per CRTC too for devices which have an RGB pipeline and
> want to output in YUV to the display:
> 
> Name: "CSC"
> Type: ENUM | ATOMIC;
> Enum values (representative):
> "default":
> 	Same behaviour as now. "Some kind" of YCbCr->RGB conversion
> 	for YCbCr buffers, bypass for RGB buffers
> "disable":
> 	Explicitly disable all colorspace conversion (i.e. use an
> 	identity matrix).
> "YCbCr to RGB: BT.709":
> 	Only valid for YCbCr formats. CSC in accordance with BT.709
> 	using [16..235] for (8-bit) luma values, and [16..240] for
> 	8-bit chroma values. For 10-bit formats, the range limits are
> 	multiplied by 4.
> "YCbCr to RGB: BT.709 full-swing":
> 	Only valid for YCbCr formats. CSC in accordance with BT.709,
> 	but using the full range of each channel.
> "YCbCr to RGB: Use CTM":*
> 	Only valid for YCbCr formats. Use the matrix applied via the
> 	plane's CTM property
> "RGB to RGB: Use CTM":*
> 	Only valid for RGB formats. Use the matrix applied via the
> 	plane's CTM property
> "Use CTM":*
> 	Valid for any format. Use the matrix applied via the plane's
> 	CTM property
> ... any other values for BT.601, BT.2020, RGB to YCbCr etc. etc. as
> they are required.

Having some RGB2RGB and YCBCR2RGB things in the same property seems
weird. I would just go with something very simple like:

YCBCR_TO_RGB_CSC:
* BT.601
* BT.709
* custom matrix

And trying to use the same thing for the crtc stuff is probably not
going to end well. Like Daniel said we already have the
'Broadcast RGB' property muddying the waters there, and that stuff
also ties in with what colorspace we signal to the sink via
infoframes/whatever the DP thing was called. So my gut feeling is
that trying to use the same property everywhere will just end up
messy.

-- 
Ville Syrjälä
Intel OTC

  parent reply	other threads:[~2017-01-30 13:35 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-27 17:23 DRM Atomic property for color-space conversion Brian Starkey
2017-01-30  8:36 ` Daniel Vetter
2017-01-30 13:35 ` Ville Syrjälä [this message]
2017-01-31 12:33   ` Brian Starkey
2017-01-31 15:15     ` Ville Syrjälä
2017-01-31 15:55       ` Brian Starkey
2017-03-16 14:07         ` Ville Syrjälä
2017-03-16 14:12           ` Alex Deucher
2017-03-16 14:20           ` Sharma, Shashank
2017-03-16 14:30             ` Ville Syrjälä
2017-03-16 14:37               ` Local user for Liviu Dudau
2017-03-16 15:14                 ` Sharma, Shashank
2017-03-16 15:55                   ` Brian Starkey
2017-03-16 17:05                     ` Sharma, Shashank
2017-03-16 17:36                       ` Ville Syrjälä
2017-03-17 10:19                         ` Local user for Liviu Dudau
2017-03-17 10:33                         ` Brian Starkey
2017-03-17 14:09                           ` Ville Syrjälä
2017-03-20 10:48                             ` Hans Verkuil

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170130133513.GO31595@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=brian.starkey@arm.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=liviu.dudau@arm.com \
    --cc=mihail.atanassov@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).