[FFmpeg-trac] #11182(swscale:closed): yuvtestsrc and yuv444p->rgba->yuv444p conversion result in huge difference
FFmpeg
trac at avcodec.org
Tue Sep 10 04:55:25 EEST 2024
#11182: yuvtestsrc and yuv444p->rgba->yuv444p conversion result in huge difference
-------------------------------------+-------------------------------------
Reporter: Andrew-R | Owner: (none)
Type: defect | Status: closed
Priority: normal | Component: swscale
Version: unspecified | Resolution: invalid
Keywords: colorspace | Blocked By:
color_primaries |
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0 |
-------------------------------------+-------------------------------------
Comment (by Balling):
>Mathematically makes no sense: At the same bit-depth, where comes such
difference?
In the case with full range RGB to full range YCbCr... There are some
values in YCbCr that will be negative R', G', B'. (For example in limited
range YCbCr BT.709 values 139, 151, 24 will be limited (!) RGB -21, 182,
181 and full RGB -43, 194, 192.)
https://stackoverflow.com/questions/32321631/is-converting-ycbcr-to-rgb-
reversible
The bit depth does not play any role. Even 12 bit YCbCr is still 6 times
bigger than RGB. What makes the change is if you use BT.2020 linear RGB
now, that would be bigger than YCbCr and that is how:
>While most (if not all?) displays expect RGB from hardware aspect..?
My LG C9 supports direct rendering of YCbCr data (and so do Intel and
Nvidia), there is no RGB in it, it is WRGB. Moreover the way this works is
that the color engagement works through XYZ, not RGB.
Here
--
Ticket URL: <https://trac.ffmpeg.org/ticket/11182#comment:11>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list