You've already forked FFmpeg
mirror of
https://github.com/FFmpeg/FFmpeg.git
synced 2025-09-16 08:36:51 +02:00
76471fb143
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.