linux-kernel - CTM and other color related properties

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <ca492b5a-2dc6-79ca-e022-b2e69e440405@ti.com>
Date:   Wed, 29 Mar 2017 10:23:54 +0300
From:   Jyri Sarha <jsarha@...com>
To:     "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
CC:     <jani.nikula@...ux.intel.com>, Sean Paul <seanpaul@...omium.org>,
        <ville.syrjala@...ux.intel.com>,
        Lionel G Landwerlin <lionel.g.landwerlin@...el.com>,
        Daniel Vetter <daniel@...ll.ch>,
        "Valkeinen, Tomi" <tomi.valkeinen@...com>
Subject: CTM and other color related properties

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.

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.

So when adding a CTM2 property blob, I would also vote for adding
pre- and post-offset vectors. 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.

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