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]
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

Powered by blists - more mailing lists