[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:10 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 slightly - it fluctuates a bit,
 almost as if output is dithered.  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 from 8bit RGB for the majority
 of colors. 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, ffmpeg is 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, right around where the color borders are
 adjacent. Especially colors against black and white (min and max) values.
 >

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