dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Jyri Sarha <jsarha@ti.com>
Cc: Liviu.Dudau@arm.com, dri-devel@lists.freedesktop.org,
	tomi.valkeinen@ti.com, laurent.pinchart@ideasonboard.com
Subject: Re: [PATCH RFC 3/6] drm: Plane YCbCr to RGB conversion related properties
Date: Mon, 24 Apr 2017 19:55:01 +0300	[thread overview]
Message-ID: <20170424165501.GB30290@intel.com> (raw)
In-Reply-To: <1a0ed660-89ff-3883-c2a2-cd15f490c591@ti.com>

On Mon, Apr 24, 2017 at 06:49:04PM +0300, Jyri Sarha wrote:
> On 04/24/17 18:13, Ville Syrjälä wrote:
> >> What about the uapi structs? In the patch there is an explicit struct
> >> naming each coefficient for what they are for in YCbCr to RGB
> >> conversion. Is this Ok, or should we go with a generic (CTM style)
> >> matrix, that could be used for RGB to YCbCr conversion too?
> > Not sure what we're talking about here, but like I said I think we
> > should stick to a fairly limited set of standard props and just have
> > each driver map the hardware resources to them as best they can.
> > 
> 
> Just about the implementation detail, if we should have a separate uapi
> struct for YCbCr to RGB CSC and RGB to YCbCr CSC. If we are going to use
> the same struct, then we could as well use the already existing CTM struct.
> 
> > If you just have csc+(de)gamma then I guess it might make sense
> > to just expose the YCbCr->RGB and degamma. If you have
> > degamma+csc+gamma then it might make sense to expose both
> > YCbCr->RGB, degamma, CTM, and gamma, and just refuse any
> > combination that can't be done. Eg. can't do YCbCr->RGB if
> > degamma is used, and YCbCr->RGB + CTM would require multiplying
> > the matrices together which you may or may not want to bother
> > with, I guess we could try to put some matrix math helpers into
> > the core to make such things less painful for drivers?
> 
> In fact we have plane specific YCbCr to RGB CSC (only preoffset
> possible), then (per crtc) gamma table, and finally a (per crtc) RGB to
> YCbCr CSC with optional post offset (so it can be used either as CSC or
> CTM).

So with that plane hw you could perhaps do:
- YCbCr->RGB if you input is not linear, but then you must
  blend using non-linear data
- colorspace conversion if your input is alredy linear

And with your crtc hw you could do:
- degamma + CTM
- gamma + RGB->YCbCr

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2017-04-24 16:55 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-21  9:51 [PATCH RFC 0/6] drm: Add properties to control YCbCr to RGB conversion Jyri Sarha
2017-04-21  9:51 ` [PATCH RFC 1/6] drm: drm_color_mgmt.h needs struct drm_crtc declaration Jyri Sarha
2017-04-21 11:46   ` Laurent Pinchart
2017-04-21  9:51 ` [PATCH RFC 2/6] drm: Make drm_atomic_replace_property_blob_from_id() more generic Jyri Sarha
2017-04-21 11:47   ` Laurent Pinchart
2017-05-02  8:31     ` Daniel Vetter
2017-04-21  9:51 ` [PATCH RFC 3/6] drm: Plane YCbCr to RGB conversion related properties Jyri Sarha
2017-04-21 11:17   ` Ville Syrjälä
2017-04-21 12:10     ` Laurent Pinchart
2017-04-21 13:08       ` Ville Syrjälä
2017-04-21 12:58     ` Sharma, Shashank
2017-04-21 13:39     ` Jyri Sarha
2017-04-21 13:52       ` Ville Syrjälä
2017-04-21 14:53         ` Brian Starkey
2017-04-21 15:21           ` Ville Syrjälä
2017-04-21 15:34             ` Brian Starkey
2017-04-21 16:49               ` Ville Syrjälä
2017-04-24 12:58                 ` Brian Starkey
2017-04-24  9:02         ` [PATCH] RFC: Design: DRM: Blending pipeline using DRM plane properties Shashank Sharma
2017-04-24 13:21         ` [PATCH RFC 3/6] drm: Plane YCbCr to RGB conversion related properties Jyri Sarha
2017-04-24 15:13           ` Ville Syrjälä
2017-04-24 15:49             ` Jyri Sarha
2017-04-24 16:55               ` Ville Syrjälä [this message]
2017-04-26 12:56                 ` Jyri Sarha
2017-04-26 13:28                   ` Sharma, Shashank
2017-04-26 17:22                   ` Ville Syrjälä
2017-05-02  8:33   ` Daniel Vetter
2017-05-02  9:29     ` Jyri Sarha
2017-04-21  9:51 ` [PATCH RFC 4/6] drm/omap: cleanup color space conversion Jyri Sarha
2017-04-21 11:53   ` Laurent Pinchart
2017-04-21  9:51 ` [PATCH RFC 5/6] drm/omap: csc full range support Jyri Sarha
2017-04-21 11:55   ` Laurent Pinchart
2017-04-21  9:51 ` [PATCH RFC 6/6] drm/omap: Enable ycbcr_to_rgb_properties for omapdrm planes REVISIT Jyri Sarha
2017-04-21 12:53 ` [PATCH RFC 0/6] drm: Add properties to control YCbCr to RGB conversion Sharma, Shashank
2017-04-21 13:50 ` Liviu Dudau

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=20170424165501.GB30290@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=Liviu.Dudau@arm.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jsarha@ti.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=tomi.valkeinen@ti.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