question about YUV -> RGB

[Spyn]

TV Scale uses luminance 16-235 cause a tv is unable to go higher than 235 and lower than 16 or is there another "cause" ?

i want to be sure that TV Scale gives a better quality on a TV screen cause i encode all my movies for watching on a TV.

[KaiserS]

It's gonna get clipped either way.

[Spyn]

what ?

[KaiserS]

Originally posted by Spyn
what ?

For watching things on your TV its better to put it into TV scale and even if you don't the output to your TV is going to clamp the luma to TV scale anyway. So there's pretty much no point in using PC scale if you are just gonna watch it on your TV. Of course when you use TV scale you aren't gonna get the blackest of black or the whitest white, but that's just the limitation you gotta live with when watching stuff on TV.

[Spyn]

Originally posted by KaiserS
For watching things on your TV its better to put it into TV scale and even if you don't the output to your TV is going to clamp the luma to TV scale anyway. So there's pretty much no point in using PC scale if you are just gonna watch it on your TV. Of course when you use TV scale you aren't gonna get the blackest of black or the whitest white, but that's just the limitation you gotta live with when watching on TV.

are you sure about this ?

absolutely no TVs are able to display a range higher than 16-235 ?

[KaiserS]

Originally posted by Spyn
are you sure about this ?

absolutely no TVs are able to display a range higher than 16-235 ?

I'm pretty sure not cause NTSC uses a luma scale of 16-235. I don't remember what PAL uses but I'm pretty sure its the same.

[Wilbert]

This setting doesn't do anything when using Mpeg2dec3/DGDecode.

[neuron2]

NTSC is an analog interface. It makes no sense to speak of digital pixel values on the analog interface. The fact of the matter is that YUV is defined to be the clipped ranges. Sending something outside them is an undefined operation. It will likely be clipped somewhere, and if not it may cause artifacts.

Crank up your contrast control, Spyn, if you want more range.

[Spyn]

Originally posted by neuron2
NTSC is an analog interface. It makes no sense to speak of digital pixel values on the analog interface. The fact of the matter is that YUV is defined to be the clipped ranges. Sending something outside them is an undefined operation. It will likely be clipped somewhere, and if not it may cause artifacts.

Crank up your contrast control, Spyn, if you want more range.

so i must use PC Scale to don't have any artifacts ?

I don't understand all that you said cause of poor english and knowledge, sorry.

[neuron2]

Sending 0-255 to a device designed to accept YUV ranges *may* cause artifacts, depending on the device.

I can't say it any clearer than that and English is my only language.

[Spyn]

Originally posted by neuron2
Sending 0-255 to a device designed to accept YUV ranges *may* cause artifacts, depending on the device.

I can't say it any clearer than that and English is my only language.

so YUV range is 16-235 and RGB is 0-255.

I got a pioneer DV-470 divx player connected to my tv with a SCART connector using RGB mode so i think i can use PC-Scale (0-255) without any artifacts ?

Do you know which range is used by Y/C (S-video) ?

thank's for your answers :)

[Wilbert]

Are you using AviSynth? If so read my response again ...

[Spyn]

Originally posted by Wilbert
Are you using AviSynth? If so read my response again ...

why dgecode.dll force 0-255 ?

[Wilbert]

No, it doesn't touch the lumarange (ie YUV [16,235]).

[neuron2]

Originally posted by Spyn
so YUV range is 16-235 and RGB is 0-255. Almost. Y range is 16-235. UV range is 16-240.

I got a pioneer DV-470 divx player connected to my tv with a SCART connector using RGB mode so i think i can use PC-Scale (0-255) without any artifacts ? It depends upon what the DV-470 decoder does. Most likely, it will clip to legal ranges.

Do you know which range is used by Y/C (S-video) ? S-Video is an analog interface. Digital pixel value ranges have no meaning there.

[Spyn]

Originally posted by Wilbert
No, it doesn't touch the lumarange (ie YUV [16,235]).

i think you wrong,

here is a screenshot of dgindex using pc scale :

http://naxxalite.free.fr/dgindex_pc.jpg

dgindex using tv scale :

http://naxxalite.free.fr/dgindex_tv.jpg

after loading each d2v file (one using pc scale, other using tv scale) in a .avs and open those avs using vdubmod, here is the result :

.d2v created using pc scale :

http://naxxalite.free.fr/vdub_pc.jpg

.d2v created using tv scale :

http://naxxalite.free.fr/vdub_tv.jpg

both vdub screenshots shown that in all case pc scales is use (0-255)

[neuron2]

VirtualDub is converting back to PC scale as part of its YV12 decompressing. It always wants to display in the display pane as RGB.

Actually, DGDecode only uses the scale setting in two cases: when you use the extra convert to RGB filters in the DLL, and when a 3rd-party app, such as Gordian Knot or VFAPI, requests an RGB frame. Normally, the served D2V passes out 16-235/240.

[Cyberia]

Originally posted by neuron2
VirtualDub is converting back to PC scale as part of its YV12 decompressing. It always wants to display in the display pane as RGB.

Actually, DGDecode only uses the scale setting in two cases: when you use the extra convert to RGB filters in the DLL, and when a 3rd-party app, such as Gordian Knot or VFAPI, requests an RGB frame. Normally, the served D2V passes out 16-235/240.

Ahhh, my brain hurts. You lost me with the very last sentence. Here's what I thought I had learned from you and Wilbert:

* Scale setting is not used AT ALL unless DGDecode is outputing an RGB frame. Which means DGDecode normally outputs unclamped 0-255 full range. (You indicate DGDecode normally outputs clamped output?)

* If an RBG frame is output then the scale setting is applied as follows: PC -> 0-255 (unclamped) or, TV -> 16-235/240 (clamped)

This could make a good FAQ clarification.

[Spyn]

using TV Scale or PC Scale will never change anything if i compress in YV12 with vdubmod if i understand, the range will be 0-255.

thank's all :)

[KaiserS]

Originally posted by Spyn
using TV Scale or PC Scale will never change anything if i compress in YV12 colorspace with vdubmod if i understand, the range will be 0-255.

No, YUV has a luma range of 16-235, YV12 is a YUV colorspace. So if the luma range of the video hasn't been put into TV scale before its feed to the codec the codec itself will clip the luma range.

[Wilbert]

Scale setting is not used AT ALL unless DGDecode is outputing an RGB frame.
Yup.

Which means DGDecode normally outputs unclamped 0-255 full range.
Nope, it outputs [16,235] YUV (in all cases).

If an RBG frame is output then the scale setting is applied as follows: PC -> 0-255 (unclamped) or, TV -> 16-235/240 (clamped)
Yup, at least in the following way. If you use DGDecode's color conversion routines (YUVtoRGB):

TV-scale: YUV [16,235] -> RGB [16,235]

PC-scale: YUV [16,235] -> RGB [0,255].

Like i said in

http://forum.doom9.org/showthread.php?s=&threadid=87811

I also said it doesn't seem to work with vfapi 1.05/TMPGEnc (btw, i guess i forgot to use DGVfapi.vfp, have to check that).

[neuron2]

IIRC, VFAPI forces PC scale, while the 3rd-party access function follows the setting.

[Spyn]

if dgdecode use reduced 16-235 in all cases when output YUV frames, why when scripting the .d2v in a .avs file and open this avs with vdubmod it look to be 0-255 ?

here is 16-235 :

http://naxxalite.free.fr/dgindex_tv.jpg

but vdub show 0-255 in all cases :

http://naxxalite.free.fr/vdub_tv.jpg

if Dgdecode output 16-235 for YUV, there is inevitably a conversion from 16-235 to 0-255 somewhere.

vdubmod don't change the colorspace by choosing fast recompress and my encoded movies are 0-255 too so i think there is no colorconversion in all the process.

in conclusion, i think dgdecode output 0-255 for YUV frames.

[neuron2]

I already told you that you can't use VDub's display. How do you know that your encoded movie is PC scale?

[Wilbert]

in conclusion, i think dgdecode output 0-255 for YUV frames.
Nope, sorry.


if Dgdecode output 16-235 for YUV, there is inevitably a conversion from 16-235 to 0-255 somewhere.

vdubmod don't change the colorspace by choosing fast recompress and my encoded movies are 0-255 too so i think there is no colorconversion in all the process.
VDub converts it to RGB [0,255] for displaying only (as neuron2 is trying to say), but it passes the YUV [16,235] to the codec.

[Spyn]

Originally posted by Wilbert
Nope, sorry.


VDub converts it to RGB [0,255] for displaying only (as neuron2 is trying to say), but it passes the YUV [16,235] to the codec.

here is a screenshot of the encoded movie from media player classic :

http://naxxalite.free.fr/mpc.jpg

here is a screenshot of the same encoded movie from vdubmod :

http://naxxalite.free.fr/vdub_nemo_tv.jpg

and here is a screenshot from dgindex using tv scale (16-235) before encoding :

http://naxxalite.free.fr/dgindex_nemo_tv.jpg

the movie has been encode with a .d2v file created using tv scale and with vdub using fast recompress (no colorspace change)

media player classic show that the movie is 0-255 and i don't think media player classic do any color conversion ?

[KaiserS]

Originally posted by Spyn
media player classic show that the movie is 0-255 and i don't think media player classic do any color conversion ?

Open your encoded movie with an Avisynth script with ColorYUV(analyze=true) in it and make a screenshot from that in vdub. Rather then trying to estimate with your eye, this will tell you exactly what the luma scale is.

[Wilbert]

media player classic show that the movie is 0-255 and i don't think media player classic do any color conversion ?
Your monitor displays RGB. So, there's always a color conversion to RGB. I guess MPC uses its own color conversion routines, just like VirtualDubMod does when opening a vob.

[Spyn]

Originally posted by KaiserS
Open your encoded movie with an Avisynth script with ColorYUV(analyze=true) in it and make a screenshot from that in vdub. Rather then trying to estimate with your eye, this will tell you exactly what the luma scale is.

i find frames with a luma minimum of 0 and others with a lum maximum of 254

all players play the movie with 0-255 range expect bsplayer who use 16-235

who lie...

[KaiserS]

Originally posted by Spyn
i find frames with a luma minimum of 0 and others with a lum maximum of 254

Can you post a screenshot? Secondly, what codec are you encoding to? If it uses a YUV colorspace it will have to have a luma range of 16-235.

[neuron2]

Just put coloryuv in the avs after DGDecode:

mpeg2source("file.d2v")
coloryuv(analyze=true)

Strangely, it does show minimum 0/maximum 255!

I will investigate.

Spyn, you can stop posting all the big screenshots now. :)

[Spyn]

Originally posted by KaiserS
Can you post a screenshot? Secondly, what codec are you encoding to? If it uses a YUV colorspace it will have to have a luma range of 16-235.

no i can't neuron2 say stop and he got same result ;)

i use xvid 1.0.3

[neuron2]

@KaiserS

mpeg2source("file.d2v")
coloryuv(analyze=true)

This shows max 255, min 0. There's nothing else involved.

[KaiserS]

Well I was talking about his encoded file, which he said was using PC scale as well, not the d2v source itself. The xvid encode shouldn't have PC scale as IIRC it clips the luma range to TV scale.

[Spyn]

Originally posted by KaiserS
Well I was talking about his encoded file, which he said was using PC scale as well, not the d2v source itself. The xvid encode shouldn't have PC scale as IIRC it clips the luma range to TV scale.

sorry neuron2 ;)

http://naxxalite.free.fr/xvid.jpg

this is an xvid movie, avs :

AviSource("H:\le_jour_d_apres.avi")
ColorYUV(analyze=true)

what mean loose minimum and loose maximum ?

[Wilbert]

Loose min means that 255/256 of all luma values lie above the loose minimum (loose max similar).

Strange, like KaiserS, XviD should clamp it to [16,235]. I guess it's time to do some tests again.

[Wilbert]

Strange, like KaiserS, XviD should clamp it to [16,235]. I guess it's time to do some tests again.
Ok, did some tests with AviSynth (with luma=0 and luma=8) and XviD (Koepi's 1.1):

1) XviD does NOT clamp when requesting YUV (it just returns YUV [0,255]).

2) It does 'clamp to YUV [16,235] prior conversion to RGB' when requesting RGB from the codec (using AviSource("Y8.avi",pixel_type="RGB24")) for example.

[Cyberia]

I have updated Q07 of the FAQ to reflect the clarifications in this thread. Still waiting on final reports from neuron2 and wilbert on the strange behavior described towards the end of the thread.


Q07: What does the "YUV -> RGB" option do?
A: First, understand that this option is ONLY used in two cases: when you use DGDecode's internal RGB conversion filters, or when a 3rd-party application, such as Gordian Knot or VFAPI, requests an RGB frame.

In short, use PC Scale if you are going to mainly watch the final video on a PC, and TV Scale if you mainly are going to watch it on a TV.

PC-scale: YUV [16,235] -> RGB [0, 255]
TV-scale: YUV [16,235] -> RGB [16, 235/240]

[Wilbert]

TV-scale: YUV [16,235] -> RGB [16, 235/240]

TV-scale: YUV [16,235/240] -> RGB [16, 235]
(240 refers to the chroma of course)

In short, use PC Scale if you are going to mainly watch the final video on a PC, and TV Scale if you mainly are going to watch it on a TV.
I know people say this, but I disagree. Imo, it has nothing to do when you will be watching it on tv or pc. Whether you encode to mpeg4 or mpeg2 i always would use PC-scale.

Ok, when would you use TV-scale? Well never, but you can use it in the following theoretic cases:

1) Open the d2v file in TMPGEnc and check the "Output YUV data as Basic YCbCr not CCIR601" option (which is UNchecked by default). In this case the RGB->YUV conversion will be done preserving the luma range.

2) I guess CCE will do this similarly when feeding RGB and checking "luminance level 0 to 255". Since you are feeding RGB [16,235], it will map to YUV [16,235]. I guess, i don't have CCE, so i never tried it.

I can't think of any other case.

[Cyberia]

Originally posted by Wilbert
TV-scale: YUV [16,235/240] -> RGB [16, 235]
(240 refers to the chroma of course)

PC Scale: YUV [16,235(Y)/240(UV)] -> RGB [0, 255]
TV Scale: YUV [16,235(Y)/240(UV)] -> RGB [16, 235]

Correct?

[Wilbert]

Yup.

[Cyberia]

Q07: What does the "YUV -> RGB" option do?
A: First, understand that this option is ONLY used in two cases: when you use DGDecode's internal RGB conversion filters, or when a 3rd-party application requests an RGB frame.

PC Scale: YUV [16,235(Y)/240(UV)] -> RGB [0, 255]
TV Scale: YUV [16,235(Y)/240(UV)] -> RGB [16, 235]

Only use TV Scale if you are using TMPGEnc with the "Output YUV Data As Basic YCbCr Not CCIR601" option, or CCE with the "Luminance Level 0 To 255" option.

Otherwise, always use PC Scale.

[Wilbert]

Q07: What does the "YUV -> RGB" option do?
A: First, understand that this option is ONLY used in two cases: when you use DGDecode's internal RGB conversion filters, or when a 3rd-party application requests an RGB frame.

PC Scale: YUV [16,235(Y)/240(UV)] -> RGB [0, 255]
TV Scale: YUV [16,235(Y)/240(UV)] -> RGB [16, 235]

Only use TV Scale if you are using TMPGEnc with the "Output YUV Data As Basic YCbCr Not CCIR601" option checked (it's UNchecked by default), or CCE with the "Luminance Level 0 To 255" option provided you are feeding it RGB.

Otherwise, always use PC Scale.

:)

[Cyberia]

done. thanks. :cool:

[Spyn]

Do you now known why a xvid / divx is YUV 0-255 ?

[Wilbert]

No, that's YUV [16,235].

[Spyn]

Originally posted by Wilbert
No, that's YUV [16,235].

http://naxxalite.free.fr/xvid.jpg

[Wilbert]

For other people reading this. Your screenshot is from a script where an XviD is loaded (see second page).

I guess I should choose my words more carefully. Like i wrote a few posts back, the luma range of a XviD clip is *clamped* to [16,235] when requesting RGB from the codec (upon decoding and/or playback). I also indicated briefly how i tested this (please ask if i need to elaborate on that). This means when encoding to XviD you should make sure that you use a luma range of YUV [16,235]. If you feed it with YUV [0,255], the clip will be "messed up" during decoding/playback.

Conclusion, although your XviD has a luma range of [0,255], which is possible since it is not clamped during the encoding (see my comments on the second page), your clip will be "messed up" during playback. So, in this sense a XviD/DivX should have a luma range of [16,235].

Is this better, or do you still disagree?

[Spyn]

i'm still disagree :)

when decoding using RGB the luma range is still 0-255, when decoding using YV12 luma range is clamp to 16-235.

i just do the test using the colorspace option in the Xvid decoder configuration :

screenshots from media player classic :

colorspace YV12 :
http://naxxalite.free.fr/xvid_yv12.bmp

colorspace RGB24 :
http://naxxalite.free.fr/xvid_rgb.bmp

[Wilbert]

when decoding using RGB the luma range is still 0-255, when decoding using YV12 luma range is clamp to 16-235.
The following happens when requesting RGB:

1) The luma range is clamped: YUV [0,255] -> YUV [16,235].
2) YUV [16,235] -> RGB [0,255]

proof)
1) Make a clip with Y=8 using AviSynth:

BlankClip(pixel_type="YV12", width=720, height=576, color_yuv=$088080)

Encode to XviD.

2a) When opening the clip in AviSynth you will get:

AviSource("F:\Temp\Y8_xvid.avi")
ColorYUV(analyze=true)

result: Y=8, U=V=128. => indeed no clamping

2b) When opening the clip in AviSynth requesting RGB from the codec you will get:

AviSource("F:\Temp\Y8_xvid.avi", pixel_type="RGB24")
RGBAdjust(analyze=true)

result: R=G=B=0. => this is only possible if Y=8,U=V=128 is clamped to Y=16,U=V=128 before converting to R=G=B=0.

Do you agree now?

[Spyn]

I better understand but i was not wrong ;)

Xvid encode using YUV 0-255

when requesting YUV (YV12) from the xvid decoder luma is clamp to [16-235]

when requesting RGB from the xvid decoder, the conversions are : YUV [0-255] -> YUV [16-235] -> RGB [0-255]

right ?

but why the xvid encoder don't clamp YUV to [16-235] during the encode process to simplify things ?

[Spyn]

up, wilbert ?

i think xvid use 0-255 for encoding cause this increase compressibility.

[L'il Jerry]

Originally posted by Spyn
up, wilbert ?

i think xvid use 0-255 for encoding cause this increase compressibility.

How would encoding with a bigger luma range make something more compressible? I don't see the logic.

[Spyn]

Originally posted by L'il Jerry
How would encoding with a bigger luma range make something more compressible? I don't see the logic.

the darker a film is, the more it is compressible.

black [0] is more compressible than black [16]

[Wilbert]

the darker a film is, the more it is compressible.
That's not always true. A red clip (or any other single color) is more compressible than a greyscale movie with different grey shades.

black [0] is more compressible than black [16]
If your luma range is YUV-[0,255] it doesn't mean it will be darker than YUV-[16,235] *on your display*. It all depends how you convert it to RGB.

[Spyn]

Originally posted by Wilbert

If your luma range is YUV-[0,255] it doesn't mean it will be darker than YUV-[16,235] *on your display*. It all depends how you convert it to RGB. [/B]

there is no RGB conversion during the encode, i was not speaking about the display but about the encode processing.

[Wilbert]

Ok, my bad.

My point still stands though. If you take a clip and scale the luma range to:

clip_1) YUV [0,255]

clip_2) YUV [16,235]

First is doesn't mean that clip_1 is darker than clip_2 (in the sense that the average luma of the pixels in clip_1 is smaller than in clip_2). Second the luma range of a YUV [0,255] clip is larger than of YUV [16,235], meaning less compressible (in general).

So, I think that using [0,255] decreases compressibility, because the luma range is wider.

black [0] is more compressible than black [16]
For clarity. A clip with (all pixels) Y=0 is just as compressible as a clip with (all pixels) Y=16.

[len0x]

Originally posted by Wilbert
For clarity. A clip with (all pixels) Y=0 is just as compressible as a clip with (all pixels) Y=16.

Indeed, its color range that matters.

[Spyn]

Originally posted by Wilbert
Ok, my bad.

My point still stands though. If you take a clip and scale the luma range to:

clip_1) YUV [0,255]

clip_2) YUV [16,235]

First is doesn't mean that clip_1 is darker than clip_2 (in the sense that the average luma of the pixels in clip_1 is smaller than in clip_2). Second the luma range of a YUV [0,255] clip is larger than of YUV [16,235], meaning less compressible (in general).

So, I think that using [0,255] decreases compressibility, because the luma range is wider.


For clarity. A clip with (all pixels) Y=0 is just as compressible as a clip with (all pixels) Y=16.

a clip with luma range of [0-255] clamp to [16-235] will change the luma of all pixels between 0 and 15 to 16, this change will decrease compressibility cause black pixels are now grey.

A dvd is 0-255 and that's why Xvid does not clamp.

[len0x]

Originally posted by Spyn
this change will decrease compressibility cause black pixels are now grey.


LOL. Tell us then - how do you *think* encoder needs more bits to encode grey than black?

[Spyn]

Originally posted by len0x
LOL. Tell us then - how do you *think* encoder needs more bits to encode grey than black?

all dark movie are very compressible ? panic room etc... why ?

[len0x]

Not because they are dark, but because they have lower color range most of the time (and that happens to be dark range, coz it it was white gamut you'll be blind instead :) ). Consider this - you have a block 16x16 that is encoded as video unit. If it had just one color i.e. black or grey (it doesn't matter) it would be the most compressible. If you have 0-255 range chances are there will be some < 16 values that are invisible to the eye, but visible to codec which has to encode it and keep all those values in. So if you clamp 0 -> 16 then it would have been much easier for codec to work with less colors as it gives it less difference to surrounding pixels/frames.

[Spyn]

if the range 0-16 is invisible for human eye, why i can see the difference on these screenshots :

colorspace YV12 (16-135) :
http://naxxalite.free.fr/xvid_yv12.bmp

colorspace RGB24 (0-255) :
http://naxxalite.free.fr/xvid_rgb.bmp

and why Xvid don't clamp to 16-235 before encoding if this is much easier for the codec ?

edit : i don't want to annoyed you, just understand.

[len0x]

How is that relevant??

My point is: smaller color range result in better compresibility. No more, no less. (it doesn't matter if you can see luma below 16 or not)


and why Xvid don't clamp to 16-235 before encoding if this is much easier for the codec ?


It like asking why it doesn't clamp to 64-192... Codec is not supposed to be doing any reduction in unless its a neccessary conversion between colorspaces. I'm not an expert in this, but its sounds like a job for denoisers (that actually do mild reduction in many cases).