Nvideo color decoding question

[CruNcher]

@neuron2
i have a question as you have alot of knowledge about this :)

is Nvidias Purevideo wrongly showing the colors of ITU-R BT. 601/709 ?

or better wich of these is the correct representation of them ?


DgDecode 601 via Avisynth Alpha 3 useing MPC VMR9 windowed

http://cruncher.mufflastig.com/hdtv/dgdecode_601-vmr9-windowed.png

DgDecode 709 via Avisynth Alpha 3 useing MPC VMR9 windowed

http://cruncher.mufflastig.com/hdtv/dgdecode_709-vmr9-windowed.png

Elecard Mpeg2-Decoder DXVA 601 useing MPC VMR9 windowed

http://cruncher.mufflastig.com/hdtv/elecard_601-vmr9-windowed.png

Elecard Mpeg2-Decoder DXVA 709 useing MPC VMR9 windowed

http://cruncher.mufflastig.com/hdtv/elecard_709-vmr9-windowed.png

Nvidia PureVideo Decoder DXVA 601 useing MPC VMR9 windowed

http://cruncher.mufflastig.com/hdtv/nvidia_601-vmr9-windowed.png

Nvidia PureVideo Decoder DXVA 709 useing MPC VMR9 windowed

http://cruncher.mufflastig.com/hdtv/nvidia_709-vmr9-windowed.png

VLC Win32 Directx Overlay 601

http://cruncher.mufflastig.com/hdtv/vlc_601-directx-overlay.png

VLC Win32 Directx Overlay 709

http://cruncher.mufflastig.com/hdtv/vlc_709-directx-overlay.png

Nvidias PureVideo Engine seems to upsample the HDTV input to 1934x1088 so 14 pixels more horizontaly dunno what this is for maybe it's easier to calculate the shaders based on this size :P

the input script for the dgdecode results was very simple
Mpeg2source("colors.d2v")

thx for your help :)

[SeeMoreDigital]

Nvidias PureVideo Engine seems to upsample the HDTV input to 1934x1088 so 14 pixels more horizontaly dunno what this is for maybe it's easier to calculate the shaders based on this size :P It's applying an 1.7777:1 ratio to 1088 vertical pixels (instead of 1080 pixels) bringing the width to 1934 pixels.


EDIT: Are any of those colour bars supposed to be white by any chance?


Cheers

[neuron2]

Wilbert is the true expert on color stuff. Can you give him a ping about it?

[CruNcher]

@ Seemoredigital
ahh yeah that is logic correcting the AR for 16/9
and i suppose the first bar should be white and not grey but im not so sure :P

@neuron2
thx i gona pm him and direct him to this :)

[tritical]

@CruNcher
the input script for the dgdecode results was very simple
Mpeg2source("colors.d2v")
You should probably instead use:

Mpeg2source("colors.d2v",upconv=2)

in the avisynth script so that dgdecode will do the conversion to rgb using the correct coefficients. Otherwise, it will get converted to rgb somewhere along the line using the default coefficients of whatever does the conversion (most likely means bt.601 will be used so the bt.709 clip will be converted using the wrong coefficients). Another option is to use avisynth's rgb conversion and manually specify which set of coefficients to use via the "matrix" parameter.

[CruNcher]

tritical ehm sorry i should have been more correct their aren't in the same files they are seperate i created a colors.d2v for one (made all the caps) then deletet it and created a new one for the other ramp, but indeed Dgindex showed for both ITU-R BT.709 also for the 601 as colormetry (seems the info flag is wrong). But is the way that Nvidia shows it correct ? i mean if both are flaged 709 then at least the 709 should be correct by one of the Decoders ?

[jmac698]

Hi,
actually, a team effort of IanB, Wilbert, and myself brought the feature of accurate colorbars to Avisynth 2.56. I did most of the research and have copies of all the standards. Wilbert is also known for his color matrix filter and I look forward to his comments.

But first we need to start with some raw data:

This analysis attempts to decide which decoder is displaying the most correct
image. Amazingly, every one of them is completely different!

1 dgdecode_601-vmr9-windowed.png, 1920x1080
2 dgdecode_709-vmr9-windowed.png, 1920x1080
3 elecard_601-vmr9-windowed.png, 1934x1088
4 elecard_709-vmr9-windowed.png, 1934x1088
5 nvidia_601-vmr9-windowed.png, 1934x1088
6 nvidia_709-vmr9-windowed.png, 1934x1088
7 vlc_601-directx-overlay.png, 1920x1088
8 vlc_709-directx-overlay.png, 1920x1088

color rgb1 rgb2 rgb3 rgb4 rgb5 rgb6 rgb7 rgb8
grey 192,192,192 192,192,192 182,180,182 182,180,182 180,180,180 180,180,180 191,191,191 191,191,191
yel 193,192,0 190,204,7 185,170,11 182,179,17 184,171,9 180,180,15 192,191,0 190,203,7
cyn 0,192,191 16,212,189 3,164,184 17,180,182 1,165,182 15,180,180 0,191,190 16,211,188
grn 0,191,0 15,224,5 5,154,12 17,179,16 4,154,10 16,180,15 0,191,0 15,223,5
mag 191,0,193 176,0,186 193,41,188 182,15,183 192,41,186 180,16,181 191,0,192 176,0,186
red 192,0,1 175,0,2 196,31,15 182,15,18 195,31,14 181,15,16 191,0,1 175,0,2
blue 0,0,192 1,0,184 15,25,190 17,15,183 13,26,188 15,16,181 0,1,192 1,0,183
blk 0,0,0 0,0,0 17,15,17 17,15,17 16,16,16 16,16,16 0,0,0 0,0,0
+4 11,11,11 11,11,11 26,24,26 26,24,26 25,25,25 25,25,25 10,10,10 10,10,10
-4 0,0,0 0,0,0 8,6,8 8,6,8 7,7,7 7,7,7 0,0,0 0,0,0

[jmac698]

http://www.dvdupgrades.ch/fix_1088_to_1080.html
MPEG compression is always doing 16x16 pixel blocks.
As 1080 is not dividable by 16, the next higher vertical size
of 1088 is used for encoding.

So it's possible the display size will be set to 1088 in the .ts or mpeg2 stream, which in normal circumstances will result in an 8 pixel grey/black bar. The true size of HD is 1080, however if the software displays 1088 and that was set as display size, it is doing the right thing, it's the stream that's wrong. So you would have to use some tool to analyze the stream to find what value is in it, before you can decide that the player is wrong, make sense?

DgDecode 601 via Avisynth Alpha 3 useing MPC VMR9 windowed (1) and
VLC Win32 Directx Overlay 601 (7) are the most correct.
Where did you get those colorbars? How were they encoded? I have to be sure they are originally correct as well, the only way to tell is to use the pixelinfo filter to read direct YUV values, or there's a trick to export YUV into GBR, which looks weird but you can read off the YUV from a color dropper.

[jmac698]

As for colors, (1) and (7) are closest.
As for size, same - I can't say for sure. Since mpeg2 can only encode in 16x16 blocks, 1088 is the nearest value to the correct 1080. Therefore the stream has a "display value" that should say 1080. If it doesn't, in normal cases (with a correct decoder) you get a grey or black 8 pixel bar which is unnecessary.
So, vlc is correct if this display value is set to 1088, otherwise it's wrong. You would have to analyze your mpeg2 stream.
How was the stream made? Where did the colorbars come from? You could also check the real YUV values, with the pixelinfo filter. Then I could tell you how many bits and what rounding mode was used in the calculation. It turns out that yellow is just on the edge of two values and can be used to guess at the accuracy of the calculation.

Btw, 4 and 6 are right in a way, except they are a little dark. This is because there is some confusion over showing "whiter than white", ie where Y (luma)>240.
1 and 7 show white as rgb=255, while 4 and 6 show white as rgb=240.

I'm curious how many actual streams contain whiter than white.

[CruNcher]

the ramps are from W6RZ his testpattern page and can be found here http://www.w6rz.net/

[SeeMoreDigital]

What do you guys see with this test card: -

http://img216.imageshack.us/img216/4363/smdcolourbartestcard0jo.png


R G B
000:000:000 = Black
255:255:255 = White

255:000:000 = Red
000:255:000 = Green
000:000:255 = Blue
255:255:000 = Yellow
255:000:255 = Magenta
000:255:255 = Cyan


By-the-way, while testing the DVI and HDMI outputs levels of various standalone players, some player owners have reported not being able to see white above 239:239:239 and black below 016:016:016


Cheers

[drmpeg]

Just to chime in here. I'm the author of the 75% color bar patterns used by CruNcher in his decoder analysis. I guarantee that the YCbCr values in these patterns are correct. However, the bitstreams do not contain a Sequence_Display_Extension to indicate the YCbCr to RGB matrix coefficients.

The default behavior of an MPEG-2 decoder that does not encounter a Sequence_Display_Extension is to use REC 709 parameters.

If you're still interested, I can create 75% color bars patterns with the correct Sequence_Display_Extension for the REC 601 and REC 709 patterns. Let me know.

Ron

[SeeMoreDigital]

Hi Ron,

With regard to your: "All the patterns in one zip file, does not include video quality clips" samples, I notice it comes in at around 152MB :eek:

You might be interested to know that with 7-zip you can compress the same number of samples to around 80MB ;)

EDIT: Yes... some more samples would be great too....


Cheers

[CruNcher]

hi drmpeg your patterns are great i also like the vertrezmotion one alot very good to test motion adaptive deinterlacers with but im a little suprised shouldn't this be bottom field first in the stream it says top field hmm :)


If you're still interested, I can create 75% color bars patterns with the correct Sequence_Display_Extension for the REC 601 and REC 709 patterns. Let me know.


would be great thx :)

[drmpeg]

I've created the color bar patterns with the correct Sequence Display Extension for each bitstream.

http://www.w6rz.net/bars601dispext.zip

http://www.w6rz.net/bars709dispext.zip

Ron

[jmac698]

Yes, they seem to be accurate at first glance. I would like a Rec709 and Rec601 *without* sequence extension. I'm trying hard to validate my testing chain.

How did you verify that the correct YUV values showed up in your test streams?

[drmpeg]

Yes, they seem to be accurate at first glance. I would like a Rec709 and Rec601 *without* sequence extension. I'm trying hard to validate my testing chain.

How did you verify that the correct YUV values showed up in your test streams?
Color bar patterns without sequence display extension:

http://www.w6rz.net/bars601.zip

http://www.w6rz.net/bars709.zip

The color bar patterns (and in fact, all the patterns on my website) are authored directly in 4:2:2 YCbCr. There's no conversion from RGB. I then use a DVS uncompressed file server connected to a hardware real-time HD MPEG-2 encoder over HD-SDI. It's a "bit perfect" environment.

I also spot check patterns with an in-house professional bitstream analyzer.

BTW, I inadvertently coded bars601dispext.ts in 4:2:2 in case anyone is having trouble with it (although it appears most software decoders handle 4:2:2 these days).

Ron

[SeeMoreDigital]

BTW, I inadvertently coded bars601dispext.ts in 4:2:2 in case anyone is having trouble with it (although it appears most software decoders handle 4:2:2 these days).

RonThat explains why Media Player Classic's own/internal MPEG-2 direct-show filter could not display it correctly ;)

[SeeMoreDigital]

I forgot to ask...

Are any of the bars (or part of bars) supposed to be coloured/look "white" upon playback?

http://img100.imageshack.us/img100/3095/bars601tsxs5.png


Cheers

[jmac698]

You can notate bars like 75/0/75/0, which means 75% grey, and the color bars are 75% luminence. If you start with a white bar, it's 100/0/75/0.

Ron: thanks a lot! I'm trying to verify a dgindex/avisynth/gimp chain for measuring YUV directly. Then I'm trying to measure a .ts. Could you could check a clip in your stream analyzer?

[jmac698]

bars601dispext.ts
16:9,1920x1080,esc [0@2],29.970030 fps,NTSC,
Interlaced,SMPTE 170M,Frame,Top

What does "esc [0@2]" mean???

[drmpeg]

bars601dispext.ts
16:9,1920x1080,esc [0@2],29.970030 fps,NTSC,
Interlaced,SMPTE 170M,Frame,Top

What does "esc [0@2]" mean???
It means that the escape bit is set on the profile_and_level_indication field. Then the profile is 0 and the level is 2 which together signal 4:2:2 profile @ High Level.

Ron

[jmac698]

Does dgindex always send YUV in rec.601? I got some colorbars in rec.709 but they read in yuv as if 601...

[Rash]

I'm sorry to ask... but how are these color bars are supposed to be tested? Through color picker on Adobe Photoshop? And which colors are they supposed to be? Purple, for instance, should be 255/0/255? Because here it is 176/0/186.

Thank you very much.

[drmpeg]

I'm sorry to ask... but how are these color bars are supposed to be tested? Through color picker on Adobe Photoshop? And which colors are they supposed to be? Purple, for instance, should be 255/0/255? Because here it is 176/0/186.

Thank you very much.
The color picker in Photoshop is a good tool to use. However, you are not testing the bars. They are known to have good YCbCr values. What you are testing is your decoders conversion from YCbCr to RGB.

Also, these are 75% bars. So in 0 to 255 RGB, you should expect values of 191 since 255 *.075 = 191.25.

With my decoder and color picker, I get the following:

601 bars
white = 191,191,191
yellow = 192,192,1
cyan = 0,191,190
green = 0,191,0
magenta = 191,0,192
red = 191,0,1
blue = 0,1,192

709 bars
white = 191,191,191
yellow = 191,191,0
cyan = 0,191,190
green = 0,191,0
magenta = 191,0,192
red = 191,0,1
blue = 0,0,191

Ron

[SeeMoreDigital]

How are you guys using the decoder picker when playing video files?

Does PhotoShop allow you to play video within its GUI? And if so, how do you know which "Output Overlay Filter Level" it's using?

Or are you taking "Print Screen" shots and measuring the colours in PhotoShop after-wards?


Cheers

[SeeMoreDigital]

Sometime ago I made the following observations, using one of my own "Grey Scale Test Card" PNG samples as a source.

After converting the PNG to a 5 second "uncompressed" AVI file and playing it in Media Player Classic (MPC).

If I capture a still frame using MPC's "Save Image" option and do a spot check using HyperSnap: -
000:000:000 (black) is displayed at 000:000:000
255:255:255 (white) is displayed at 255:255:255

If I make a "screen capture" with MPC in VMR9 (Renderless) mode and do a spot check using HyperSnap: -
000:000:000 (black) is displayed at 000:000:000
255:255:255 (white) is displayed at 255:255:255



After converting the PNG to a 5 second "MPEG-2 (709)" file and playing it in Media Player Classic (MPC).

If I capture a still frame using MPC's "Save Image" option and do a spot check using HyperSnap: -
000:000:000 (black) is displayed at 000:000:000
255:255:255 (white) is displayed at 255:255:255

If I make a "screen capture" with MPC in VMR9 (Renderless) mode and do a spot check using HyperSnap: -
000:000:000 (black) is displayed at 016:016:016
255:255:255 (white) is displayed at 232:237:232



After converting the PNG to a 5 second "MPEG-4" file and playing it in Media Player Classic (MPC).

If I capture a still frame using MPC's "Save Image" option and do a spot check using HyperSnap: -
000:000:000 (black) is displayed at 016:016:016
255:255:255 (white) is displayed at 235:235:235

If I make a "screen capture" with MPC in VMR9 (Renderless) mode and do a spot check using HyperSnap: -
000:000:000 (black) is displayed at 016:016:016
255:255:255 (white) is displayed at 235:235:235


Strange eh?????