Ffmpeg colour bugs

[mirh]

So.. Pretty nice guide you have here, but I think you slightly misunderstood the situation.
It is true that "all unspecified things the same" they stick to bt601, but the problem isn't really that there are assumptions about unknown still image formats (or better yet *videos*, because from png to jpg and webp I'm really skeptical any of them wouldn't have pretty rigorously documented default properties).
Everything is kind of a disaster because despite all of this, the program is then completely silent about such decisions (including within the final metadata) - and it is then the video players that have to try to guess what the color matrix is for yuv-rgb conversion.
And this is only one of the many shortcomings.

Long story short we have:

• files aren't tagged with their colorspace information (and I'd like to remember the SD=601 and HD=709 convention otherwise)
• unless using zscale, forget about extracting videos to jpeg (unsure about the other way around?)
• output pngs have wrong gamma (in one of the tags at least? depending on the software you may be good)
• colorspace and scale are also busted in their own ways with linear gamma conversions

There are too what you could call "slight rounding errors" (the last three links here), but for once they seem pretty minor.

[richardssam]

Hi, sorry for seeing this so late.

Lots of interesting things here, so it would be good to try and break it down.

I would love to understand more about "The Situation", for our particular use case of encoding PNG's to mov files, and maintaining quality, I do believe that it largely does boil down to a missing bt601, but also the RGB 2 YUV conversion is terrible, and at least for our test cases does seem to be improved by scale filter.

You do bring up an interesting point about colorspace in scale is broken for linear, but we are recommending that those sorts of conversion be done using OCIO outside of ffmpeg. We essentially dont trust ffmpeg too much so the less we do there the better, and I think that is particularly true for "linear" since you often want to do other color space conversions too (e.g. ACEScg to sRGB), and that also ignores that the TRC for rec709 is "Camera Rec709" not 1886, which almost everybody ignores.

Strictly speaking, the ticket you mention https://trac.ffmpeg.org/ticket/10000 is actually incorrect, it is "correctly" setting the gamma to 1.98 since that does approximate camera-rec709, which nobody actually interprets correctly.

For the "Slight Rounding errors" I'm definately want to build up a test suite for codecs, since it does seem like there are a number of issues extracting images to different file formats, for example, I've noticed that with prores_ks encodes, I need to add -sws_flags spline+accurate_rnd+full_chroma_int -vf scale=in_color_matrix=bt709:out_color_matrix=bt709 to get the correct output, but not for h264.

Thanks again for the feedback, I am in the process of pushing out an updated test suite, which I'm hoping to use, and perhaps test for some of these issues.