Why does red block more in video than other colors?

[premiumcapture]

I found this but wasn't completely satisfied:
http://video.stackexchange.com/quest...deos-on-the-pc

Any thoughts?

[sanlyn]

I wasn't satisfied with that posted link and tiny blurry image, either. All you can see is that red is oversaturated for the entire image. Post something from your own captures if you're finding that problem. All I see from the red logo in that image is aliasing.

[lordsmurf]

Easy question, good question!

The issue with red and blue are sampling errors in digital domain.
- Red/blue is "2" in the typical 4:2:2, meaning half of luma.
- Green/luma is "4".

So:
- Green has no issue being 100% coverage.
- Blue isn't really noticeable, due to human vision.
- That leaves red.

Ever wonder why analog chroma noise is a blue/red mist? That's one reason why.
And in analog, red easily bled and was channel offset.

Note that it's not pure RGB either, but YUV. So "mostly blue", "mostly red" and "mostly green". Confused yet?

When you crunch it down further to 4:1:1 in a digital domain (ie, DV) it gets worse. So when somebody notices red blocky artifacts, it's almost always due to DV compression (on conversion) being applied. Thus why NTSC DV compression is terrible for conversion (but not shooting). There are other issues with DV, but that's simply one.

This all said, the clip in the StackExchange post was from Youtube, and the lineage isn't known. Lots of people do stupid things with video, and guessing is pointless.

4:2:0 can have rounding errors, but you rarely see blocking outside of 4:1:1. And when you do, then 4:2:0 was double/multiple processed in 4:2:0, instead of being used solely a distribution/delivery. In other words, they kept editing as MPEG, and didn't start/edit with 4:2:2 (low-lossy ProRes422 or lossless Huffyuv). So again, dumb person, not bad tech. MPEG should be final export or archives only. It's not for editing beyond one time.

Everybody got it now?

[premiumcapture]

Good replies!

Here's a photo showing my latest encounter:


Though the issue is in multiple places, very easy to spot on the bow near where the colors contrast. This is a DVD source and it can also be assumed to be block noise, but the red has always stood out to me.

On an interesting note, I used to use a TV as a monitor, but never noticed the issues until I switched to a smaller 27" IPS monitor. I am guessing the TV filters must have tuned it out to the point I couldn't notice it before.

[lordsmurf]

Well, this isn't really the same issue entirely. You're looking at a DVD (4:2:0), of anime (NTSC-J source). Both of those can affect color.

And we have no idea of the lineage, which may be multi-processed MPEG.

And again, red is one of most "visible" colors to the human eyes, so any slight difference in shade is seen. Othe colors are just as blocky, but you're not noticing it. There are tools that can show block artifacting, though I forget what those are offhand. However, simple abuse of the gamma can sometimes reveal it, by going darker or lighter.

My Sony HDTV smoothes over such artifacts -- a main reason I got it.

[premiumcapture]

Quote:

Originally Posted by lordsmurf

Well, this isn't really the same issue entirely. You're looking at a DVD (4:2:0), of anime (NTSC-J source). Both of those can affect color.

And we have no idea of the lineage, which may be multi-processed MPEG

From what I've ready, I believe that this was sourced from a Japanese Beta master and digitally restored and then released on NTSC-USA DVD. A common complaint for this release is the contrast level, which I suspect could be due to IRE issues. I have no idea how it was edited, but this is from the first episode of the official NA Dragonball release, straight off the DVD.

[lordsmurf]

Over-contrast is often a sign of DV (ab)use. DV conversion cooks video. So it's a possibility here, especially knowing what I do about small studios.

"Beta" could be anything. I doubt it's Betamax. More likely Digital Betacam, being from the 90s. That too, can have some artifacts, as the color is compressed 4:2:2 @ 2.3:1. Though I believe input could also be 3:3:1, with recording 4:2:2; it's been too long, at least 10 years, since I messed with any of that format.

NTSC-J's IRE won't help when shown on USA NTSC. Not much different from PAL in U.S., which also has issues with chroma hotness/saturation -- especially red.

This is why TV filters now exist. Old CRT hid the flaws, HDTV magnified them.

Videohelp has some OCD members that want to re-encode the DVDs to make them "flawless", not understanding that the mere act of decoding and re-encoding will cause loss as well. I'm all for restoration (obviously), but that's just insanity. It's good enough to watch, so they should just enjoy it.

Good conversation.

[sanlyn]

Quote:

Originally Posted by premiumcapture

Here's a photo showing my latest encounter:

I don't see any pixellation in that image. What I do see are compression artifacts (block noise, overly coarse gradients and early signs of banding, depending on how much those rough contours and color clumps flutter during play), muted color, low contrast, a puny red that's trying to go purplish, and mildly but visibly soiled whites and blacks. Possibly a poor job of resampling from Rec709 down to Rec601? Or maybe just re-encoding loss. There are some ragged and broken drawn lines. The original image looks rather lame. The low contrast hides some mild edge ringing. If your image represents the way the movie looks when playing, it would be boring visually.

Original image:


re-graded (AfterEffects CS3 settings transposed to VirtualDub filters):

[msgohan]

Quote:

Originally Posted by sanlyn

I don't see any pixellation in that image.

Both of the left edges of the bow. Also where it meets her hair, but the black line is thicker there and hides most of the chroma transition.

Quote:

Originally Posted by lordsmurf

- Green/luma is "4".
- Green has no issue being 100% coverage.

- Blue isn't really noticeable, due to human vision.

Green is "only" about 60% of luma.

The thing about our deficiency with blue matches what I've read before.

Quote:

When you crunch it down further to 4:1:1 in a digital domain (ie, DV) it gets worse. So when somebody notices red blocky artifacts, it's almost always due to DV compression

Blockiness is due to bad upsampling of the downsampled chroma on the decode side. DV gets blamed for this because so many DV decoders are old garbage that use nearest neighbor (duplication) instead of proper interpolation. A good decoder like Cedocida does it right, and DV decoders are hardly the only offenders in any event.

4:2:0 source... VLC internal (= duplication) vs hardware (= interpolation)
RGB rings - Ut VLC internal.PNG

You must be logged in to view this content; either login or register for the forum. The attached screen shots, before/after images, photos and graphics are created/posted for the benefit of site members. And you are invited to join our digital media community.

It appears that when you use Take Snapshot like the Dragon Ball screenshot, VLC uses its internal method even when it's set to play back via hardware.

Green has just as much as blocking as red, perhaps moreso. I think we just don't see fully-saturated green very often (one reason for green screens, besides Bayer).

Original
RGB rings - Ut VLC hardware.PNG

Conversions in Avisynth (all interpolation)

4:2:2

You must be logged in to view this content; either login or register for the forum. The attached screen shots, before/after images, photos and graphics are created/posted for the benefit of site members. And you are invited to join our digital media community.

4:1:1
RGB rings.png

4:2:0

You must be logged in to view this content; either login or register for the forum. The attached screen shots, before/after images, photos and graphics are created/posted for the benefit of site members. And you are invited to join our digital media community.

[sanlyn]

Quote:

Originally Posted by msgohan

Both of the left edges of the bow. Also where it meets her hair, but the black line is thicker there and hides most of the chroma transition.

Had to blow up that image 400% to see those edges. Might be easier to see in motion.

Thanks for the interpolation samples. Are there larger images anywhere?

[msgohan]

I just made the original PNG in Paint. Anything specific that you suspect a larger image would reveal?

[premiumcapture]

On another note, my MBP is much more forgiving with this issue than my PC, though my desktop monitor has lower resolution and is twice as big.

[premiumcapture]

Thanks for putting this together - I agree with your assessment of the colors 100%. Later episodes seem to do a better job, but at face value the first few do look very drab. It has always struck me as odd that for this and other animation, restoration jobs seem to be on the sloppier side even though trucks of money are going into them.

Quote:

Originally Posted by sanlyn

I don't see any pixellation in that image. What I do see are compression artifacts (block noise, overly coarse gradients and early signs of banding, depending on how much those rough contours and color clumps flutter during play), muted color, low contrast, a puny red that's trying to go purplish, and mildly but visibly soiled whites and blacks. Possibly a poor job of resampling from Rec709 down to Rec601? Or maybe just re-encoding loss. There are some ragged and broken drawn lines. The original image looks rather lame. The low contrast hides some mild edge ringing. If your image represents the way the movie looks when playing, it would be boring visually.

Original image:


re-graded (AfterEffects CS3 settings transposed to VirtualDub filters):