[FFmpeg-devel] [PATCH] vf_colorspace: Add an option to clamp trc LUT output (PR #20438)

[FFmpeg-devel] [PATCH] vf_colorspace: Add an option to clamp trc LUT output (PR #20438)

[Drew Dunne via ffmpeg-devel]

PR #20438 opened by Drew Dunne (doctor3w)
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20438
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20438.patch

Add a new flag to the vf_colorspace filter which provides the user an
option to clamp the linear and delinear transfer characteristics LUT
values to the [0, 1] represented range. This helps constrain the
potential value range when converting between colorspaces.

Certain colors when going through the conversion can result in out of
gamut colors after the rotation. The colorspace filter allows that with
the extended range. The added clamping just keeps the colors within the
[0, 1) range rather than using that extended range. I'm not enough of a
color scientist to say which is correct, but there are certain
situations where we would prefer to keep the colors in gamut.

The example I have is:

A solid color image of 8-bit YUV: Y=157, U=164, V=98.

Specify the input as:

Input range: MPEG
In color matrix: BT470BG
In color primaries: BT470M
In color transfer characteristics: Gamma 28

Output as:
Out color range: JPEG
Out color matrix: BT.709
Out color primaries: BT.709
Out color transfer characteristics: BT.709

During the calculation you get:

Input YUV:                             y=157,      u=164,      v-98
Post-yuv2rgb BT.470BG:                 r=0.456055, g=0.684152, b=0.928606
Post-apply gamma28 linear LUT:         r=0.110979, g=0.345494, b=0.812709
Post-color rotation BT.470M to BT.709: r=-0.04161, g=0.384626, b=0.852400
Post-apply Rec.709 delinear LUT:       r=-0.16382, g=0.615932, b=0.923793
Post-rgb2yuv Rec.709 matrix:           y=120,      u=190,      v=25

Where with this change, the delinear LUT output would be clamped to 0,
so the result would be:
r=0.000000, g=0.612390, b=0.918807 and a final output of
y=129, u=185, v=46

As for the long and av_clip64, this was just because lrint returned a
long, so I left it as that and then used av_clip64 to the [0,1) range to
avoid overflow. But re-reading, it looks like av_clip_int16 would
downcast that long to int anyway so the possibility of overflow already
existed there. I've put it back to int just to match the existing
behavior.


>From c288cff23a065fb2d3ff1ff999abc3b33c76296f Mon Sep 17 00:00:00 2001
From: Drew Dunne <asdunne@google.com>
Date: Thu, 4 Sep 2025 17:01:56 +0000
Subject: [PATCH] vf_colorspace: Add an option to clamp trc LUT output

Add a new flag to the vf_colorspace filter which provides the user an
option to clamp the linear and delinear transfer characteristics LUT
values to the [0, 1] represented range. This helps constrain the
potential value range when converting between colorspaces.

Certain colors when going through the conversion can result in out of
gamut colors after the rotation. The colorspace filter allows that with
the extended range. The added clamping just keeps the colors within the
[0, 1) range rather than using that extended range. I'm not enough of a
color scientist to say which is correct, but there are certain
situations where we would prefer to keep the colors in gamut.

The example I have is:

A solid color image of 8-bit YUV: Y=157, U=164, V=98.

Specify the input as:

Input range: MPEG
In color matrix: BT470BG
In color primaries: BT470M
In color transfer characteristics: Gamma 28

Output as:
Out color range: JPEG
Out color matrix: BT.709
Out color primaries: BT.709
Out color transfer characteristics: BT.709

During the calculation you get:

Input YUV:                             y=157,      u=164,      v-98
Post-yuv2rgb BT.470BG:                 r=0.456055, g=0.684152, b=0.928606
Post-apply gamma28 linear LUT:         r=0.110979, g=0.345494, b=0.812709
Post-color rotation BT.470M to BT.709: r=-0.04161, g=0.384626, b=0.852400
Post-apply Rec.709 delinear LUT:       r=-0.16382, g=0.615932, b=0.923793
Post-rgb2yuv Rec.709 matrix:           y=120,      u=190,      v=25

Where with this change, the delinear LUT output would be clamped to 0,
so the result would be:
r=0.000000, g=0.612390, b=0.918807 and a final output of
y=129, u=185, v=46

As for the long and av_clip64, this was just because lrint returned a
long, so I left it as that and then used av_clip64 to the [0,1) range to
avoid overflow. But re-reading, it looks like av_clip_int16 would
downcast that long to int anyway so the possibility of overflow already
existed there. I've put it back to int just to match the existing
behavior.
---
 doc/filters.texi            |  3 +++
 libavfilter/vf_colorspace.c | 14 ++++++++++++--
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index 1b5665d36e..e212bd0970 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -10403,6 +10403,9 @@ von Kries whitepoint adaptation
 identity whitepoint adaptation (i.e. no whitepoint adaptation)
 @end table
 
+@item clamptrc
+Clamps the linear and delinear transfer characteristics LUT values to the [0, 1] represented range.
+
 @item iall
 Override all input properties at once. Same accepted values as @ref{all}.
 
diff --git a/libavfilter/vf_colorspace.c b/libavfilter/vf_colorspace.c
index e1f4725f63..ad8596918f 100644
--- a/libavfilter/vf_colorspace.c
+++ b/libavfilter/vf_colorspace.c
@@ -123,6 +123,7 @@ typedef struct ColorSpaceContext {
     int fast_mode;
     enum DitherMode dither;
     enum WhitepointAdaptation wp_adapt;
+    int clamp_trc;
 
     int16_t *rgb[3];
     ptrdiff_t rgb_stride;
@@ -215,7 +216,9 @@ static int fill_gamma_table(ColorSpaceContext *s)
         } else {
             d = out_alpha * pow(v, out_gamma) - (out_alpha - 1.0);
         }
-        s->delin_lut[n] = av_clip_int16(lrint(d * 28672.0));
+        int d_rounded = lrint(d * 28672.0);
+        s->delin_lut[n] = s->clamp_trc ? av_clip(d_rounded, 0, 28672)
+                                       : av_clip_int16(d_rounded);
 
         // linearize
         if (v <= -in_beta * in_delta) {
@@ -225,7 +228,9 @@ static int fill_gamma_table(ColorSpaceContext *s)
         } else {
             l = pow((v + in_alpha - 1.0) * in_ialpha, in_igamma);
         }
-        s->lin_lut[n] = av_clip_int16(lrint(l * 28672.0));
+        int l_rounded = lrint(l * 28672.0);
+        s->lin_lut[n] = s->clamp_trc ? av_clip(l_rounded, 0, 28672)
+                                     : av_clip_int16(l_rounded);
     }
 
     return 0;
@@ -1000,6 +1005,11 @@ static const AVOption colorspace_options[] = {
     ENUM("vonkries", WP_ADAPT_VON_KRIES, "wpadapt"),
     ENUM("identity", WP_ADAPT_IDENTITY, "wpadapt"),
 
+    { "clamptrc",
+      "Clamps the linear and delinear LUT output values to the range [0, 1].",
+      OFFSET(clamp_trc), AV_OPT_TYPE_BOOL,  { .i64 = 0    },
+      0, 1, FLAGS },
+
     { "iall",       "Set all input color properties together",
       OFFSET(user_iall),   AV_OPT_TYPE_INT, { .i64 = CS_UNSPECIFIED },
       CS_UNSPECIFIED, CS_NB - 1, FLAGS, .unit = "all" },
-- 
2.49.1

_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org