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.
Signed-off-by: Drew Dunne <asdu...@google.com>
---
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 908c98a3cf..cb09d73f62 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.51.0.rc2.233.g662b1ed5c5-goog
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.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
