ffmpeg 709 Colors

[hello_hello]

Originally Posted by poisondeathray

Compression wise JPEG-XL is much better than png at the highest compression levels, but much slower

Yeah, it looks like you're correct. I had the "Progressive JXL" option checked.

A 1080p(ish) image of my cat (taken with a very old phone so it doesn't have a huge amount of detail):

PNG default compression 6 - 1,687,864 bytes
PNG maximum compression 9 - 1,568,618 bytes
JXL default speed 7 - 923,194 bytes
JXL slowest speed 9 - 898,895 bytes
Progessive JXL speed 7 - 2,210,651 bytes
Progessive JXL speed 9 - 1,703,089 bytes

JXL lossy 90% quality - 181,999 bytes
JPEG 90% quality - 298,577 bytes
JPEG 90% quality, no chroma sub-sampling - 322,603 bytes

The default lossless speed is usable but faster speeds are very slow for what appears to be only a small increase in compression, at least in non-progressive mode.

[poisondeathray]

Originally Posted by huhn

this is not fix by ffmpeg.
even if the meta data is correct programs will interpret them wrong.

Yes, it's a mess.

Just think of the browser case alone, and the millions/billons of incorrectly displayed PNG images on the net (!) . Think of all the software that uses ffmpeg for the backend, and they probably use the "auto" conversion routine. And it's not just a little bit off, sometimes it's +/- 10-12 valuesfor 8bit RGB (!) .

Not only that, they probably use the "fast" swscale conversion, not the accurate swscale conversion algorithm, another few pixel values off (regardless of PNG tags). Even grey scale values can be off for the latter (!). I'd argue the swscale accurate conversion routine should be the default setting when using swscale. It's not 2001 anymore with single core computers.

What's the point of using a "lossless" format if the displayed values are off, sometimes significantly waaay off , or a some avoidable rounding errors are introduced from a fast conversion. ?

The truth is nobody care much about color accuracy. It if looks mostly ok, that's good enough for most people

Originally Posted by huhn

stripping is the way to go!

I'm sure that's what you say to all the ladies

Or avoid ffmpeg for that scenario, or use workarounds .

Originally Posted by hello_hello

 image of my cat:

But of course... a cat

No, seriously live action content can often compresses differently than anime or cartoons, so thanks for that quicky test

But in terms of compatibility, jpeg-xl still has quite low compatibility for usage cases. For compatibility, unfortunately PNG is still up there for lossless. webp is better in terms of lossless RGB compression, decent for compatibility but still a distant second to PNG

[GeoffreyA]

I think JPEG XL should be the gold standard for most use cases, lossy and lossless, and especially at the higher end of quality; we've finally got a successor to JPEG, GIF, and PNG, but astonishingly, it is scarcely supported anywhere. Doubtless, there are agendas not to do so: Chrome, for example, did but support was removed or disabled. Apple is supporting it, though.

When I tried cjxl, I was impressed with the results; it beat cjpegli, PNG, and losslessly repacked old JPEGs, gaining a bit of compression. The last feature would be useful in squeezing the size of the many mobile photos we have today, taking up GB after GB.

Gianni Rosato, the SVT-AV1-PSY developer, did some comparisons:

https://giannirosato.com/blog/post/jpegli/
https://giannirosato.com/blog/post/image-comparison/

[Z2697]

JXL is NOT scarcely supported in most areas, especially in free softwares, but it is scarcely supported in browsers just because some "guy" at Google randomly decided to ditch it and Mozilla also randomly decided to put it behind "beta" walls, that just eliminated 80% of the potential user, thus probably eliminated 99% of the potential use case. (no one wants their pictures only visible to 20% of the users right?)
(I'm calm, I'm very calm)

Although it kinda sounds like "big social media companies offloads their bandwidth cost to people who uses their products (computational cost when decoding)", unlike AV1 which has hardware decoding (although YouTube uses software decoding when HW decoding is not available instead of fallback to VP9), but big medias are gonna "save" the bandwidth anyways, if it's not cost you computational power, then it's quality of the content the cost.

[GeoffreyA]

Concerning FFmpeg's -colorspace switches, it seems that setting them before the input merely marks the stream and doesn't do any conversion. Setting them after the input causes swscale to be called several times.

Before:

ffmpeg -loglevel debug -colorspace bt709 -color_trc bt709 -color_primaries bt709 -color_range tv -i Meridian.mp4 -frames:v 1 -f null -

[vost#0:0/wrapped_avframe @ 0000023d4cd81000] Starting thread...
[vf#0:0 @ 0000023d4cd7c600] Starting thread...
[vist#0:0/h264 @ 0000023d4d5b6040] [dec:h264 @ 0000023d4cd7c780] Starting thread...
[in#0/mov,mp4,m4a,3gp,3g2,mj2 @ 0000023d4cd77000] Starting thread...
Press [q] to stop, [?] for help
[h264 @ 0000023d4d431c00] nal_unit_type: 6(SEI), nal_ref_idc: 0
[h264 @ 0000023d4d431c00] nal_unit_type: 5(IDR), nal_ref_idc: 3
[h264 @ 0000023d4d431c00] Format yuv420p chosen by get_format().
[h264 @ 0000023d4d431c00] Reinit context to 3840x2160, pix_fmt: yuv420p
[h264 @ 0000023d4d431c00] no picture
[h264 @ 0000023d4d249700] nal_unit_type: 1(Coded slice of a non-IDR picture), nal_ref_idc: 2
[h264 @ 0000023d4d249700] no picture
[h264 @ 0000023d4d302480] nal_unit_type: 1(Coded slice of a non-IDR picture), nal_ref_idc: 2
[h264 @ 0000023d4d302b40] nal_unit_type: 1(Coded slice of a non-IDR picture), nal_ref_idc: 0
[h264 @ 0000023d4d5aa3c0] nal_unit_type: 1(Coded slice of a non-IDR picture), nal_ref_idc: 0
[h264 @ 0000023d4d431c00] nal_unit_type: 1(Coded slice of a non-IDR picture), nal_ref_idc: 2
[h264 @ 0000023d4d249700] nal_unit_type: 1(Coded slice of a non-IDR picture), nal_ref_idc: 2
[graph -1 input from stream 0:0 @ 0000023d4cd80700] w:3840 h:2160 pixfmt:yuv420p tb:1/60000 fr:60000/1001 sar:1/1 csp:bt709 range:tv
[AVFilterGraph @ 0000023d4d5b33c0] query_formats: 3 queried, 6 merged, 0 already done, 0 delayed
Output #0, null, to 'pipe:':

https://pastebin.com/SS5QN5Sa

After:

ffmpeg -loglevel debug -i Meridian.mp4 -colorspace bt709 -color_trc bt709 -color_primaries bt709 -color_range tv -frames:v 1 -f null -

[vost#0:0/wrapped_avframe @ 000002654ca40fc0] Starting thread...
[vf#0:0 @ 000002654ca3c580] Starting thread...
[vist#0:0/h264 @ 000002654d246040] [dec:h264 @ 000002654ca3c740] Starting thread...
[in#0/mov,mp4,m4a,3gp,3g2,mj2 @ 000002654ca37000] Starting thread...
Press [q] to stop, [?] for help
[h264 @ 000002654d0c1bc0] nal_unit_type: 6(SEI), nal_ref_idc: 0
[h264 @ 000002654d0c1bc0] nal_unit_type: 5(IDR), nal_ref_idc: 3
[h264 @ 000002654d0c1bc0] Format yuv420p chosen by get_format().
[h264 @ 000002654d0c1bc0] Reinit context to 3840x2160, pix_fmt: yuv420p
[h264 @ 000002654d0c1bc0] no picture
[h264 @ 000002654ced9700] nal_unit_type: 1(Coded slice of a non-IDR picture), nal_ref_idc: 2
[h264 @ 000002654ced9700] no picture
[h264 @ 000002654cadeac0] nal_unit_type: 1(Coded slice of a non-IDR picture), nal_ref_idc: 2
[h264 @ 000002654cf92ac0] nal_unit_type: 1(Coded slice of a non-IDR picture), nal_ref_idc: 0
[h264 @ 000002654d3b8b80] nal_unit_type: 1(Coded slice of a non-IDR picture), nal_ref_idc: 0
[h264 @ 000002654d0c1bc0] nal_unit_type: 1(Coded slice of a non-IDR picture), nal_ref_idc: 2
[h264 @ 000002654ced9700] nal_unit_type: 1(Coded slice of a non-IDR picture), nal_ref_idc: 2
[graph -1 input from stream 0:0 @ 000002654ca200c0] w:3840 h:2160 pixfmt:yuv420p tb:1/60000 fr:60000/1001 sar:1/1 csp:unknown range:unknown
[format @ 00000265519fa400] Setting 'color_spaces' to value 'bt709'
[h264 @ 000002654cadeac0] nal_unit_type: 1(Coded slice of a non-IDR picture), nal_ref_idc: 0
[format @ 00000265519fa400] Setting 'color_ranges' to value 'tv'
[auto_scale_0 @ 000002654ca40740] w:iw h:ih flags:'' interl:0
[format @ 00000265519fa400] auto-inserting filter 'auto_scale_0' between the filter 'Parsed_null_0' and the filter 'format'
[h264 @ 000002654cf92ac0] nal_unit_type: 1(Coded slice of a non-IDR picture), nal_ref_idc: 0
[AVFilterGraph @ 000002654d244e80] query_formats: 4 queried, 6 merged, 3 already done, 0 delayed
[auto_scale_0 @ 000002654ca40740] w:3840 h:2160 fmt:yuv420p csp:unknown range:unknown sar:1/1 -> w:3840 h:2160 fmt:yuv420p csp:bt709 range:tv sar:1/1 flags:0x00000004
[auto_scale_0 @ 000002654ca40740] [framesync @ 0000026551a684d0] Selected 1/60000 time base
[auto_scale_0 @ 000002654ca40740] [framesync @ 0000026551a684d0] Sync level 1
[h264 @ 000002654d3b8b80] nal_unit_type: 1(Coded slice of a non-IDR picture), nal_ref_idc: 2
[graph -1 input from stream 0:0 @ 000002654ca200c0] video frame properties congruent with link at pts_time: 0
[h264 @ 000002654d0c1bc0] nal_unit_type: 1(Coded slice of a non-IDR picture), nal_ref_idc: 2
[h264 @ 000002654ced9700] nal_unit_type: 1(Coded slice of a non-IDR picture), nal_ref_idc: 0
[swscaler @ 0000026551bb2280] YUV color matrix differs for YUV->YUV, using intermediate RGB to convert
[h264 @ 000002654cadeac0] nal_unit_type: 1(Coded slice of a non-IDR picture), nal_ref_idc: 0
Output #0, null, to 'pipe:':

https://pastebin.com/k36cAHXw

[GeoffreyA]

Originally Posted by Z2697

JXL is NOT scarcely supported in most areas, especially in free softwares, but it is scarcely supported in browsers just because some "guy" at Google randomly decided to ditch it and Mozilla also randomly decided to put it behind "beta" walls, that just eliminated 80% of the potential user, thus probably eliminated 99% of the potential use case. (no one wants their pictures only visible to 20% of the users right?)
(I'm calm, I'm very calm)

Although it kinda sounds like "big social media companies offloads their bandwidth cost to people who uses their products (computational cost when decoding)", unlike AV1 which has hardware decoding (although YouTube uses software decoding when HW decoding is not available instead of fallback to VP9), but big medias are gonna "save" the bandwidth anyways, if it's not cost you computational power, then it's quality of the content the cost.

Exactly. Well, everything on Earth is mostly a racket, despite lip-service to the contrary. The long and short of it is that Google controls a lot, and in the case of JXL, they perhaps wanted WebP to prosper. It's disgusting when politics and agendas supersede technical merit.

[Z2697]

Originally Posted by GeoffreyA

Exactly. Well, everything on Earth is mostly a racket, despite lip-service to the contrary. The long and short of it is that Google controls a lot, and in the case of JXL, they perhaps wanted WebP to prosper. It's disgusting when politics and agendas supersede technical merit.

Google even contributed like 50% of the JXL "techs", at least the initial draft or so.
WebP and AVIF are free format as well, I don't think they are the reason behind the removal of JXL.
(Or maybe, in a conspiracy view, they aren't really free after all, Google has some secrect income from them?)

[SeeMoreDigital]

Originally Posted by Z2697

JXL is NOT scarcely supported in most areas, especially in free softwares, but it is scarcely supported in browsers just because some "guy" at Google randomly decided to ditch it and Mozilla also randomly decided to put it behind "beta" walls, that just eliminated 80% of the potential user, thus probably eliminated 99% of the potential use case. (no one wants their pictures only visible to 20% of the users right?)

As disappointing as it is that web browsers don't support JPEG XL images, it would be handy if AV software's such as FFmpeg and VirtualDub2 where able to import and export them.

[Z2697]

Originally Posted by SeeMoreDigital

As disappointing as it is that web browsers don't support JPEG XL images, it would be handy if AV software's such as FFmpeg and VirtualDub2 where able to import and export them.

FFmpeg can, through libjxl. Not sure about other thousands of softwares using FFmpeg tools or libraries, but most likely it's just a matter of an extra compile setting.

[GeoffreyA]

Originally Posted by Z2697

Google even contributed like 50% of the JXL "techs", at least the initial draft or so.
WebP and AVIF are free format as well, I don't think they are the reason behind the removal of JXL.
(Or maybe, in a conspiracy view, they aren't really free after all, Google has some secrect income from them?)

I don't know what the reason was, and it is paradoxical because, as you point out, Google contributed a lot to JXL. All I can say is that these big corporations are sorely lacking in the good-faith department, and it's inexcusable that there isn't widespread support for this excellent format. Even Windows out of the box, as far as I'm aware.

[jay123210599]

Originally Posted by poisondeathray

Ask a ffmpeg developer . There are tickets for this already.

The gAMA, cHRM tag issue is specific to PNG . Even if the underlying YUV to RGB conversion in ffmpeg is correct, the PNG can have problems being displayed in programs

The most consistent PNG display is no gAMA, cHRM tags - it essentially displays the same everywhere

It's easy to verify this, if you strip the gAMA, cHRM tags, the PNG now displays correctly in browsers and other programs.




No .

see #2 in the post above "For non colorimetry flagged sources..."

Also point #2 in my first reply "For a source without colorimetry flags, unless otherwise specified,..."


Nothing is guaranteed to be automatically correct in ffmpeg-land. You should always verify your workflow, because there are a bunch of "gotchas"


Jpeg is different because there are YUV variants, subsampled variants, RGB variants. Also, it is supposed to use full range 601 (pc 601) - as per the jpeg spec , not Rec709, not limited range. Common conversions should be handled correctly automatically in ffmpeg already (because jpeg is/was so common, all the bugs have been fixed), but you can test and verify . Obscure input formats might need some other switches for the correct conversion

AVIF isalso different because they have pixel format variations as well, possible different conversions. For example a YUV AVIF wouldn't need any changes to matrix, because the input is YUV. You aren't converting to RGB in that case

Webp lossless is RGB only, but lossy web is YUV. So you have to control the YUV to RGB conversion for lossless webp for the correct colors, otherwise bt601 is used

GIF is actually PAL8 , not sure if the conversion is correct, you have to test

But what about APNG? So even if I use a video with colorimetry flags, it will still get the wrong colors for PNG files because of the gAMA, cHRM tags? How do I strip them to solve the problem?

[Z2697]

OMG, this guy is worse than ChatGPT.

[poisondeathray]

Originally Posted by jay123210599

But what about APNG?

Yes ffmpeg apng is affected .

So even if I use a video with colorimetry flags, it will still get the wrong colors for PNG files because of the gAMA, cHRM tags?

It will display the wrong colors in many programs.

How do I strip them to solve the problem?

I use tweakpng to delete tags, I don't know if there are better tools, I haven't really looked into it because I prefer not have the problem in the first place. I don't know if it has a CLI batchable interface. It would be pretty awful to manually process an image sequence one by one

Workarounds are to pipe ffmpeg to ffmpeg , or aviysnth script clearing the props like propclearall() - so in that case it would "look" to ffmpeg like an unflagged file, then you could use zcale to control the YUV=>RGB conversion in ffmpeg. You could also do the YUV=>RGB conversion directly in the avs script , and/or use it to write out a png sequence.

[Z2697]

Originally Posted by poisondeathray

Yes ffmpeg apng is affected .



It will display the wrong colors in many programs.



I use tweakpng to delete tags, I don't know if there are better tools, I haven't really looked into it because I prefer not have the problem in the first place. I don't know if it has a CLI batchable interface. It would be pretty awful to manually process an image sequence one by one

Workarounds are to pipe ffmpeg to ffmpeg , or aviysnth script clearing the props like propclearall() - so in that case it would "look" to ffmpeg like an unflagged file, then you could use zcale to control the YUV=>RGB conversion in ffmpeg. You could also do the YUV=>RGB conversion directly in the avs script , and/or use it to write out a png sequence.

You can use

zscale=pin=2:p=2:tin=2:t=2

to make FFmpeg think the flags are unknown, and will not create those PNG chunks.

[poisondeathray]

Originally Posted by Z2697

You can use

zscale=pin=2:p=2:tin=2:t=2

to make FFmpeg think the flags are unknown, and will not create those PNG chunks.

It works.

So for the OP it only requires 1 zscale call and would look like

-vf zscale=pin=2:p=2:tin=2:t=2:min=709,format=gbrp

[SeeMoreDigital]

Does anybody have any Jpeg XL samples I can store on my 'Test Files HDD'?

I tried downloading some from the web but they download as PNG

[Z2697]

Originally Posted by SeeMoreDigital

Does anybody have any Jpeg XL samples I can store on my 'Test Files HDD'?

I tried downloading some from the web but they download as PNG

It really isn't that obscure... Encode some your own with cjxl or FFmpeg
https://github.com/libjxl/libjxl/releases
https://www.gyan.dev/ffmpeg/builds/

[SeeMoreDigital]

Originally Posted by Z2697

It really isn't that obscure... Encode some your own with cjxl or FFmpeg
https://github.com/libjxl/libjxl/releases
https://www.gyan.dev/ffmpeg/builds/

Thanks, but sadly, I'm not commandline person.

[Z2697]

Originally Posted by SeeMoreDigital

Thanks, but sadly, I'm not commandline person.

There's official test data as well
https://github.com/libjxl/testdata

[SeeMoreDigital]

Thanks... but it's way above my skill set.