[FFmpeg-trac] #9407(ffmpeg:reopened): Broken Conversion: yuv444p10le to yuv444p
FFmpeg
trac at avcodec.org
Mon Sep 6 06:01:17 EEST 2021
#9407: Broken Conversion: yuv444p10le to yuv444p
-------------------------------------+-------------------------------------
Reporter: Michael | Owner: (none)
Witten |
Type: defect | Status: reopened
Priority: normal | Component: ffmpeg
Version: unspecified | Resolution:
Keywords: pix_fmt yuv | Blocked By:
yuv444p10le yuv444p 10-bit format |
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0 |
-------------------------------------+-------------------------------------
Comment (by Balling):
>I think a transfer function issue
a) we do not support EOTF awared scale, see #6694
b) ycbcr to ycbcr does not require going to linear RGB. Everything is done
on R'G'B. (The exceptions are of course newer ICtCp, BT.2020-cl
(everything on Blu-ray and streams uses bt.2020-'''n'''cl though)) and
chromaticity derived constant luminance systems. Those operate on linear
light).
c) Please note that Imagemagick has a bug that it says it is sRGB when it
only has gAMA chunk without sRGB chunk, it is present on all from svg
images on wikipedia, an insane bug that destroyes colors. And also that
0.4545445 is just 2.2 pure gamma which is not sRGB, in this case ffmpeg
appers to set the tag and even say it is perceptual rendering intent
inside sRGB chunk. Now, perceptual can be handled very differently by
different software, so... also please note that it is tagged as sRGB, but
the correct is gAMA chunk of 1/2.4, since BT.709 transfer must be
presented using 2.4 pure gamma on perfect display. This is also a bug in
ffmpeg, of course. We do ot change the transfer either.
Now, I do not think how you think we will fix it if it were not fixed in
the past 10 years or so...
--
Ticket URL: <https://trac.ffmpeg.org/ticket/9407#comment:9>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list