From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754897AbdC2JO3 (ORCPT ); Wed, 29 Mar 2017 05:14:29 -0400 Received: from mga05.intel.com ([192.55.52.43]:51633 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752720AbdC2JO1 (ORCPT ); Wed, 29 Mar 2017 05:14:27 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.36,240,1486454400"; d="scan'208";a="1128408298" Date: Wed, 29 Mar 2017 12:14:20 +0300 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: Jyri Sarha Cc: "dri-devel@lists.freedesktop.org" , "linux-kernel@vger.kernel.org" , jani.nikula@linux.intel.com, Sean Paul , Lionel G Landwerlin , Daniel Vetter , "Valkeinen, Tomi" Subject: Re: CTM and other color related properties Message-ID: <20170329091420.GR30290@intel.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 29, 2017 at 10:23:54AM +0300, Jyri Sarha wrote: > Referring to this discussion: > https://patchwork.kernel.org/patch/9546905/ > > Since the discussion, has there been any planning/work been done about > the CTM2 API? > > We would need for omap drm (for DSS5 and DSS6) a similar matrix API > for two purposes. However, neither of them is an exact match to the > CTM property. > > 1. CRTC specific Color Phase Rotation matrix is pretty close to CTM > concept, but it is applied after the gamma correction. However, there > is an optional static full-range or limited-range post-offset vector > and with it the CTM can also be used to convert the RGB output to a > YCbCr display output. Having a post-gamma csc is defintiely the right way to do it. In our case we don't have that in the current hardware :( All we have is degamma+csc+gamma, so this complicates things quite a bit when the user wants to apply ctm and/or gamma and we also need to use the csc either for rgb->ycbcr or rgb full->limited range conversion. ATM we don't do ycbcr output (but Shashank has plans) and it looks like our code for dealing with the rgb full->limited range conversion is totally bogus if there's a user specified ctm or gamma. So I think what we want is a degamma->csc->gamma->csc type of pipeline, where each driver can obviously select which parts of the pipeline they actually can support. > > 2. Plane specific Color Space Conversion matrix and pre-offset vector > is for YUV to RGB conversion. For customization purposes we would like > to expose this 3x3 matrix and the 3-element offset vector to user > space. So in general this is almost the same thing at the previous, but > for reverse conversion. Yeah, for planes I think we want a csc->degamma->csc->gamma type of pipeline. Again not all hardware can do it all so some of it will be optional. And on a lot of hardware some of these are totally fixed function blocks, so eg. exposing a fully programmable matrix may not always make sense. We did discuss this on the list recently: https://lists.freedesktop.org/archives/dri-devel/2017-January/131175.html https://lists.freedesktop.org/archives/dri-devel/2017-March/135854.html > > So when adding a CTM2 property blob, I would also vote for adding > pre- and post-offset vectors. Indeed. I was actually thinking that wouldn't it be cool if the hw actually had a 4x4 matrix so that you could do the translations purely with the matrix itself. But I've never actually seen that in any hardware, so exposing the pre/post offsets separately seems like the better plan. > Then a CSC would simply be a > combination off CTM and either a pre- or post- offset vector or maybe > both, depending on whether the block provides a conversion from RGB to > YUV, the other way around, or both. > > Then it is a question whether the offset vectors should be absolute or > or relative to the bit depth of RGB components. A relative, with enough > precision, would be the most generic choice but it would leave a lot of > work to the driver code in many cases. The actual depth of the data going through the matrix is hardware dependant anyway, so I don't think absolute values will really work. > > For convenience there could also be a standard enum for selecting > either custom coefficients or predefined standard conversion > (Full-range, ITU-R BT.601, and ITU-R BT.709 at least). > > In general the color space conversion arithmetic are described well > on this web page: > http://www.equasys.de/colorconversion.html > > Best regards, > Jyri -- Ville Syrjälä Intel OTC