flowframes
flowframes copied to clipboard
n00mkrad
Changes to Video's Color
https://github.com/n00mkrad/flowframes/issues/123 It's absolutely a bug. But the culprit is ffmpeg technically.
#123 It's absolutely a bug. But the culprit is ffmpeg technically.
Do you know of any fix or workaround?
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)
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
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).
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)
https://user-images.githubusercontent.com/8310378/176689899-d3659f91-f7ea-4495-a997-9bf694b8bae0.mp4
pix_fmt=yuv420p level=31 color_range=tv color_space=bt709 color_transfer=bt709 color_primaries=bt709 chroma_location=left field_order=progressive
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.
when you remove gAMA.
As I said gAMA is supposed to be 2.4. It matters for Davinci, that does it correctly, e.g.
Sigh... Am I going to assume this is https://trac.ffmpeg.org/ticket/9672? Or is the sRGB chunk/handling unrelated to ICC?
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.
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.
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)
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.
Yes, there is none. I wanted to open but did not have time. Essentially BT.709 is supposed to be using pure 2.4 gamma EOTF on perfect OLED screen in the dark room. Yet they just invert OETF which is 1.9608.
чт, 30 июн. 2022 г., 23:08 mirh @.***>:
So.. then.. am I correct in believing there's no bug report about this issue on the tracker?
— Reply to this email directly, view it on GitHub https://github.com/n00mkrad/flowframes/issues/157#issuecomment-1171628526, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHQOBJVPOQRLBZKZGCFMSYDVRX5CDANCNFSM52A7RFHA . You are receiving this because you were mentioned.Message ID: @.***>
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
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?
~~Sounds like your video player may hav~~ https://github.com/mpv-player/mpv/issues/534#issuecomment-34568591 https://forum.blackmagicdesign.com/viewtopic.php?f=21&t=101253 Avoid apple stuff for accurate reproduction.