YUV - Rec.601 / Rec.709?

[zerowalker]

Okay i wonder about these to "versions" YUV.

Cause as i understand it, RGB doesn´t have a certain setting to tell if it´s either one of them. As RGB is just, perfect so to speak.

But YUV can be either one right?

Now the problem i have is that if i save an RGB file as YV12 for example with, Lagarith. It will automaticly choos Rec.601, while it seems to be that Rec.709 is pretty much always used. Atleast in captured content (gameplay for whatever your PC shows).

The solution i currently use is to change ColorMatrix afterwards from Rec.601 -> Rec.709.

But is that really lossless? Doesn´t it use som kind of rounding to get the other colors?

And well, it is pretty wasteful to have to change it on all the content.

I would like to be able to choose to save in either format in Lagarith, or well, any lossless codec.

Does anyone know of a way to solve this, thanks!

Here is a screenshot if it helps: http://screenshotcomparison.com/comparison/17137

[poisondeathray]

Cause as i understand it, RGB doesn´t have a certain setting to tell if it´s either one of them. As RGB is just, perfect so to speak.


No, there are different types of RGB color models as well eg. AdobeRGB, sRGB, ProPhotoRGB, etc... the way "YUV" maps to the RGB coordinates is different


But YUV can be either one right?

Now the problem i have is that if i save an RGB file as YV12 for example with, Lagarith. It will automaticly choos Rec.601, while it seems to be that Rec.709 is pretty much always used. Atleast in captured content (gameplay for whatever your PC shows).


601 vs 709 determine how YUV is converted to RGB (or vice versa) . There are other matrices as well (other methods of conversion or "mapping" between YUV and RGB)



The solution i currently use is to change ColorMatrix afterwards from Rec.601 -> Rec.709.

But is that really lossless? Doesn´t it use som kind of rounding to get the other colors?


Not lossless, each time you convert you lose quality


And well, it is pretty wasteful to have to change it on all the content.

I would like to be able to choose to save in either format in Lagarith, or well, any lossless codec.

Does anyone know of a way to solve this, thanks!


If you have an RGB source, use lagarith or any other codec in RGB mode . Do all operations in RGB. Only convert YUV at the very end if you have to

[zerowalker]

No, there are different types of RGB color models as well eg. AdobeRGB, sRGB, ProPhotoRGB, etc... the way "YUV" maps to the RGB coordinates is different

Doesn´t it record in the RGB mode that my PC displays?
So in a way, it´s "perfect", for what it´s doing (capturing what i see).


Use lagarith in RGB mode . Do all operations in RGB. Only convert YUV at the very end if you have to

The problem is that RGB modes uses extensive CPU power and alot of space. But mostly it´s the CPU power that ruins it.

Which is why i would like to know the best way to convert from the source (which is RGB) to YUY, or YV12 for the matter.

The colormatrix change it the only way i know of.

But as it isn´t lossless, it seems that i will lose information as it´s doing a conversion twice:

RGB -> Rec.601 -> Rec.709

Which is not ideal.

But why is all codecs converting to Rec.601?
Why isn´t there a way to change it?

[poisondeathray]

Doesn´t it record in the RGB mode that my PC displays?
So in a way, it´s "perfect", for what it´s doing (capturing what i see).



Yes. It's perfect for what you are doing (if you use RGB to record)

I was just saying be aware there are different types of RGB models as well



The problem is that RGB modes that extensive CPU power and alot of space. But mostly it´s the CPU power that ruins it.

Which is why i would like to know the best way to convert from the source (which is RGB) to YUY, or YV12 for the matter.

The colormatrix change it the only way i know of.

But as it isn´t lossless, it seems that i will lose information as it´s doing a conversion twice:

RGB -> Rec.601 -> Rec.709

Which is not ideal.

But why is all codecs converting to Rec.601?
Why isn´t there a way to change it?


Yes you will incur more quality loss .

Get a faster computer and more hard drives

Colormatrix only converts between YUV , not RGB. If you convert between RGB, YUV you use ConvertToXX (matrix =XX)

No, most codecs automatically use Rec.601 when doing YUV<=>RGB conversions . I don't know of any that allow you to control this through the codec settinsg

[zerowalker]

I was just saying be aware there are different types of RGB models as well

Ah, okay:)

t a faster computer and more hard drives

Colormatrix only converts between YUV , not RGB. If you convert between RGB, YUV you use ConvertToXX (matrix =XX)

Well that is a way sure, problem is that i do have quite a fast PC (Quad Core 4ghz). And the space isn´t the problem really.

But it is possible to make the codec convert to Rec.709 right?
I mean, if it´s told to do it.

Cause it´s either asking someone to add it, or make the recording software convert to YUY internally with Rec.709 before handing it over to the codec.

But thanks, now i know that i wasn´t out in the woods about this.

[poisondeathray]

But it is possible to make the codec convert to Rec.709 right?
I mean, if it´s told to do it.


Convert to YUV using 709 instead of 601, yes it should be possible


Cause it´s either asking someone to add it, or make the recording software convert to YUY internally with Rec.709 before handing it over to the codec.


Yes

[Warperus]

But why is all codecs converting to Rec.601?
Actually, not all. It depends on recording software, codec settings/possibilities and yuv<->rgb filters and their preferennces in your system.

[zerowalker]

Well, it seems that most codecs choose Rec.601, atleast the good ones.
The recording softwares i have tried are MSI Afterburner and dxtory, and atleast MSI Afterburner just passes the RGB to the codec, i think dxtory does the same.

And when the codec get´s it, it will use Rec.601 in atleast UT Video Codec and Lagarith.

[xooyoozoo]

Open source or free-use tools generally assume 601 and do their work into and out of 601 unless told otherwise. 'Professional' applications seem to mostly go the 'official' route, which is assume 601 at SD resolutions or less and 709 at HD (720p+) resolutions. It's kind of a mess and becomes annoying if you use raw files and have to switch between multiple applications.

[zerowalker]

Seems to be the case indeed.

But i don´t understand, what is the difference between them?
Is Rec.709 better, does it allow more colors?
Or is it just like (Warm, Cold color mode) or something like that?

[Warperus]

First of all, they have different base colors.
In CIE 1931 chromaticity coordinates:

Red Green Blue
X Y X Y X Y
BT.601 PAL 0.640 0.330 0.290 0.600 0.150 0.060
BT.601 NTSC 0.630 0.340 0.310 0.595 0.155 0.070
BT.709 0.640 0.330 0.300 0.600 0.150 0.060

In practice you'll not notice this difference as more than half of software ignores this sort of flagging even if it exists in file.

Second, they have different matrix coefficients for Y'CbCr<->R'G'B' conversions. That's what generally produces difference in picture you see.

BT.709 doesn't have more colors, it has just a bit different different math inside. When it was created they supposed it to be more close to modern CRT monitors. Later sRGB standard was based on BT.709 matrix coefficients and base colors (gamma is a bit different, but you should be superhuman to actually notice the difference here).

Unfortunately, VFW and Directshow don't have color tags so as developer you are doomed to always guess what you are processing. Microsoft recommends BT.601 for SD resolution and BT.709 for higher resolutions for video.
MPEG-2 allowed to use BT.709 and something like BT.601 (BT.470-2 system B, G)
MPEG-4 ASP used BT.601 all the way
MPEG-4 AVC allowes to use both with BT.709 as default (even for SD content).

Why many cature programs use 601? I think because of historical reasons.
When they were created it was a time of xvid/divx (that is, mpeg-4 asp). So developers decided to be ready for xvid encoding and applied corresponding RGB<->YUV conversion, the one suitable for xvid encoding. For example, I've seen it in bandicam trial with internal xvid, mjpeg and even external x264.
I don't think it's good actually, as now we live in sRGB/bt.709 world, but changing defaults might be a pain as well. I remember when fraps changed something like this and some old videos (recorded in previous versions) became corrupted in colors.

As for concerns of color loss... You have 24-bit rgb as input (8 bit for each color), but final video will be in about ~21 bit yuv (16-235 levels for luma , 16-240 for chroma) and in fact valid colors are even less than that. So you'll lose color information anyway. I never seen it as big issue, but I prefer to record computer graphics in RGB mode and convert it into yuv colorspace in rendering phase.

[zerowalker]

Ah that´s explains a lot.

But it´s sad that VFW doesn´t allow color tags. But isn´t it possible to make some kind of check to make sure it´s converted corretly at the first frame (if it has colors)?
Cause RGB and the correct YUV Matrix, looks pretty much identical (if you skip the loss of color thanks to YV12/YV16).
But if you use the wrong matrix, blue becomes purple and stuff like that.

I think it should be very easy to make some kind of check in the beginning to make it confirm what matrix it should be using.

Though that´s alot harder than purely choosing matrix yourself, and as i am no developer, i wouldn´t be able to do this.

[Wilbert]

I think it should be very easy to make some kind of check in the beginning to make it confirm what matrix it should be using.
It's difficult to see the difference with your own eyes (let alone with some algorithm). Have a look at the screenshots here: http://avisynth.org/mediawiki/Colorimetry

[zerowalker]

In that picture, yes. And if you look at them side by side, yes.

But if you go back and forth, it´s pretty obvious. Maybe not that´s it´s wrong, but that it´s clearly different.

Look at the comparison i posted in the first post.

[drmpeg]

Here's what it looks like with 75% color bars.

http://www.w6rz.net/barsmatrix.jpg

[zerowalker]

As far as i can see, 709 to 601 looks closer to 601 than 601 to 709 those to 709.

[ChiDragon]

I disagree. Numbering the images at the top as 1 & 2 and the bottom as 3 & 4, to my visual system 4 is the most noticeably wrong. The green bar is neon (so are magenta and red in 3, but they don't draw my eye as much). Plus magenta is purple.

[zerowalker]

What do you mean, do you compare them to what they are supposed to look like?

4 is supposed to look close to 1
3 is supposed to look close to 2

On my screen, 1 and 4 look pretty much alike.
But 3 and 2 doesn´t look as close, the red for example on 3 is much brighter compared to 2, which concludes 3 fails when trying to reach 701 colors from 601 source.

Man, i must be blind, while i wrote this i notice, 1 and 4 aren´t alike at all, only purple and the rest to the right is close, but green and the others are completely out of place;S
Don´t know how i could have missed that.

But in other words, the conversion from one YUV matrix to another is far from transparent, maybe it´s hard to notice in dark and real life movies.
But cartoon and stuff with clear colors will look out of place when you compare them.

[TheSkiller]

Yeah it's quite a problem these days especially on the internet.
On YouTube for example many videos display wrong because for some unknown reason YouTube (or Flash-Player I don't know) always sticks to assuming Rec.709 to do the RGB conversion for playback. :rolleyes:
And obviously this gives wrong colors for all videos which use Rec.601, like virtually every content that was uploaded in lower definition than 720p and therefore usually using Rec.601.

If you upload a 75% color bar test pattern to YouTube using Rec.601 you get exactly what the pictures 1 and 3 show. 1 is how it is supposed to look like and 3 is how it looks on YouTube.
I sometimes find it rather easy to spot. If something is supposed to be deep red it gets this ugly orange tinge from the wrong coefficients.

[zerowalker]

Wait, does Youtube make a conversion even if the content is YUV?

[drmpeg]

It's a little difficult to tell if the incorrect matrix is being used with cartoons since the colors are exaggerated anyway. First image is correct.

http://www.w6rz.net/advyuv709.png

http://www.w6rz.net/advyuv601.png

Ron

[zerowalker]

True, but still unwanted.

And well to the pictures, it´s hard to see, but if i look at the green carpet thing in the back, i notice that´s it´s,
thinner in terms of strong coloring in the one below compared to the one above.

[poisondeathray]

Wait, does Youtube make a conversion even if the content is YUV?

Yes, every display device works in RGB. You don't look at YUV as YUV, always the RGB representation of it. There is always conversion somewhere to RGB

It's easier to see 709/601 differences on live action content, especially skin tones

[zerowalker]

I understand that, but isn´t the matrix changed when it´s converted to YUV, not when it´s showed as RGB?

If i save an RGB as YV12 Rec.601, won´t it be displayed as RGB with Rec.601 matrix then?
I know that certain files has flags (MPEG 2 and stuff), but if you don´t have a flag, won´t it just show the YV12 as it looks, but in RGB format, meaning not matrix conversion will be done on playback?

[poisondeathray]

I understand that, but isn´t the matrix changed when it´s converted to YUV, not when it´s showed as RGB?

If i save an RGB as YV12 Rec.601, won´t it be displayed as RGB with Rec.601 matrix then?
I know that certain files has flags (MPEG 2 and stuff), but if you don´t have a flag, won´t it just show the YV12 as it looks, but in RGB format, meaning not matrix conversion will be done on playback?


No , you can use a different matrix when converting between RGB<=>YUV

Just because you convert RGB to YV12 using one, doesn't necessarily mean whatever software or hardware device will use the same matrix to convert back to RGB for display - this one of the reason why there maybe color display inconsistencies

Flags are just "recommendations". Hardware or software players might ignore the flag

An RGB format is already RGB, so no matrix will be applied when viewing it (there is no YUV to RGB conversion)

[zerowalker]

But if i convert an RGB to YV12 with Rec.601 and one with Rec.709, they will look different right?

I don´t get how it´s working, i mean.

If a conversion from RGB to YV12 is used with 601, is it supposed to be done with 601 the other way back to get the original color?

Cause when i am using avisynth to play around with the matrixes, it will look different if i play up a file converted with different matrixes, even though the playback itself shouldn´t be able to know what matrix was used to convert it in the first place, right?

[Warperus]

If a conversion from RGB to YV12 is used with 601, is it supposed to be done with 601 the other way back to get the original color?
Exactly! Unfortunately decoder should guess or know about this from external info.

[zerowalker]

Well that is pretty ackward. It´s just well, bad, not an optimal way to get convert and decode colors at all, cause in 90% of the cases there is no flag or the flags are ignored;S

But i wonder.

Currently, i record in YV12, which goes with 601, and then i use colormatrix to change it to 709 (with some loss of course). Then i encode it with x264 and upload it to youtube.
Would i get the same results just uploading without any colormatrix, as youtube will decode it with 709 and re-encode it?
Meaning, i will get the same results, as long as there matrix conversion is doing what it´s supposed to?.

Though i will test this, i am pretty sure i tested it before and it produced the wrong colors.

EDIT:

Okay i uploaded a clip which was 1 sec 601 (which came from it being converted to YV12 in the first place) and 1 sec 709 (using colormatrix 601->709).
And in youtube it changed colors the same way as it looked in avisynth.

Have i tested it wrong, or is it showing the colors as it´s supposed to?

[wonkey_monkey]

as youtube will decode it with 709 and re-encode it?

It doesn't have to be decoded to RGB for YouTube to re-encode it (similar to VirtualDub in "Fast recompress" mode), since x264 is yv12 and so is (I believe) YouTube so the matrix doesn't come in to it. It only happens at the point of display.

David

[Asmodian]

RGB is just RGB, no Rec.601/709.

I thought YouTube assumes all YUV is Rec.601? (http://forum.doom9.org/showthread.php?p=1522080) This is part of the YouTube web player not really their encoder (unless you upload RGB, that is converted to YUV with Rec.601).

If you want YouTube to display correct colors don't you just use Rec.601 when converting from RGB and do colormatrix 709->601 on any YUV Rec.709 content?

What do you mean, do you compare them to what they are supposed to look like?

4 is supposed to look close to 1
3 is supposed to look close to 2


No, 1 is supposed to look like 2, and 3 and 4 are supposed to look different (wrong). You shouldn't notice if the YUV is Rec.601 or Rec.709 once you convert to RGB for display, they should look exactly the same assuming you used the correct matrix when doing the conversion to RGB. 3 and 4 show what it looks like if you use the wrong matrix.

[wonkey_monkey]

Some screenshots from YouTube (top and bottom) and the original RGB:

http://img594.imageshack.us/img594/1591/matrixm.png

[TheSkiller]

If you want YouTube to display correct colors don't you just use Rec.601 when converting from RGB and do colormatrix 709->601 on any YUV Rec.709 content?
Nope, I have done elaborate tests on this and I'm absolutely certain everything you upload to YouTube must be prepared to be converted back to RGB using Rec.709 coefficients.
That means anything that is RGB should be converted to YUV using Rec.709 and anything that is already YUV but supposed to be displayed using Rec.601 needs to be ColorMatrix'ed().

davidhorman just demonstrated this. :)


Edit: By the way, there is one exception, if you watch any video in 240p mode it's the other way around and Rec.601 is always used. What a mess.

[zerowalker]

It seems that i clearly mistook how it all works;S

Butatleast according to davidhorman, i got the youtube 709 part right.

That you need to use 701 to get it right.

But i wonder, if the video is 601, is there a way to get it right in Youtube, or is it impossible to show 601 correctly with 709 as playback?

TheSkiller: Really? 240p being 601 is just weird. But well, that mode is never really used so it doesn´t really matter.

[Warperus]

RGB is just RGB, no Rec.601/709.Unfortunately, there are quite a few RGB colorspaces around, but we face sRGB most of the time.

http://en.wikipedia.org/wiki/RGB_color_space

zerowalker
I believe Youtube follows general practice: 576p and less is in BT.601, 720p and more is in BT.709.

[wonkey_monkey]

I believe Youtube follows general practice: 576p and less is in BT.601, 720p and more is in BT.709.

Untrue, I think; the clips I created in order to make my png above were only 640x480, but displayed with 709 by YouTube.

So far the only time I've seen YouTube use 601 is when a video is viewed at 240p, as TheSkiller pointed out.

[Asmodian]

Ah good to know, I am glad YouTube uses BT.709, most everything going forward should match. I was confused why they would use the non-computer standard.

Thanks davidhorman those screenshots are quite convincing. :)