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

FFmpeg trac at avcodec.org
Tue Mar 30 22:31:08 EEST 2021

#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:5 Balling]:
 > Replying to [comment:4 pdr0]:
 > >
 > > You can -vf scale...
 > >
 > No, you do not. The problem here is quite obvious: you need to remember
 what ffmpeg defaults to.
 > And now you need to remember what your source image is. The answer is
 quite obvious: it is sRGB, as everything PNG not tagged with chunks gAMA
 or cHRM or iCCP.
 > Now, what is the only matrix available for sRGB in the standards
 (iec61966_2_1 am. 1)? Right, BT.601 and such YCbCr colorspace is called
 > Now, next. What is the color primaries of sRGB? Right: they are BT.709.
 > So your command (with smaller png, 1080p maybe, is this a regression
 that bigger files are not supported??) is:
 > ffmpeg -y -t 4 -loop 1 -i 1.png -color_primaries bt709 -color_trc
 iec61966_2_1 -colorspace smpte170m  2.mp4
 > So here it is. The color is '''the same''' as in source picture (I am
 not so sure it will be for all colors, though, because we now have limited
 range!!!). Of course you need a good player for this that supports sYCC:
 > mpv.com --no-config 2.mp4
 > The result is that the very same color is there.
 > Again, you can rescale all of it, however you wanna. Even change the
 lattice. Just be careful.
 > I am not setting full range, because I am sure mpv is broken in full

 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

 Or if you want exact numbers, use 10bit YUV or RGB

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

More information about the FFmpeg-trac mailing list