[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 pdr0):

 Replying to [comment:9 Balling]:
 >
 > The only one player that supports those very non-standard for video sRGB
 is mpv.
 >

 Right, so why make a non standard video that only plays correctly in a
 small% of players ? The numbers are slightly off anyways



 > 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.
 >


 I'm using windows mpv-x86_64-20210316-git-5824d9f , and the color varies
 in each channel if you move a color picker. Either way, it's always going
 to be off +/-3 when you check colors for 8bit YUV. It's mathematically not
 possible to have exact perfect colors for 8bit YUV. You always expect +/-3
 errors in each channel

 It's just that more players assume "709" for "HD" resolutions, so you're
 going to have similar colors +/-3 more often in more players (instead of
 way off like +/-30). Some players do not even read flags at all. So it's
 smarter to do the actual conversion with 709 matrix and flag it 709.


 >
 > No. We in Chrome use sRGB EOTF for BT.709 OETF.

 Is that hardcoded, or can video metadata VUI flags influence that ?



 > >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.
 >


 Yes - that's what I'm saying; for the purposes of this math/conversion
 discussion , we're not using like crf 40 or something on a typical content
 (ie not single color), where you'd
 contaminate the observations with lossy enocoding errors. You're not using
 subsampling, where the kernal used for resampling the U,V planes can and
 WILL generate YUV values that produce negative RGB values (out of gamut)




 > >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.


 I only see a PNG there, no BMP. Do you have the BMP, or should I convert
 PNG to BMP? Or just use those depicted RGB values?

 Note when you use -pix_fmt yuv420p such as in that link, you're using
 bicubic resampling for the chroma planes by default, so you would expect
 out of gamut values. Negative lobe and "sharper" kernals will generate
 more out of gamut values.

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