From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from madras.collabora.co.uk (madras.collabora.co.uk [IPv6:2a00:1098:0:82:1000:25:2eeb:e5ab]) by gabe.freedesktop.org (Postfix) with ESMTPS id 030A310E054 for ; Mon, 18 Sep 2023 08:02:23 +0000 (UTC) Date: Mon, 18 Sep 2023 11:02:18 +0300 From: Pekka Paalanen To: Harry Wentland Message-ID: <20230918110218.3c7975c4.pekka.paalanen@collabora.com> In-Reply-To: References: <20230908150315.75977-1-harry.wentland@amd.com> <20230908150315.75977-6-harry.wentland@amd.com> <20230915175258.0181c016.pekka.paalanen@collabora.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [igt-dev] [RFC PATCH 5/7] igt/color: Add SW color transform functionality List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Sebastian Wick , Shashank Sharma , Simon Ser , Alexander Goins , Michel =?UTF-8?B?RMOkbnplcg==?= , Xaver Hugl , igt-dev@lists.freedesktop.org, Jonas =?UTF-8?B?w4VkYWhs?= , Victoria Brekenfeld , Joshua Ashton , Daniel Vetter , Aleix Pol , Naseer Ahmed , Christopher Braga Errors-To: igt-dev-bounces@lists.freedesktop.org Sender: "igt-dev" List-ID: On Fri, 15 Sep 2023 15:50:52 -0400 Harry Wentland wrote: > On 2023-09-15 10:52, Pekka Paalanen wrote: > > On Fri, 8 Sep 2023 11:03:13 -0400 > > Harry Wentland wrote: > > =20 > >> In order to test color we want to compare a HW (KMS) transform > >> with a SW transform. This introduces color transform for an > >> sRGB EOTF but this can be extended to other transforms. Code is > >> borrowed from Skia. > >> > >> Signed-off-by: Harry Wentland > >> Cc: Ville Syrjala > >> Cc: Pekka Paalanen > >> Cc: Simon Ser > >> Cc: Harry Wentland > >> Cc: Melissa Wen > >> Cc: Jonas =C3=85dahl > >> Cc: Sebastian Wick > >> Cc: Shashank Sharma > >> Cc: Alexander Goins > >> Cc: Joshua Ashton > >> Cc: Michel D=C3=A4nzer > >> Cc: Aleix Pol > >> Cc: Xaver Hugl > >> Cc: Victoria Brekenfeld > >> Cc: Daniel Vetter > >> Cc: Uma Shankar > >> Cc: Naseer Ahmed > >> Cc: Christopher Braga > >> --- > >> lib/igt_color.c | 330 ++++++++++++++++++++++++++++++++++++++++++++++++ > >> lib/igt_color.h | 105 +++++++++++++++ > >> lib/igt_fb.c | 6 +- > >> lib/igt_fb.h | 2 + > >> lib/meson.build | 1 + > >> 5 files changed, 441 insertions(+), 3 deletions(-) > >> create mode 100644 lib/igt_color.c > >> create mode 100644 lib/igt_color.h ... > >> +/* > >> + * A transfer function mapping encoded values to linear values, > >> + * represented by this 7-parameter piecewise function: > >> + * > >> + * linear =3D sign(encoded) * (c*|encoded| + f) , 0 <=3D |en= coded| < d > >> + * =3D sign(encoded) * ((a*|encoded| + b)^g + e), d <=3D |en= coded| =20 > >=20 > > The code you have does not actually do the extended form (use of sign > > and absolute value), but clamps the result to [0.0, 1.0]. > > =20 >=20 > Yes, the intention (and I didn't write this but copied it) is to be able = to use > this to describe most (all?) standard transfer functions. See > https://github.com/google/skia/blob/main/include/core/SkColorSpace.h My complaint is about doc and implementation disagreeing. xvYCC and integer-encoded scRGB would need an extended range if anyone wanted to test those, if they even fit here. I also do not understand how it can be possible to express PQ EOTF or HLG OETF with this parameterisation. Maybe it's an approximation on a very limited domain? Thanks, pq > >> + * > >> + * (A simple gamma transfer function sets g to gamma and a to 1.) > >> + */ > >> +struct igt_color_tf { > >> + float g, a,b,c,d,e,f; > >> +}; > >> + > >> +const struct igt_color_tf srgb_tf =3D {2.4f, (float)(1/1.055), (float= )(0.055/1.055), (float)(1/12.92), 0.04045f, 0, 0}; > >> + > >> +/* end of Skia-based code */ > >> + > >> +typedef struct igt_pixel { > >> + float r; > >> + float g; > >> + float b; > >> +} igt_pixel_t; =20 > >=20 > > Thanks, > > pq =20 >=20