[FFmpeg-trac] #9167(undetermined:closed): Color changed when an image converting to video

[FFmpeg]

#9167: Color changed when an image converting to video
-------------------------------------+-------------------------------------
             Reporter:  kvsico       |                    Owner:
                 Type:  defect       |                   Status:  closed
             Priority:  normal       |                Component:
                                     |  undetermined
              Version:  unspecified  |               Resolution:  invalid
             Keywords:               |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------

Comment (by Balling):

 Replying to [comment:7 pdr0]:
 > It's close, but the colors are not exactly the same
 >
 > It's close in MPV, MPCHC, VLC,  but with the expected +/- rounding
 errors.
 > Original 238,77,45
 > MPV 237,76,44
 > MPCHC 237,77,44
 > VLC 237,76,44
 > FFplay 252,90,41
 > Potplayer 251,89,39
 >
 > FFplay and Potplayer are way off
 >
 >
 > If using 8bit YUV, I would use 709 and do it the other way with -vf
 scale, because more players will have similar close values +/-3 . Every
 player including FFplay, Potplayer, dozens others will look close,
 including browsers
 >
 > Or if you want exact numbers, use 10bit YUV or RGB

 MPC uses FFmpeg and does not really support sRGB in video. So does VLC
 (and very old version) and FFplay. FFplay does not support colorspaces
 good enough, because SDL library.

 The only one player that supports those very non-standard for video sRGB
 is mpv.

 I do not know what version of mpv you use, but here on Windows (Windows
 has much better pow function, just for example, LOL) mpv does give 238,
 77, 44. Just saying, I will attach a sample.

 >will look close, including browsers

 No. We in Chrome use sRGB EOTF for BT.709 OETF. So you are very off here.
 Unfortunately no choice here, everything else is done for sRGB ambient
 light, we cannot use BT.1886 as it is for dark ambient. Maybe when we will
 get TrueTone fully...
 >lossy differences

 There are no lossy differences on '''one''' color. At least in x264. 4:2:0
 also preserves all colors, on one color that is.

 >All out of gamut values have already been eliminated by definition

 I would not be so sure about that, use --gamut-warning in mpv. You will be
 surprised. On default setting x264 does produce out-of-gamut (unless there
 is another bug in --gamut-warning). Oopsie. Use this bmp sample for
 example: https://video.stackexchange.com/questions/19944/ffmpeg-bmp-to-
 yuv-x264-color-shift It gives superblack.

--
Ticket URL: <https://trac.ffmpeg.org/ticket/9167#comment:9>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker