4:2:2 & 4:4:4 with Blackmagics codecs

[Bassquake]

Thought Id do a quick test to see how Blackmagic Intensitys codecs works on screen capture.

See attached images. Apologies for bit gruesome image! Was taken from a news website.

8 bit 4:2:2



8bit HD 4:2:2


10bit 4:4:4


My question is that I notice the 4:2:2 seems to do something to the text causing some rainbow aliasing. Is this because of the sub-sampling of 4:2:2?

[jagabo]

My question is that I notice the 4:2:2 seems to do something to the text causing some rainbow aliasing. Is this because of the sub-sampling of 4:2:2?

Yes. 4:2:2 chroma subsampling stores the chroma channels at 1/2 the horizontal resolution. So a 1920x1080 frame will have a 1920x1080 luma channel but only 960x1080 chroma channels.

https://forum.videohelp.com/threads/294144-Viewing-tests-and-sample-files?p=1792760&vie...=1#post1792760

[poisondeathray]

But you shouldn't get rainbows on separate black and white text... even with 4:2:2 . The Y' should be encoded separately

If the black and white was besides (in proximity to) some color areas , then maybe.... but something else is going on

[jagabo]

The 10 bit 4:4:4 image has the same "rainbows" on B/W text. It's sub-pixel font smoothing in Windows.

[poisondeathray]

The 10 bit 4:4:4 image has the same "rainbows" on B/W text. It's sub-pixel font smoothing in Windows.

say what??? are you looking at the same thing ???

Definitely doesn't have the "same rainbows"

[poisondeathray]

I can replicate your results. Doesn't occur (at least not as bad) with other 8bit 422 codecs. Something screwy with BM codecs "hdyc"

BM 8bit 422 fourcc "hdyc"
BM 10bit 444 fourcc "r210"

I tested other codecs, they don't have as bad artifacts

"uly2" UT video codec 422
"2vuy" 8bit uncompressed 422
"uvyv" 8but uncompressed 422
"v210" 10bit uncompressed 422

[jagabo]

The 10 bit 4:4:4 image has the same "rainbows" on B/W text. It's sub-pixel font smoothing in Windows.

say what??? are you looking at the same thing ???

This is what I see, 4x point resize, first three lines 4:2:2, second three lines 4:4:4:



Same rainbows.

[poisondeathray]

It's definitely not the same. There is more chroma aliasing in the 4:2:2 version. The "width" of colored pixels is larger .

Examples - consider the "N" in content. The right edge goes an extra 2 colored pixels in the 4:2:2 version, but 1 pixel in the 4:4:4 version. Look at the width colored pixels of the characters compared to "white".

Even in your screenshot, look at the 1st "R" in "WARNING". Look at the inner circle, there are 2 colored pixels, vs. 1 colored + 1 white. It's wider.

For the 4:4:4 version - even when the color edge pixels are the same "width" (same number) as the 4:2:2 version, the color of the pixel is closer to "black" in the 4:4:4 version.

These things together give the perception of less aliasing. The full version is attached below (Click and view at full size)

1 - Normal


2- Saturation increased to show the colored pixel width better (there are more "white" pixels in the 4:4:4 version) . The right edge of the base of the "T" is 3 colored pixels vs. 1

[Bassquake]

I forgot to add a screenshot of the webpage so you could check for anti-alising. Unfortunately I had to do it now and the orange "Updated" is gone. But if you copy the images into photoshop and zoom right in:

Zoomed 500% in photoshop



You can tell from the text the 10bit 4:4:4 is identical to the text in the screen capture which has windows anti-aliasing applied.

Screencapture:


The 4:2:2 is definately worse and the orange shifts colour too. Should that be normal for a 4:2:2 codec?

ps. The site Im taking it from is the www.dailymail.co.uk site

edit: Ill post an image tonight using Blackmagics mjpeg but its pretty awful!

[poisondeathray]

The 4:2:2 is definately worse and the orange shifts colour too. Should that be normal for a 4:2:2 codec?

Normal and expected for areas with color.
http://en.wikipedia.org/wiki/Chroma_subsampling

The method of chroma subsampling used (resizing kernal used, and algorithm) can cause the shift to occur in different direction , or with more/less aliasing. There are pros/cons to each method

But the black/white text result is not normal, and other 422 codecs aren't as bad

[jagabo]

It's definitely not the same. There is more chroma aliasing in the 4:2:2 version. The "width" of colored pixels is larger .

Of course. The 4:2:2 version has less chroma resolution. But the "rainbows" are from sub-pixel font smoothing by Windows. So even though the source is black text on a white background there are bits of color around the edges of the text due to the font smoothing. Those discolorations are blurred by the 4:2:2 chroma subsampling.

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

Another issues is how the encoder performs the conversion from RGB 4:4:4 to YUV 4:2:2 and then how the video is converted back to RGB 4:4:4 for display. Some programs use a simple point resize. Others will use some form of averaging and interpolation.

If he turns off font smoothing, or switches to non-subpixel smoothing, those discolorations of B/W text won't occur. On new caps, obviously.

[poisondeathray]

Ah sorry I see what you are saying - the underlying reason for the "rainbows" is the same, not they are the same

But the choice of subsampling makes a big difference here. Different codecs will subsample using different algorithms (also the choice of upsampling back to RGB for the screenshot can make a difference; for example if point resampling was used and bicubic used for the screenshot, there will be another shift)

I took his 444 still image as a source and re-encoded with various codecs above. The subsampling choice was left to the codec, not the host application.
e.g. here is hdyc (BM 8bit 422) vs. uly2 (UT 8bit 422) vs. uyvy (uncompressed 8bit 422)



Not shown is the original, but uyvy has less rainbows but is technically "worse", in the sense that it doesn't preserve the original rainbows . Also the color edges of "true colors" may get shifted one way or the other. Pros/cons

[Bassquake]

As promised, the mjpeg capture which is truly awful!



No idea why it has odd missing lines.

Edit: Looks like it captures interlaced.

Heres the original capture and one using huffyuv. Its identical.

Original bmp capture:


huffyuv:


As far as I know huffy is 4:2:2, so shame blackmagic one cant do the same.

[jagabo]

As promised, the mjpeg capture which is truly awful!


[Attachment 15664 - Click to enlarge]

No idea why it has odd missing lines.

This is a well known issue with MJPEG. The lines aren't missing they're just in the wrong order. Instead of lines 0,1,2,3,4,5... they are stored as 1,0,3,2,5,4... There is usuallly a "swapf field order" setting in MJPEG decoders to account for this. If not in the MJPEG decoder it can be done with similar filters in VirtualDub and AviSynth.

[Bassquake]

@jagabo Youre right. I opened the video in virtualdub and it displayed it correctly. See attached:

Blackmagic mjpeg:


Its not too bad now. Even has less rainbow than the 8bit 4:2:2 video!