ffmpeg 709 Colors

[jay123210599]

This is the information for a video I have. If I make a png image sequence out of it using ffmpeg and/or Shutter Encoder, will the images have the 709 colors from the video?

Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings : CABAC / 4 Ref Frames
Format settings, CABAC : Yes
Format settings, Reference frames : 4 frames
Format settings, Slice count : 4 slices per frame
Codec ID : V_MPEG4/ISO/AVC
Duration : 23 min 43 s
Bit rate mode : Variable
Bit rate : 38.7 Mb/s
Maximum bit rate : 40.0 Mb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.779
Time code of first frame : 00:59:59:00
Stream size : 6.42 GiB (96%)
Default : No
Forced : No

[FranceBB]

Yes it will, however please note that it will convert the range from Limited TV Range to Full PC Range during the yv12 to rgb24 conversion.

Here's a simple yv12 limited tv range output generated to simulate your source:


ColorBars(848, 480, pixel_type="YV12")


https://i.imgur.com/QADXV1t.png

And here's the mediainfo of the corresponding PNG file:



General
Complete name : New File 000000.png
Format : PNG
Format/Info : Portable Network Graphic
File size : 3.54 KiB

Image
Format : PNG
Format/Info : Portable Network Graphic
Compression : Deflate
Format settings : Linear
Width : 848 pixels
Height : 480 pixels
Display aspect ratio : 16:9
Color space : RGB
Bit depth : 8 bits
Compression mode : Lossless
Stream size : 3.54 KiB (100%)


Notice how it has been converted from YV12 to RGB24, so from 4:2:0 8bit to RGB24 8bit.
BT709 is indeed still there and preserved, but given that Studio RGB (i.e RGB Limited TV Range) isn't really a thing outside of broadcast environments, pretty much any software that converts to RGB will make the picture Full PC Range. In the 8bit case we're going from 16-235 to 0-255. As a side note, the reason why Studio RGB is only used in broadcast and isn't really widespread is that SDI cables need some codes to carry stuff like the timecode and other sync codes, so you wouldn't be able to carry the whole 255 values.


Anyway, this can be easily simulated like this:


ColorBars(848, 480, pixel_type="YV12")
Converttoyv24(matrix="PC.709")
TurnRight.Histogram.TurnLeft #luma
Crop(0, 0, -0, -480)
Subtitle("Original Video Limited TV Range")
video=last

ImageSource("D:\New File (22)000000.png")
Converttoyv24(matrix="PC.709")
TurnRight.Histogram.TurnLeft #luma
Crop(0, 0, -0, -480)
Subtitle("Screenshot Full PC Range")
screenshot=last

StackVertical(video, screenshot)


https://i.imgur.com/4qTvmn0.png

As you can see, the first one, the original video, never exceeds the 235 top and only ever goes down the 16 bottom in one specific section on the right hand side dedicated to the super black. In other words, it's 8bit limited tv range. On the other hand, the second one, the screenshot, happily hits the 255 ceiling (i.e white) and 0 bottom (i.e black) as it's 8bit full pc range. Again, this kind of conversion is pretty safe and there aren't any issues unless you actually have out of range values (i.e things going above 235 or 0.7V and below 16 or 0.0V) 'cause when your 235 gets mapped to 255 anything above 235 is automatically lost as it can't be mapped above 255. In any case, in a properly graded and encoded limited tv range file there shouldn't be anything going out of range in the first place 'cause every TV is RGB Full PC Range anyway and it would perform the exact same conversion anyway, so any out of range highlight would be clipped out. This is exactly why I always tell all my coworkers to be extremely careful during live events and to always perform soft highlights rollback to dim them and make them fall within the 0.0-0.7V range.

[poisondeathray]

This is the information for a video I have. If I make a png image sequence out of it using ffmpeg and/or Shutter Encoder, will the images have the 709 colors from the video?

1) It depends on your commandline
2) For a source without colorimetry flags, unless otherwise specified, ffmpeg will use bt601 by default, not 709, for the YUV=>RGB conversion

[jay123210599]

1) It depends on your commandline
2) For a source without colorimetry flags, unless otherwise specified, ffmpeg will use bt601 by default, not 709, for the YUV=>RGB conversion

This is the my command line:
ffmpeg -i input.mkv output%d.png

So does both ffmpeg and Shutter need colorimetry flag in order to get the 709 colors? What about for making gifs, webps, and apngs?

[Z2697]

You should extract all planes individually and encode them to grayscale PNG. Absolute perfect color retention.

[GeoffreyA]

This is the my command line:
ffmpeg -i input.mkv output%d.png

You can try the following and see if it helps:

ffmpeg -colorspace bt709 -color_trc bt709 -color_primaries bt709 -color_range tv -i input.mkv output%d.png

Usually, I set that on all input, file or pipe, because most content is BT.709. If you're using a batch file, use two percentage signs on Windows.

[Z2697]

You can try the following and see if it helps:

ffmpeg -colorspace bt709 -color_trc bt709 -color_primaries bt709 -color_range tv -i input.mkv output%d.png

Usually, I set that on all input, file or pipe, because most content is BT.709. If you're using a batch file, use two percentage signs on Windows.

I'd rather use zscale :cool:
Faster and better.
The only benefit of swscale IMO is it can handle more obscure pixel formats.

[poisondeathray]

Beware the problem with ffmpeg using -colorspace etc..., or with colorimetry tagged files and using png output - is the output png still has gAMA and cHRM tags. This causes the colors to be displayed inconsistently in different programs . A browser may display certain colors, a picture viewer something else. Different source filters can display different colors. A long standing ffmpeg issue with several open tickets and discussion

For untagged files, I would use zscale too. If using swscale, beware it uses a "fast" less accurate conversion unless you use -sws_flags full_chroma_int+accurate_rnd

[jay123210599]

Beware the problem with ffmpeg using -colorspace etc..., or with colorimetry tagged files and using png output - is the output png still has gAMA and cHRM tags. This causes the colors to be displayed inconsistently in different programs . A browser may display certain colors, a picture viewer something else. Different source filters can display different colors. A long standing ffmpeg issue with several open tickets and discussion

For untagged files, I would use zscale too. If using swscale, beware it uses a "fast" less accurate conversion unless you use -sws_flags full_chroma_int+accurate_rnd

So yes, that and Shutter Encoder need colorimetry flags from videos in order to get the 709 colors? The same goes for making gifs, webps, and apngs?

[poisondeathray]

Shutter Encoder need colorimetry flags from videos in order to get the 709 colors? The same goes for making gifs, webps, and apngs?

Not sure, I don't use shutter encoder . It depends on what commands it's passing to ffmpeg, and/or other operations it's performing. Maybe it has some logic that makes assumptions about a given resolution and colorimetry. You can test it.

[GeoffreyA]

Z2697, poisondeathray, I do use zscale for actual conversion or scaling; no contest, it leaves swscale in the dust. However, I found that using those switches before the input merely sets the values for the internal structures, as far as I can tell from the debug log, and doesn't do any conversion (the auto-inserted swscale filter).

[jay123210599]

So what should I do for ffmpeg and Shutter Encoder to get the 709 colors when making images out of this type of video? Leave it as it is or add the flags to the video beforehand or during the conversion?

[poisondeathray]

So what should I do for ffmpeg and Shutter Encoder to get the 709 colors when making images out of this type of video? Leave it as it is or add the flags to the video beforehand or during the conversion?


1) If you leave it as-is, the default YUV to RGB conversion uses Rec601

2) For non colorimetry flagged sources - you control the conversion by specifying the input matrix as 709 using zscale or swscale. Use the sws scale switches mentioned above if you care about less error when using swscale.

eg

-vf zscale=min=709,format=gbrp


3) If you add the colorimetry flags to the source, or for sources with colorimetry flags already present , the ffmpeg PNG's will display incorrect colors in many programs, including browsers (!) - because of gAMA and cHRM tag issue. Other formats like GIF are not affected

[jay123210599]

3) If you add the colorimetry flags to the source, or for sources with colorimetry flags already present , the ffmpeg PNG's will display incorrect colors in many programs, including browsers (!) - because of gAMA and cHRM tag issue. Other formats like GIF are not affected

But why would there be gAMA and cHRM tag issues? So other formats like AVIF, JXL, WEBP, JPG, GIF, and APNG will automatically get the 709 colors, even if the colorimetry flags are not present in the source?

[poisondeathray]

But why would there be gAMA and cHRM tag issues?


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.



So other formats like AVIF, JXL, WEBP, JPG, GIF, and APNG will automatically get the 709 colors, even if the colorimetry flags are not present in the source?

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

[SeeMoreDigital]

Why can't us regular folk create Jpeg 2000 images as used with DCP (Digital Cinema Package)/DCI?

[hello_hello]

Why can't us regular folk create Jpeg 2000 images as used with DCP (Digital Cinema Package)/DCI?

Probably mostly due to patents.
https://en.wikipedia.org/wiki/JPEG_2000#Legal_status
Or maybe partly due to obsolescence.
https://en.wikipedia.org/wiki/JPEG_XL
JPEG_XL has a lossless mode. It seems to compare with PNG for compression only it's much slower (unless it's the IrfanView implementation or something peculiar to my setup).

[poisondeathray]

https://en.wikipedia.org/wiki/JPEG_XL
JPEG_XL has a lossless mode. It seems to compare with PNG for compression only it's much slower (unless it's the IrfanView implementation or something peculiar to my setup).


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

Here are some compression tests on a single image anime frame (notice the thread starter... he had multiple login handles that all got banned on that site for basically rehashing the same questions over and over... just saying....)

https://forum.videohelp.com/threads/413346-BMF-and-EMMA-files#post2722950

[hello_hello]

jay123210599,
SMPlayer can save screenshots of frames as it plays a video as png, webp or jpeg. I haven't messed around with it much but you can increase the playback speed by a fair amount so you shouldn't have to do it in real time. I'd be willing to give SMPlayer the benefit of the doubt in respect to always saving the images with the correct colors. Here's a few jpegs with a section of the rec.709 video they were taken from. Test.zip (https://files.videohelp.com/u/210984/Test.zip) (6.9 MB)

[huhn]

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


this is not fix by ffmpeg.
even if the meta data is correct programs will interpret them wrong.
one of these is literally the windows picture "app" it will assume that your display is gamma 2.2 so not the same issue where HDR assumes sRGB for SDR sources but similar.

well ffmpeg could fix interpreting bt 1886 as something around 2.0 by using the bt 709 encoding function for what ever reason. i don't hold my breath on that...

stripping is the way to go!

Why can't us regular folk create Jpeg 2000 images as used with DCP (Digital Cinema Package)/DCI?
doesn't this work for like 15 years or so:
https://developer.nvidia.com/nvjpeg2000-downloads?target_os=Windows
i guess i simply don't know about a DCI limitation?

[hello_hello]

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]

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




stripping is the way to go!



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

Or avoid ffmpeg for that scenario, or use workarounds .






image of my cat:



But of course... a cat :devil:

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]

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]

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]

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]

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]

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]

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]

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]

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]

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 :scared:

[Z2697]

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 :scared:

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]

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]

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.

[GeoffreyA]

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 :scared:

Here's a script that works with cjxl. Just paste it into a .bat file with Notepad. You can set the --effort parameter up to 10; the default is 7. It controls the efficiency-speed tradeoff and can be omitted for a cleaner command.

mkdir "out-jxl"

for %%i in (*.png *.jpg *.jpeg *.gif) do (

cjxl "%%i" "out-jxl\%%~ni.jxl" --effort 7

)

Place cjxl.exe, which you download from the libjxl Github repo (https://github.com/libjxl/libjxl/releases), in the same folder as the .bat file, along with some PNG or JPEG pictures. Upon running, it will convert them all, putting the JXL files in the "out-jxl" folder.

[jay123210599]

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.

What else can I use to make PNG and APNGs out of videos that will get the right colors? Will VirtualDub2 do the trick?

What about Shutter Encoder? Did you test it out and see if it got the right colors?

[Sunspark]

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 :scared:

https://jpegxl.info/resources/jpeg-xl-test-page

If your browser supports jxl you can just save-as, but if it doesn't, then you will need to look at the page source and replace the png saying no jxl with the jxl version.

[SeeMoreDigital]

Here's a script that works with cjxl. Just paste it into a .bat file with Notepad. You can set the --effort parameter up to 10; the default is 7. It controls the efficiency-speed tradeoff and can be omitted for a cleaner command.

mkdir "out-jxl"

for %%i in (*.png *.jpg *.jpeg *.gif) do (

cjxl "%%i" "out-jxl\%%~ni.jxl" --effort 7

)

Place cjxl.exe, which you download from the libjxl Github repo (https://github.com/libjxl/libjxl/releases), in the same folder as the .bat file, along with some PNG or JPEG pictures. Upon running, it will convert them all, putting the JXL files in the "out-jxl" folder.Thanks... I installed FFmpeg 7 a few days ago I and used the following code: 'ffmpeg -i input.png -effort 7 output.jxl'

It produced an image file that MediaInfo could not read but VirtualDub2 was able to see the .jxl file and detect the following properties: -

https://i.ibb.co/p3stDgg/Untitled.jpg

[GeoffreyA]

It produced an image file that MediaInfo could not read

I wonder if MediaInfo has implemented support as yet.

[poisondeathray]

What else can I use to make PNG and APNGs out of videos that will get the right colors?


You can use the ffmpeg commands in the post above



Will VirtualDub2 do the trick?


vdub doesn't write gAMA, cHRM tags for PNG - so it's unaffected by that issue. For unflagged files you'd need to set the decode format to 709 (because vdub also uses Rec601 for RGB conversion unless otherwise specified), for colorimetry flagged files I think it should be ok



What about Shutter Encoder? Did you test it out and see if it got the right colors?

I don't use shutter encoder, but if there is an extra commandline section you should be able to use the commands in earlier posts

[j7n]

You can transcode the PNGs with some other software that will remove the Gamma chunk, for example, IrfanView batch mode. Most common programs ignore it, but some go out of their way to respect it, such as JPEGli which will construct an ICC profile to emulate the useless gamma.

It's easy to see whether you get the 601 or 709 matrix looking at some face-like tones. 601 will be more red and 709 will be more green. Some video players guess by resolution or allow you to switch and preview (ffdshow).

[jay123210599]

You can use the ffmpeg commands in the post above

I don't use shutter encoder, but if there is an extra commandline section you should be able to use the commands in earlier posts

You mean this?
-colorspace bt709 -color_trc bt709 -color_primaries bt709 -color_range tv

Or this?
-vf zscale=min=709,format=gbrp

Shutter Encoder does have a commandline section to enter ffmpeg commands here (https://imgur.com/PmjQLdk).

By the way, why not use rgb24 instead of gbrp?

[poisondeathray]

You mean this?
-colorspace bt709 -color_trc bt709 -color_primaries bt709 -color_range tv


No because that will cause ffmpeg to write the PNG chunks when used as input options


Or this?
-vf zscale=min=709,format=gbrp


That is for unflagged sources, to specify the matrix


**See post #35


By the way, why not use rgb24 instead of gbrp?

zscale works with planar formats, gbrp is the pixel format identifier for planar rgb. If you use rgb24, it will go through a different path and introduce rounding errors - the values will be slightly off from expected or proper conversion

[jay123210599]

No because that will cause ffmpeg to write the PNG chunks when used as input options



That is for unflagged sources, to specify the matrix


**See post #35



zscale works with planar formats, gbrp is the pixel format identifier for planar rgb. If you use rgb24, it will go through a different path and introduce rounding errors - the values will be slightly off from expected or proper conversion

So you mean this:
-vf zscale=pin=2:p=2:tin=2:t=2:min=709,format=gbrp

Is it more convenient and simpler to use VirtualDub2 since they can automatically get the right colors for the videos and images (and much easier to correct them if they don't)? Will they produce the same results and have the same quality as ffmpeg pngs and apng files?