ffmpeg 709 Colors

[poisondeathray]

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]

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]

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]

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/ef77jno7fxpc2lc/Calliphora_YUV420P8_linear_gamma_scaling_testing.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]

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]

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/ef77jno7fxpc2lc/Calliphora_YUV420P8_linear_gamma_scaling_testing.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]

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.

[poisondeathray]

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


You can compare them. They will be similar in quality, but they are not bit identical.

Difficult to say which is "higher quality", because they are both technically lossy compared to the source. 8bit RGB is a lossy converted representation of 8bit 4:2:0 YUV data - and you cannot get back the original values - so an 8bit (or 16bit) PNG is lossy compared to the source by that definition

The main differences are due to the chroma upscaling algorithms used (if you test using a 4:4:4 source, the differences are reduced) , but there are other differences as well



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.

You can repeat with YUV 4:4:4 src tests with no chroma scaling for the RGB step and you get similar findings


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.


Yes , and just because there is one proposed method of linear gamma scaling , it doesn't mean you should use it. Use whatever works for your goals . Some people like merging the extracted Y from the linear-Y path with the extracted CbCr from the linear-RGB path with a weighting , for example, or whatever combination.

BTW , the original jpg (stored as YUV444 fullrange) src image
https://en.wikipedia.org/wiki/File:Calliphora_sp_Portrait.jpg


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

Personally, I prefer using RGB for color manipulations . RGB is an additive model. It makes intuitive sense to me 1+1=2. Some people are able to do it successfully fully in YCbCr... I find it more difficult to do in YCbCr for more than simple manipulations

[Z2697]

I mean, I totally agree that doing it in RGB is the right way, I added some point to it: chroma scaling is still involved so the performance and sharpness (of chroma) will still be affected, unless (maybe) point resize is used.
YUV is weird, man. It's a legacy from analog era, it serves... virtually nothing in modern times.
Well, subsampling saves encoding and decoding time, and the encoder is more efficient in compressing YUV in contrast to RGB, but what if we have switched to RGB long time ago? Things will be designed around RGB and maybe not subsampling, but encoders will be better at RGB.

It's just that I always hesitate to convert back and forth bwtween YUV and RGB during process, when 99.9% of the source we can get are already YUV420.

[huhn]

while subsampling is just counterproductive YCbCr is not for lossy encoding.
the power to use less bit rate for Cb and Cr is to powerful and can not be beaten or reached with RGB.

there are other types that make converting back and for easier but using "lossy" complex one like ITP should be the future.

[GeoffreyA]

Yes , and just because there is one proposed method of linear gamma scaling , it doesn't mean you should use it. Use whatever works for your goals . Some people like merging the extracted Y from the linear-Y path with the extracted CbCr from the linear-RGB path with a weighting , for example, or whatever combination.

I suppose like most things, the "best" approach is often a hybrid method, combining the best of each.

BTW , the original jpg (stored as YUV444 fullrange) src image
https://en.wikipedia.org/wiki/File:Calliphora_sp_Portrait.jpg

Thanks.

I mean, I totally agree that doing it in RGB is the right way, I added some point to it: chroma scaling is still involved so the performance and sharpness (of chroma) will still be affected, unless (maybe) point resize is used.
YUV is weird, man. It's a legacy from analog era, it serves... virtually nothing in modern times.
Well, subsampling saves encoding and decoding time, and the encoder is more efficient in compressing YUV in contrast to RGB, but what if we have switched to RGB long time ago? Things will be designed around RGB and maybe not subsampling, but encoders will be better at RGB.

YUV is confusing, whereas RGB makes practical sense, reflecting what we learn about the primary colours in everyday life, and even a child could understand it. Though a relic of the past, YUV more closely reflects the way our eyes work and exploits that, similar to audio compression paying more attention to the frequencies ours ears are most sensitive to. But I agree that life would be easier with RGB.

[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.

Here's my ticket on the matter. Do you think the developers of ffmpeg would respond?

https://trac.ffmpeg.org/ticket/11443

[huhn]

you can only argue about what ffmpeg writes in but the "issue" is only fixed by not writing it only wrong information like 2.22 for windows user.

mpc-hc writes 2.2 or 2.22 so the result is correct on windows even through the value is wrong.

mpv writes or was writing utter none sense like 1.967(approximation of bt 709 encoding transfer function...) which supposedly works on mac. this was copied from ffmpeg.

while the solution is not writing it.

this here is only about gamma and gAMA.
if you add the correct 2.4 you will get wrong results because Microsoft expect your display is sRGB this is a lost cause don't add it.

[jay123210599]

you can only argue about what ffmpeg writes in but the "issue" is only fixed by not writing it only wrong information like 2.22 for windows user.

mpc-hc writes 2.2 or 2.22 so the result is correct on windows even through the value is wrong.

mpv writes or was writing utter none sense like 1.967(approximation of bt 709 encoding transfer function...) which supposedly works on mac. this was copied from ffmpeg.

while the solution is not writing it.

this here is only about gamma and gAMA.
if you add the correct 2.4 you will get wrong results because Microsoft expect your display is sRGB this is a lost cause don't add it.

Can you answer this question?

https://forum.doom9.org/showthread.php?t=186081

[huhn]

no clue i never created an apng in my life.