Official 4:4:4 / Chroma Subsampling Thread - Page 3

I downloaded and ran that Monitor Asset Manager program. I'll include the results below, but I'm not sure how accurate they are. It shows the manufacturer date as being in late 2010, but that's certainly not the case. The back of the TV says it was manufactured in September 2011. Uhhmmm... Maybe that late 2010 date is just when the TV was originally designed?

I also checked AMD Catalyst Control Center. It shows the pixel format for the Samsung TV display to be YCbCr 4:4:4 Pixel Format. I've never changed that, so that's just what it defaulted to. Should I be using one of the RGB 4:4:4 options instead? Would one of those provide better quality?



From my 2011 Samsung UN32D6000 LED-LCD HDTV...

-------begin copy/paste-------
Monitor
Model name............... SAMSUNG
Manufacturer............. Samsung
Plug and Play ID......... SAM07C3
Serial number............ 1
Manufacture date......... 2010, ISO week 46
Filter driver............ None
-------------------------
EDID revision............ 1.3
Input signal type........ Digital
Color bit depth.......... Undefined
Display type............. RGB color
Screen size.............. 700 x 390 mm (31.5 in)
Power management......... Not supported
Extension blocs.......... 1 (CEA-EXT)
-------------------------
DDC/CI................... Not supported

Color characteristics
Default color space...... Non-sRGB
Display gamma............ 2.20
Red chromaticity......... Rx 0.640 - Ry 0.330
Green chromaticity....... Gx 0.300 - Gy 0.600
Blue chromaticity........ Bx 0.150 - By 0.060
White point (default).... Wx 0.313 - Wy 0.329
Additional descriptors... None

Timing characteristics
Horizontal scan range.... 26-81kHz
Vertical scan range...... 24-75Hz
Video bandwidth.......... 230MHz
CVT standard............. Not supported
GTF standard............. Not supported
Additional descriptors... None
Preferred timing......... Yes
Native/preferred timing.. 1920x1080p at 60Hz (16:9)
Modeline............... "1920x1080" 148.500 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync
Detailed timing #1....... 1360x768p at 60Hz (16:9)
Modeline............... "1360x768" 85.500 1360 1424 1536 1792 768 771 777 795 +hsync +vsync

Standard timings supported
720 x 400p at 70Hz - IBM VGA
640 x 480p at 60Hz - IBM VGA
640 x 480p at 67Hz - Apple Mac II
640 x 480p at 72Hz - VESA
640 x 480p at 75Hz - VESA
800 x 600p at 60Hz - VESA
800 x 600p at 72Hz - VESA
800 x 600p at 75Hz - VESA
832 x 624p at 75Hz - Apple Mac II
1024 x 768p at 60Hz - VESA
1024 x 768p at 70Hz - VESA
1024 x 768p at 75Hz - VESA
1280 x 1024p at 75Hz - VESA
1152 x 870p at 75Hz - Apple Mac II
1152 x 864p at 75Hz - VESA STD
1280 x 800p at 60Hz - VESA STD
1280 x 960p at 60Hz - VESA STD
1280 x 1024p at 60Hz - VESA STD
1440 x 900p at 60Hz - VESA STD
1440 x 900p at 75Hz - VESA STD
1680 x 1050p at 60Hz - VESA STD
1600 x 1200p at 60Hz - VESA STD

EIA/CEA-861 Information
Revision number.......... 3
IT underscan............. Supported
Basic audio.............. Supported
YCbCr 4:4:4.............. Supported
YCbCr 4:2:2.............. Supported
Native formats........... 1
Detailed timing #1....... 1280x720p at 60Hz (16:9)
Modeline............... "1280x720" 74.250 1280 1390 1430 1650 720 725 730 750 +hsync +vsync
Detailed timing #2....... 1920x1080i at 60Hz (16:9)
Modeline............... "1920x1080" 74.250 1920 2008 2052 2200 1080 1084 1094 1124 interlace +hsync +vsync
Detailed timing #3....... 720x480p at 60Hz (16:9)
Modeline............... "720x480" 27.000 720 736 798 858 480 489 495 525 -hsync -vsync

CE video identifiers (VICs) - timing/formats supported
1920 x 1080p at 60Hz - HDTV (16:9, 1:1) [Native]
1280 x 720p at 60Hz - HDTV (16:9, 1:1)
1920 x 1080i at 60Hz - HDTV (16:9, 1:1)
720 x 480p at 60Hz - EDTV (16:9, 32:27)
1920 x 1080p at 24Hz - HDTV (16:9, 1:1)
1920 x 1080p at 30Hz - HDTV (16:9, 1:1)
NB: NTSC refresh rate = (Hz*1000)/1001

CE audio data (formats supported)
LPCM 2-channel, 16/20/24 bit depths at 32/44/48 kHz

CE speaker allocation data
Channel configuration.... 2.0
Front left/right......... Yes
Front LFE................ No
Front center............. No
Rear left/right.......... No
Rear center.............. No
Front left/right center.. No
Rear left/right center... No
Rear LFE................. No

CE video capability data
CE scan behavior......... Supports overscan and underscan
IT scan behavior......... Supports overscan and underscan
PT scan behavior......... Not supported
RGB quantization range... Not supported
YCC quantization range... Not supported

CE colorimetry data
xvYCC709 support......... Yes
xvYCC601 support......... Yes
sYCC601 support.......... No
AdobeYCC601 support...... No
AdobeRGB support......... No
Metadata profile flags... 0x01

CE vendor specific data (VSDB)
IEEE registration number. 0x000C03
CEC physical address..... 1.0.0.0
Supports AI (ACP, ISRC).. Yes
Supports 48bpp........... No
Supports 36bpp........... Yes
Supports 30bpp........... Yes
Supports YCbCr 4:4:4..... Yes
Supports dual-link DVI... No
Maximum TMDS clock....... 225MHz

Report information
Date generated........... 12/31/2011
Software revision........ 2.60.0.972
Data source.............. Real-time 0x0021
Operating system......... 6.1.7601.2.Service Pack 1

Raw data

00,FF,FF,FF,FF,FF,FF,00,4C,2D,C3,07,01,00,00,00,2E,14,01,03, 80,46,27,78,0A,EE,91,A3,54,4C,99,26,

0F,50,54,BD,EF,80,71,4F,81,00,81,40,81,80,95,00,95,0F,B3,00, A9,40,02,3A,80,18,71,38,2D,40,58,2C,

45,00,A0,5A,00,00,00,1E,66,21,50,B0,51,00,1B,30,40,70,36,00, A0,5A,00,00,00,1E,00,00,00,FD,00,18,

4B,1A,51,17,00,0A,20,20,20,20,20,20,00,00,00,FC,00,53,41,4D, 53,55,4E,47,0A,20,20,20,20,20,01,78,

02,03,22,F1,46,90,04,05,03,20,22,23,09,07,07,83,01,00,00,E2, 00,0F,E3,05,03,01,67,03,0C,00,10,00,

B8,2D,01,1D,00,72,51,D0,1E,20,6E,28,55,00,A0,5A,00,00,00,1E, 01,1D,80,18,71,1C,16,20,58,2C,25,00,

A0,5A,00,00,00,9E,8C,0A,D0,8A,20,E0,2D,10,10,3E,96,00,A0,5A, 00,00,00,18,00,00,00,00,00,00,00,00,

00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00, 00,00,00,00,00,00,00,00,00,00,00,EF
-------end copy/paste-------

The problem is that sharpness is exist in PC mode only. In non-PC (YCbCr) mode Desktop looks perfect, photos look ok, and video looks not perfect anyway die to all the lossy conversions RGB > YCbCr etc.
I tried to calibrate a picture in PC mode over video driver and TV settings, but no luck. Picture brightness and contrast are just screwed and it seems not fixable. I guess its just a broken firmware in LG TVs for RGB input and there are no solutions in the net, cause only few people who care and noone can't fix that part of firmware.

FYI, my 2010 Sony 32EX700 passes 4:4:4 in Graphics mode with an HDMI/HDMI cable (no audio). Game mode may also work, I didn't try it. General mode does not.

4:4:4 rgb: 24 bit per pixel
4:4:4 ycbcr: 24 bit per pixel
4:2:2 ycbcr: 16 bit per pixel
4:2:0 ycbcr: 12 bit per pixel

Note that bluray is lossy, not lossless. Moving to 4:4:4 could in principle be compensated by compressing more. That would lead to a loss of high-frequency details, just like 4:2:0 subsampling leads to a loss of high-frequency details. My guess is that if could improve quality/bitrate trade-off for those few cases where chroma subsampling really is an issue.

-k

Thank you for this nice initiative.

Now, I remember similar problems 4 years ago when I bought my existing tv. It seems that they never learn: the really simple stuff that just "should work" often does not. Rather, they put effort into meaningless "smart-tv" functionality...

Now, this interests me: Can these tvs do 4:4:4, 24p/50p/60p 1920x1080 non-scaled/non-overscanned _at the same time_? Seems to me that they define a PC input that may have lousy video specs, then save all of the video goodies for the non-PC inputs.

If I have a PC connected that is used for still-images, bluray, occasional surfing, why should it not do a decent job for all of those without me changing tv modes (or even worse swapping HDMI connectors)?

-k

Wild guess:
The image pipeline does scale any input up by 5%. If you select no overscan, it will simply scale it back down by 5% so as to fit the panel, but since those two scaling passes are not perfect inverses, you get some artifacts.

Sounds like a stupid thing to do, but that does not mean that someone did not do it...

-k

It depends on the TV. You have to look at them on a case by case basis.

Michael

I posted this in the input lag topic as well. Please note video card HDMI setting is already set to HDMI "disable audio".

Sony Bravia KDL-32BX420

For Input Lag Test, TV is compared with NEC FE791 17" CRT Monitor @ 1280x720 clone mode. CRT cannot output 1920x1080. Video Card used is Nvidia 9800GTX+.

For Chroma 4:4:4 Test, TV is set to 1920x1080 over DVI-VGA or DVI-HDMI.


Graphics Scene Mode via VGA Connection

Input Lag

Average is 40ms - 50ms.



Chroma Test

Passes. Red Lines are solid. All Grey Text are clear, camera could not capture it properly. Text is very clear.




Game Scene Mode via VGA Connection

Input Lag

Average is 30ms - 50ms. Roughly the same as graphics mode but quality takes a dive as chroma test fails in this mode.



chroma Test

Fails. Red Lines are not solid. Red, Blue and Magenta text are blurred and barely readable.




Graphics Scene Mode via DVI-HDMI Connection

Input Lag

Average is 50ms - 70ms.



Chroma Test

Fails. Red Lines are not solid. Magenta text is blurred and barely readable.




Game Scene Mode via DVI-HDMI Connection

Input Lag

Average is 70ms.



Chroma Test

Fails. Red Lines are not solid. Red, Blue and Magenta text are blurred and barely readable.




Since I'm running the screen at 720p for input lag testing, the scaling probably introduced some lag. The TV has a widescreen "normal" mode, which disables scaling of 720p content and does 1:1 pixel mapping. This improved input lag significantly. Input Lag was around 17ms - 50ms.



Hence, if you run 1080p via VGA in Graphics Mode, the result should be similar.


Nevertheless, the input lag is too much in HDMI mode. Even in 1080p Game Mode, I can feel my actions delayed in BF3. The fact that text looks like crap using any mode over HDMI is also a major disappointment. Viewing angles are poor. You have around a 5 degree viewing angle before you see funky antiglare patterns on the screen. Not a major problem if you are using as a computer monitor as your head won't be off-center anyway. Needless to say, I won't be keeping this TV.

The only redeeming qualities are that the colors are pretty decent. Blacks are dark for a LCD. There is zero/minimal backlight bleeding. Watching movies in a dark room isn't too bad.

If you are considering this TV as a computer monitor, the only good mode for this TV appears to be VGA Graphics mode.

4:4:4 fails on all scene modes over hdmi. My Panasonic G15 plasma however seem to do well for both tests over hdmi.

I don't believe you can say that chroma compression leads to high frequency detail loss. ALL detail of an image is carried in the luma channel. For example, with component input on a TV you can disconnect the two color component inputs and still see all the image detail in B/W. The color components just add the color to the image. IIRC, the loss of high frequency detail loss is a result of the video compression codec - MPEG, etc. - setup parameters and filtering of the video, not the chroma compression. You can still have crappy looking compressed video with YCbCr 4:4:4. Chroma subsampling/compression is just another way to further reduce the video data after the "raw" video was compressed with some codec.

It would be a nice experiment to watch two encodings of a movie from the same master. One with YCbCr 4:4:4 output and one with the usual YCbCr 4:2:0. I would bet that one couldn't tell the difference when viewed normally. Only once you started dissecting and comparing frames would you most likely be able to see the differences if you looked hard enough.

larry

A color image contains 3 channels - typically either r,g and b or Y Cb and Cr. Each of these channels contains spatial information that can be cathegorized as high frequency or low frequency. If you insert a lowpass filter in either channel, that channel will experience high-frequency loss.

The reason why YCbCr (and friends) is so popular is that most of the information (even more of the relevant information) is concentrated in a single channel ("Y" or "black and white"), while the color difference channels tend to be smooth and less important. Therefore they can be subsampled and harshly compressed. See wikipedia illustration below.



Except all of the image detail is not contained in the B/W channel.

And the luminance component just add the luminance information to the image. All are needed for a realistic color image.

Chroma subsampling leads to blurring or aliasing of the spatial information contained in the color difference channels. For content with sharp color transitions, this can be quite visible.

Sure. You can also have crappy video from a lossless 1080p60 rgb 4:4:4 file - if the source was a cell-phone camera.

Chroma subsampling happens before the codec, not after. And a very similar high-frequency loss/bandwidth reduction can be implemented by setting all of the high-frequency DCT coefficients to zero in the lossy encoder (assuming intra coding for simplicity).

For most content (such as the image above) there simply isnt much high-frequency info in the color difference channels. Subsampling then has no penalty. For other content (such as the test patterns used in this thread), the subsampling leads to visible errors.

-k

Bump,

In the OP's opinion, or anyone else qualified to answer, would the following test be valid to determine if a panel is 4:4:4 capable? Or possibly as a quick and dirty test?

If the test proves to be no more than a "crutch" for the lazy, please let me know, and i promise to delete it to prevent it from becoming a crutch .



- Click the above link, then mouse over to the top of the webpage to make the dropdown menu appear.

- Click the "Text" link in the dropdown menu.

- Adjust the rightside sliders till you have a dark background.

- Adjust the leftside sliders to change the color of your text, alternate between red, blue and yellow text over darker backgrounds.

- You can drag the slider window around to test different sections of your LCD panel. Not sure if anyone would be able to detect uniformity issues that way but it wouldn't hurt to try.

Any test should be valid as long as following conditions are met:
1. need one pixel wide line made of one of primary colors, like red
2. background with the same intensity as line but different color.
3. way to verify the line is 1 pixel wide
To be honest I have no idea why TV sets fail the test used in this forum, even with chroma 422 they all should pass this test. Since that test has one pixel wide red lines on the black background, lets say 2 pixels next to each other are one red and one black on the original: and they share color (hence chroma 422) so they both red, however the red pixel has Luma set to lets say 50%, so it's visibly red, the other pixel has luma 0 so even if it's red, still should show black and the test should be passed. I believe TV's fail this test not because of chroma 422, but post processing, namely color interpolation. The black pixel, #2 instead of being displayed as black, if one followed luma, is somehow averaged from 1st (red) and third (black) or something like that. This forces errors and artifacts even on white screen with black text which should never happen.
Your linked test seems fine to me.

That's not how quite how luma works.

Look at http://en.wikipedia.org/wiki/File:YU...00_percent.png - this is the plane of colors all corresponding to a luma of 0.

For the specific example in this thread, the RGB triplet is (180,16,16) or (because I'm going to be lazy and use floating point for the rest of my post) (0.706, 0.063, 0.063). Using the Rec. 709 matrix this results in a YUV triple of (0.199, -0.064, 0.394). If the neighboring pixels get half the chroma, that results in a YUV triple of (0, -0.032, 0.197). Converting back to RGB, that's (0.252, -0.068, -0.068), or (64, 0, 0) in 8-bit (clipping negative color.)

At some point when I'm less lazy I'll finish a test pattern that has alternating red/blue and red/green lines with the same luma value, which are completely unrepresentable subsampled and should make it obvious when TVs are doing chroma subsampling rather than blurring.

Just tested a Sony KDL-46HX729 hooked up to a HTPC with a Radeon 6850 and sound enabled over HDMI and got good results after making a few tweaks on the set. (see attachment for picture of screen) My guess is that 4:4:4 should work on any Sony "HX" model. Picture quality is much improved when viewing pictures from our digital cameras.

TV settings:
1) [Home] > "Picture & Display" > "Pro Picture Setup" > "HDMI Dynamic Range" > "HDMI 2" > "Full"
2) [Options] --> "Scene Select" --> "Graphics"
3) [Home] > "Picture & Display" > "Screen" > "Auto Display Area" > "Off"
4) [Home] > "Picture & Display" > "Screen" > "Display Area" > "Full Pixel"

Radeon CCC settings:
1) "My Digital Flat Panels" > Pixel Format > "RGB 4:4:4 Pixel Format PC Standard (Full RGB)


Regards,
bspvette86

HDMI from the PC direct to the TV with sound enabled and working. FYI I noticed that the test charts have compression artifacts and should really be recreated in a lossless format for accurate testing results. Zoom in on the images to like 800% and you should see what I mean.

Regards,
bspvette86

The chart is saved in "PNG" format and I believe png uses lossless compression, so there should be no loss of detail or artifacts. I also noticed couple "errors", this could have been put there during chart creation, maybe.

I looked at the original charts on belle-nuit.com and they were created in .tiff with no artifacts. Would probably be pretty easy to recreate this test chart from the original charts on their site.

Regards,
bspvette86

i find this all confusing.

what setting should my blu ray player be set at for watching blu rays? ycbcr or rgb?

i will have the sharp 60 632 and have a panny 110 player.

thx

I modified the original 720p .tiff chart found on the belle-nuit.com site to be like the one we have been using in this thread. See attached.

Regards,
Karl

DOH!, the file uploader modified the file and introduced compression errors. changed from 1080p to 720p and re-attached image. Save the file to you desktop and view from your OS rather than through the website. The website viewer will show a modified version.

This chroma thing only affects PC input, Blue Ray discs are always chroma subsampled so it really doesn't matter anyway. I would think RGB is more for computers and YCBR or properly YcBcR is more for video coding like BR but I could be wrong.

Sony 2010 46" NX711 passes the test in game mode and a couple other modes.

You should use YCbCr output for Blu-ray and DVD; the encoded video is in YCbCr and a conversion to 8-bit RGB is slightly lossy. Better to let your TV do said conversion in its processing pipeline especially if it converts back to YCbCr internally.

However, you should probably use RGB output from computers even if you're playing Blu-rays and DVDs; YCbCr HDMI output means that the computer is likely doing YCbCr -> RGB -> YCbCr. Theoretically a hardware overlay based renderer could bypass the RGB step but compositing window managers (Windows since Vista, OS X since 10.2) break this. Anything that renders using OpenGL or Direct3D renders into RGB.

That said, it's unlikely you'd see any difference.

Here's a better screenshot of the Sony KDL46HX729 that is in focus and with a better exposure as well.

Or we could just create a new test file that would not infringe on anyone's copyright.... (see attached for example)

Regards,
bspvette86


added sample screenshots from Sony KDLXH729

Relevant article by Stacy Spears and Don Munsil:

http://spearsandmunsil.com/articles/...olorspace.html

Most video processors in TVs convert everything to 4:2:2 YCbCr internally before they do any scaling/processing.