Re: [PATCH 01/10] drm/colorop: Add DRM_COLOROP_CSC_FF

[Pekka Paalanen <pekka.paalanen@collabora.com>]

[-- Attachment #1: Type: text/plain, Size: 4089 bytes --]

On Mon, 16 Mar 2026 13:59:57 -0400
Harry Wentland <harry.wentland@amd.com> wrote:

> On 2026-03-16 12:03, Pekka Paalanen wrote:
> > On Mon, 16 Mar 2026 10:36:44 -0400
> > Harry Wentland <harry.wentland@amd.com> wrote:
> >   
> >> On 2026-03-16 07:53, Pekka Paalanen wrote:  
> >>> On Mon, 16 Mar 2026 16:04:32 +0530
> >>> "Borah, Chaitanya Kumar" <chaitanya.kumar.borah@intel.com> wrote:
> >>>     
> >>>> On 3/16/2026 2:27 PM, Pekka Paalanen wrote:    

...

> >>>>> Unfortunately, BT.601, BT.709 and BT.2020 define two separate things each:
> >>>>> - the YCbCr<->RGB conversion, and
> >>>>> - the colorspace primaries (and white point, but that is the same for
> >>>>>    them all).
> >>>>>    
> >>
> >> Would it make sense to treat these as two separate things in terms
> >> of colorops?  
> > 
> > Hi Harry,
> > 
> > no, if your hardware not care. There are no semantics for the numbers
> > in the UAPI, it's just whatever numbers, and mathematical operations on
> > them.
> > 
> > I suspect that your hardware does care, though, and actually has
> > separate hardware elements for the YCbCr conversion and the colorspace
> > conversion matrix. After all, one has to be able to put a LUT or a
> > curve between the two to make sense.
> > 
> > IOW, two different colorops, yes. But different colorop types? Maybe
> > that depends on whether they would have the same colorop properties or
> > not.
> >   
> 
> If I understand you correctly you're saying we can have a single
> colorop type to represent either type. A client of the API needs
> to understand what it's doing with the colorop and can use it
> as either a YCbCr conversion matrix in the case of YCbCr-to-RGB
> conversion, or an NPM for conversion of linear, normalized data
> from one set of primaries to another.
> 
> Is that understanding correct?

Yes. It's mostly a question of taste, whether we want matrices
conventionally used in different contexts in the same enum. I think
it's fine.

> >> I have done some work on a CSC colorop and intend to send out the
> >> patches in the next couple of days.
> >>
> >> https://gitlab.freedesktop.org/hwentland/linux/-/commits/csc-colorop
> >>
> >> It follows the drm_plane's COLOR_RANGE and COLOR_ENCODING semantic
> >> and is only intended for YCbCr-to-RGB conversion, like the original
> >> properties on the plane.
> >>
> >> For the colorspace conversion within RGB (e.g., BT709 to BT2020)
> >> it might make sense then to have its own colorop if HW works on
> >> pre-defined transformations, or use the CTM 3x3 or 3x4 matrix ops
> >> if HW provides a flexible matrix.
> >>
> >> We might need to think about naming, since colorspace conversion (CSC)
> >> right now seems to refer to both YCbCr conversion and primaries
> >> conversion.  
> > 
> > Indeed.
> > 
> > YCbCr conversion is usually a matrix operation. H.273 calls it
> > MatrixCoefficients, but it also lists cases where you need the EOTF in
> > the mix. I could go with "YCbCr coefficients". The pure matrix forms
> > are used on electrical pixel values.
> > 
> > The color space conversion matrices that are based on (Normalized)
> > Primary Matrices (NPM) must be used on optical pixel values. NPM is the
> > matrix that converts optical RGB values to CIE 1931 XYZ. For an
> > RGB-to-RGB conversion you need one NPM and another inverse NPM chained.
> >   
> 
> This could be expressed in a single matrix, right?

Naturally. y = N * (M * x) = (N * M) * x, where N, M are matrices and
x, y are column vectors.

> I intend to send out my patches as an RFC either way, but I think I
> could just as well work with the CSC_FF colorop. I'll have a look at
> basing my work on this.


Thanks,
pq


> > I guess using CSC for the latter is not obvious enough because it has
> > been used for the former (color model conversion) as well?
> > 
> > How about "color-primary conversion"?
> > 
> > I stole it from
> > https://onlinelibrary.wiley.com/doi/pdf/10.1002/9780470994375.app8
> > 
> > 
> > Thanks,
> > pq

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]