On Mon, 16 Mar 2026 13:59:57 -0400 Harry Wentland <[email protected]> wrote:
> On 2026-03-16 12:03, Pekka Paalanen wrote: > > On Mon, 16 Mar 2026 10:36:44 -0400 > > Harry Wentland <[email protected]> wrote: > > > >> On 2026-03-16 07:53, Pekka Paalanen wrote: > >>> On Mon, 16 Mar 2026 16:04:32 +0530 > >>> "Borah, Chaitanya Kumar" <[email protected]> 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
pgpJxIJSlgwQe.pgp
Description: OpenPGP digital signature
