[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:10 pdr0]:
 Well, first of all I consider H.273 to be mandatory. If it is not
 supported, then it should be fixed. We consider to fix it in Chrome,
 already added YCgCo with SW overlays from Nvidia and what not. Time for
 ICtCp patches in AVIF and then to Chromium.

 I also consider JPEG CMYK to be mandatory.

 >I'm using windows mpv-x86_64-20210316-git-5824d9f

 Just updated to this version, I still have perfect results on Windows, the
 same color. VERY strange, but it is what it is. I mean here is the
 screenshot if do not believe me.
 https://fastpic.ru/view/114/2021/0331/_30edaccc5667f45bb40a59a57bbe7d0a.png.html

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

 VUI flags are just an OETF for most cases, unless the EOTF is defined too
 in the standard, like for sRGB and SMPTE270M (here we apply the need
 transforms). In some cases like with xvYCC there is no EOTF at all. You
 can use BT.1886 for the BT.709 or BT.601 core of xvYCC but for extended
 gamut use of BT.1886 is inadequate, just like for HDR BT.1886 is not good
 enough, it was modified in BT.2390. So to answer you question, is not
 hardcoded, just for the EOTF in case of BT.2020 and BT.709 SDR we use sRGB
 EOTF, not BT.1886 as specified by Rec. BT.2020 and BT.709. We are going to
 reconsider sooner or later, of course. We will need normal EOTFs for
 constant luminance stuff.

 >if you move a color picker slightly - it fluctuates a bit -- output is
 dithered

 That is what MadVR does, I am not found of the idea. BT.601 is okay for
 that, because BT.601 uses different white point, so chromatic adaptation
 can be done by this hack.

 >I only see a PNG there, no BMP

 Yes, just convert it. BTW, I need to update that question with sRGB video.
 Ha.

 >-pix_fmt yuv420p

 I do not use it. It is still superblack, I will attach the sample. There
 are some values are off-by-one. I can attach a sample of that too.

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