ffmpeg 709 Colors

[GeoffreyA]

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

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, 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]

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.

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]

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

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]

Originally Posted by GeoffreyA

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

[GeoffreyA]

It produced an image file that MediaInfo could not read

I wonder if MediaInfo has implemented support as yet.

[poisondeathray]

Originally Posted by jay123210599

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]

Originally Posted by poisondeathray

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.

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

[poisondeathray]

Originally Posted by jay123210599

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]

Originally Posted by poisondeathray

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?

[poisondeathray]

Originally Posted by jay123210599

So you mean this:

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

yes

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?

"easier" or not depends on the person and preferences. For some people one method might be easier. Or not.

Vdub2 is not "automatic" - requires you to select the decode format interpretation as 709 for non colorimetry tagged input, otherwise 601 is used for the RGB conversion

The PNG compression step is lossless for either - but there will be slight differences in the 4:2:0 YUV to RGB conversion algorithms so they will not be exactly the same, but should be very close

[Balling]

pngcrush -m 40 -rem gAMA file.png withoutgAMA.png

[GeoffreyA]

While we're on the topic of zscale and colour spaces, is this the correct way of downscaling, from 1080p to 720p, in the linear domain:

-vf zscale=min=709:tin=709:pin=709:rin=limited:m=gbr:t=linear:p=709:dither=none,format=gbrpf32le,zscale=1280:-1:f=spline36,crop=%crop%,zscale=m=709:t=709:p=709:r=limited:dither=error_diffusion,format=yuv420p

[Z2697]

Originally Posted by GeoffreyA

While we're on the topic of zscale and colour spaces, is this the correct way of downscaling, from 1080p to 720p, in the linear domain:

-vf zscale=min=709:tin=709:pin=709:rin=limited:m=gbr:t=linear:p=709:dither=none,format=gbrpf32le,zscale=1280:-1:f=spline36,crop=%crop%,zscale=m=709:t=709:p=709:r=limited:dither=error_diffusion,format=yuv420p

I'm not sure if "rgb roundtrip" is necessary or not. Does linear light downscaling implies rgb?

[GeoffreyA]

I'm not too sure, but I think that linear-light YUV is not possible (whereas gamma-compressed RGB is).

[GeoffreyA]

Originally Posted by Z2697

I'm not sure if "rgb roundtrip" is necessary or not. Does linear light downscaling implies rgb?

You're right. I've been reading and breaking my head over this: going through RGB is best avoided because (1) scaling subsampled chroma up; (2) the troubled YUV > RGB > YUV conversion; and (3) scaling chroma down.

The following stays at YUV420 throughout the process, only raising the bit depth to 16 and later dithering down.

-vf zscale=min=709:tin=709:pin=709:rin=limited:m=709:t=linear:p=709:r=limited:dither=none,format=yuv420p16le,
    zscale=1280:-1:f=spline36,crop=%crop%,
    zscale=m=709:t=709:p=709:r=limited:dither=error_diffusion,format=yuv420p

[poisondeathray]

Originally Posted by GeoffreyA

You're right. I've been reading and breaking my head over this: going through RGB is best avoided because (1) scaling subsampled chroma up; (2) the troubled YUV > RGB > YUV conversion; and (3) scaling chroma down.

The following stays at YUV420 throughout the process, only raising the bit depth to 16 and later dithering down.

-vf zscale=min=709:tin=709:pin=709:rin=limited:m=709:t=linear:p=709:r=limited:dither=none,format=yuv420p16le,
    zscale=1280:-1:f=spline36,crop=%crop%,
    zscale=m=709:t=709:p=709:r=limited:dither=error_diffusion,format=yuv420p

The results are slightly different with linear Y scaling path , instead of linear scaling RGB path - The linear Y downscaling results are more saturated than they should be.

Chroma Up sampling and then down sampling can be lossless if nearest neighbor algorithm is used - but this factor is usually negligible because linear scaling is usually used and more important in the downscaling direction anyways


Here is one of the prototypical tests used for gamma scaling error "Calliphora_sp" . It has been cropped 1px on each side to 1292x1928, converted to a YUV420P8 "source" for testing. The goal is to downscale to half width and half height. The same command lines were used as the ones you posted (with width and height adjusted to the goal )

https://www.mediafire.com/file/ef77j...sting.zip/file

The zscale linear RGB path result closely matches what industry standard scalers do (e.g. NukeX). The explanation I've got from colorists is that gamma is a RGB defined concept, and it's not correct to perform in YUV

[jay123210599]

Originally Posted by poisondeathray

The PNG compression step is lossless for either - but there will be slight differences in the 4:2:0 YUV to RGB conversion algorithms so they will not be exactly the same, but should be very close

How are they different? Which one will have the higher quality?

[Z2697]

Originally Posted by poisondeathray

The results are slightly different with linear Y scaling path , instead of linear scaling RGB path - The linear Y downscaling results are more saturated than they should be.

Chroma Up sampling and then down sampling can be lossless if nearest neighbor algorithm is used - but this factor is usually negligible because linear scaling is usually used and more important in the downscaling direction anyways


Here is one of the prototypical tests used for gamma scaling error "Calliphora_sp" . It has been cropped 1px on each side to 1292x1928, converted to a YUV420P8 "source" for testing. The goal is to downscale to half width and half height. The same command lines were used as the ones you posted (with width and height adjusted to the goal )

https://www.mediafire.com/file/ef77j...sting.zip/file

The zscale linear RGB path result closely matches what industry standard scalers do (e.g. NukeX). The explanation I've got from colorists is that gamma is a RGB defined concept, and it's not correct to perform in YUV

Yeah... and zimg also scales chroma when performing transfer conversion, so keep YUV won't actually "save the chroma" anyways, well, unless you use point resize in the conversion, but then you do downscale, it doesn't really matter after all, better just go RGB.

[GeoffreyA]

Originally Posted by poisondeathray

The results are slightly different with linear Y scaling path , instead of linear scaling RGB path - The linear Y downscaling results are more saturated than they should be.

Many thanks, poisondeathray. I think I might end up dreaming of that fly's face tonight!

Apart from the increase in saturation, which is visibly off, the linear-Y path seems slightly sharper: at least on the hairs. The brightness on the eyes has also gone up. This is a source that I am going to keep and experiment with. Earlier today, when I put together the revised command, I tested a shot from Mulholland Drive and all looked identical, even scaling in gamma light.

The explanation I've got from colorists is that gamma is a RGB defined concept, and it's not correct to perform in YUV

Also, it's often advised to perform calculations or processing in RGB because of the maths.