Changes to Video's Color

[Animeke]

Is there any settings or way to fix this issue? Is this a bug?

[mirh]

#123
It's absolutely a bug. But the culprit is ffmpeg technically.

[Animeke]

#123 It's absolutely a bug. But the culprit is ffmpeg technically.

Do you know of any fix or workaround?

[mirh]

Yes, I literally provide them in my link..
(even though whether it will work or not, depends on the mood of the half-assed flowframes workaround)

[Animeke]

Ah, didn't realize that was a link. Thanks, I'll try it out.

[neojam]

Yep, been a bug in ffmpeg since forever.
FFmpeg did always screw up colors on frame extraction to jpg/png.
At least for any of yuv420p sources, even if those are tagged correctly, like:
pix_fmt=yuv420p
color_range=tv
color_space=bt709
color_transfer=bt709
color_primaries=bt709

[mirh]

No, that's completely wrong.
Only extraction to jpeg is broken. Png is fine.
But what you have in mind is surely the other bug, i.e. the one in the encoding step that forgets to tag the output (which is always bt.601).

[neojam]

Not from my experience.
It's not as bad as it is the case with JPEGs, but still, the exported PNGs never match the source.
What ffmpeg settings do you use to extract to PNG?

From my experience exporting to PNG from ffmpeg darkens the image and crushes blacks.
Below is an example of SD-Video (1st frame only) followed by png/jpg of that frame that were exported from:
Premiere to PNG
Photoshop to PNG
ffmpeg to PNG
ffmpeg to JPG
(I attached the video source and all exported images, if you want to do your own tests.)

Exported PNGs from Photoshop and Premiere match the source video exactly. You can test it by opening both, the source video (pause on 1st frame) and PNG in ffplay, so they're on top of each other to check for differences.
The colors of PNG that was created with ffmpeg wont match the source (darker colors + crushed blacks)

compare2.mp4

compare2.zip

pix_fmt=yuv420p
level=31
color_range=tv
color_space=bt709
color_transfer=bt709
color_primaries=bt709
chroma_location=left
field_order=progressive

[mirh]

Oh, FFS I want to die. I'm speechless. >_<
great @ValZapod I summon you
Yes, there seems to be a small difference even when you remove gAMA.

[mirh]

Sigh... Am I going to assume this is https://trac.ffmpeg.org/ticket/9672?
Or is the sRGB chunk/handling unrelated to ICC?

[mirh]

So.. then.. am I correct in believing there's no bug report about this issue on the tracker?

EDIT: https://trac.ffmpeg.org/ticket/10000

Well, that BUG is technically fixed, because we added support for cICP in png, that has higher priority than gAMA chunk. So that means it now writes image with cICP OETF BT.709, that will show up correctly as 2.4 gamma in mpv, e.g., or even in ffmpeg.

[neojam]

I honestly don't know it any different. FFmpeg was behaving for me like that for years.
On bright HD scenes the color changes are not as visible, but for dark SD scenes, especially badly compressed ones its quite obvious.

[mirh]

If your issue is a big SD/HD difference, that must necessarily be the lack of tagging that I hinted from my first post.
You may have been headbanging while trying to understand it, because:

• a lot of professional editing tools reads png gAMA tags, which are screwed in ffmpeg (unclear where it's getting actually tracked, but hey, thankfully reading them doesn't work either!)
• flowframes tries to put up some quick smarty pants, not understanding the actual abomination beneath

TL;DR without any specific option, ffmpeg internally defaults to bt.601 without telling anybody (i.e. writing it down in metadata).
On top and besides of that though, we have much more:

• YUV formats (e.g. jpeg) are fucked OOTB when they differ in color range
• gamma is happily left to 2.2 despite whatever the output may be (I guess this is the minuscule tint that I still perceive once I have addressed everything else in this list.. or maybe they are the other little nitpicks)

[neojam]

Its not really my issue and all formats (SD/HD/etc.) are affected the same way (the color-mismatch is just more easily to spot on dark scenes for human eye). But whatever is really broken, I doubt it will be fixed anytime soon, I just wanted to point out that your assumption about PNG export being fine was wrong.

[mirh]

Cool.
Now there's only half a dozen of bugs to fix to go /s

EDIT: for some insane reason, 10 days ago all comments by @ValZapod disappeared
I could only save this from the memory hole

[Feynman1999]

Not from my experience. It's not as bad as it is the case with JPEGs, but still, the exported PNGs never match the source. What ffmpeg settings do you use to extract to PNG?

From my experience exporting to PNG from ffmpeg darkens the image and crushes blacks. Below is an example of SD-Video (1st frame only) followed by png/jpg of that frame that were exported from: Premiere to PNG Photoshop to PNG ffmpeg to PNG ffmpeg to JPG (I attached the video source and all exported images, if you want to do your own tests.)

Exported PNGs from Photoshop and Premiere match the source video exactly. You can test it by opening both, the source video (pause on 1st frame) and PNG in ffplay, so they're on top of each other to check for differences. The colors of PNG that was created with ffmpeg wont match the source (darker colors + crushed blacks)

compare2.mp4
compare2.zip

pix_fmt=yuv420p level=31 color_range=tv color_space=bt709 color_transfer=bt709 color_primaries=bt709 chroma_location=left field_order=progressive

on my mac m1 , the SD0000000001-ffmpeg.png is more likely same to mp4 , (photo shop and premiere looks darker), is it right?

[mirh]

Sounds like your video player may hav
mpv-player/mpv#534 (comment)
https://forum.blackmagicdesign.com/viewtopic.php?f=21&t=101253
Avoid apple stuff for accurate reproduction.