Blocking in red-colored areas: what could it be?

[Chainmax]

I'm ripping my Simpsons S7 DVDs and found out that the source has some slight blocking on red-colored areas. Here's a clip showing the issue (most visible around Willie's beret):

http://rapidshare.com/files/12794029/sample.demuxed.m2v.html

Any idea what this is and how it can be eliminated?

[foxyshadis]

It has to do with the way YUV works, because the eye is by far much less sensitive to red/violets than to any other color, they're weighted far less and thus quantization affects them much more. Because the YUV conversion isn't quite right, red is usually the first place overquantization shows up. JPEG suffers the same problem. An interesting experiment is inverting the chroma planes, and see how what was a decent looking red-violet area is suddenly an unbearably bad (blocky, ringy, and banded) blue-green one.

(Interestingly, although we're less sensitive to reds in general, we're less sensitive to transitions of blue than other colors. So while a blue surface appears brighter than an identical red one, it's a little fuzzier.)

See, I guess all that schooling wasn't for naught.

How to eliminate it? Deblock the chroma planes. (And the luma if it suits your fancy.) Maybe touch it with SSIQ if that causes any color bleeding.

[Chainmax]

Would it be something like this (deduced from mediawiki's explanation of SWAP):

video=last
u_chroma = UToY(video).DeBlock_QED()
YToUV(u_chroma, video.VToY)
MergeLuma(video)
video=last
v_chroma = VToY(video).DeBlock_QED()
YToUV(v_chroma, video.UToY)
MergeLuma(video)

? Also, my current script is this:

MPEG2Source("C:\smps\Epi1.d2v",info=3)

ColorMatrix(hints=true,interlaced=true)

BiFrost()

DeCross()

DeDot()

AssumeTFF()
Deinted=TDeint(order=1,field=1,type=1)
TFM(d2v="C:\smps\Epi1.d2v",order=1,mode=6,PP=7,slow=2,mChroma=false,Clip2=Deinted)
TDecimate(mode=1)

FFT3DFilter(sigma=3,plane=3,bw=32,bh=32,bt=5,ow=16,oh=16)

gradfun2db()

DeGrainMedian()

DeHalo_Alpha()

Crop(8,0,702,480,align=true)

Spline36Resize(512,384)

aWarpSharp(depth=16,cm=1)

dull=last
sharp=dull.LimitedSharpenFaster(SMode=4,Strength=150)
Soothe(sharp,dull,25)

Would putting the chroma deblocking after the FFT3DFilter line be a good idea?

[*.mp4 guy]

To get the most out of it gradfun should always be used at the end of the script.

[Chainmax]

Why is that? Also, how should it be located if used more than once?

[*.mp4 guy]

it should be last because it adds yv12 dithering to the image, puting filters after it will get rid of the dithering or change it, there shouldn't be any benefit to using it more then once with the same strength on the same clip.

[Mug Funky]

it can also reduce contrast and bleed flat areas into other flat areas... i'd use it judiciously if i were you. also it's only relevant for RGB or if RGB appears in the filter chain. for yuv to yuv it's useless except for maybe VMR display on a computer.

dither can be achieved with addgrain at very low (nearly imperceptible?) amounts.

[Chainmax]

Ok, so gradfun2db should only be used in extreme banding cases or if RGB colorspace is introduced/present in the chain then. Thanks for the advice :). What about the question in my second post, is the script snippet I posted a good way to deblock chroma?

[Didée]

Would it be something like this (deduced from mediawiki's explanation of SWAP):

video=last
u_chroma = UToY(video).DeBlock_QED()
YToUV(u_chroma, video.VToY)
MergeLuma(video)
video=last
v_chroma = VToY(video).DeBlock_QED()
YToUV(v_chroma, video.UToY)
MergeLuma(video)

That's not really a good idea. Basically for the almost same reason like this here (http://forum.doom9.org/showthread.php?p=934083#post934083) :

Deblock_QED works with a fixed 8x8 grid mask. But if you execute UVtoY(), then you get a halfsize frame, where the smallest possible blocksize is 4x4. Thus deblock_qed will potentially miss half of all blocking, if you do it that way ...

If at all, then it would simply be
vid = whatever
vid.deblock_qed().mergeluma(vid)

However, if it's only chroma that is concerned, perhaps you're better off with just deblock().

[Chainmax]

So, if using DeBlock(), would this:

video=last
u_chroma = UToY(video).DeBlock()
YToUV(u_chroma, video.VToY)
MergeLuma(video)
video=last
v_chroma = VToY(video).DeBlock()
YToUV(v_chroma, video.UToY)
MergeLuma(video)

be the correct script snippet or would there be a more elegant, shorter solution? Also, as you can see I'm already using BiFrost, DeCross and FFT3DFilter on chroma because the source has some nasty rainbows, won't using DeBlock() blur the chroma too much?

[Didée]

... won't using DeBlock() blur the chroma too much?
Can't be answered ... that's up to you to decide. :)

I'm just wondering: Deblock() is deblocking both luma and chroma. Why do you want to go that road with putting-chroma-into-luma, deblock that (with 2 instances of deblock), and then put-chroma-back-from-luma-to-chroma?

The result is (should) not be different from just deblock().mergeluma(last) like I posted above ... you get the same, but do it much more complicated, and slower.

[Chainmax]

What I want to do is to deblock the chroma in order to get rid of the blocking in red-colored areas like Groundskeeper Willie's beret in the sample I posted i the OP.

[foxyshadis]

The cpu2="oxoxoo" argument to mpeg2source will also deblock chroma-only. I don't see any actual blocking, but I'm tired and Didée has called me blind before. >.> Maybe the horror of the dot crawl is making my brain shut down - you couldn't pay me to watch that.

For some reason upconv=1 isn't working, and you have to manually specify interlaced conversion to rgb or yuy2 to see it correctly. I wonder if I've trusted upconv incorrectly in the past...

[Chainmax]

Actually, it wasn't Didée who said this was a chroma blocking issue. You suggested that on the second post. Maybe this isn't a chroma blocking issue?
In any case, how does MPEG2Source's deblocking compare to DeBlock() and DeBlock_QED() in terms of blurriness and detail removal? The source has to go through enough filtering as it is, and I don't want to overdo it.

[foxyshadis]

ІдштвЗЗ шы уйгшюююю

Okay, I don't know what happened there. Trying again,

BlindPP is the same as the cpu argument, aside from being blind about it. Deblock has a bit different look to it, but they both do their deblocking thing. At least with the built-in version the strength is based on the quant. I don't think you'll see any difference if you use them in chroma-only, since shows like that have practically no chroma detail to protect.

I hadn't actually seen the clip for the first post. I don't know what would actually futher improve it after all that filtering.

[Chainmax]

Ok,I'll try the cpu2 parameter then,thanks for the suggestion. I'd still like to ask you to download the sample (it's only ~8MB) and see if you can spot the problem.

By the way, this thread has given me a couple of new ideas on how to deal with my infamous Simpsons S1E1 clip. Could you please tell me how would I go about using FunkyDeBlock() on both chroma planes?


[edit]using cpu2="ooxxoo"didn't yield any noticeable difference, so it probably isn't chroma blocking :confused:.

[HeadBangeR77]

I'm dealing with some heavily blocked source atm, encoding many samples using Deblock (Fizick's plugin) and BlindPP. If I come to any useful conclusions, I'll report back immediately. Over ;)

PS. Deblock seems to do a better job, as for now at least, higher quants than the default 20, but I'm playing with threshold and the second argument (strength? sensitivity?), to reduce smoothing of some small fine details.

[Didée]

but I'm tired and Didée has called me blind before. >.>
Have a reference when/where I should've insulted you in such a way? I remember once pulling your leg (http://forum.doom9.org/showthread.php?p=851781#post851781) a little, and once I asked whether your eyes are tired (http://forum.doom9.org/showthread.php?p=892518#post892518) (which will happen after 20 hours in front of the screen).
That's all I can remember. :)

To the issue (managed to have a look at the sample, finally)

As it has been mentioned already, that's not "blocking", just the usual YV12 color disease. Also, there seems to be some sort of color bleeding, since in those places the color "from the other side" sneaks over the black lines.
Perhaps something can be fiddled with color smoothing ( RemoveGrain(0,11), or blur(0,1) or mt_convolution("1","1 2 1",Y=2,U=3,V=3) ) plus luma-guided chroma warping ( MergeChroma(aWarpSharp(cm=1)) ) ... happy toying, I can't/won't.

[Alain2]

luma-guided chroma warping ( MergeChroma(aWarpSharp(cm=0)) )
I don't follow.. if you disable chroma processing in awarpsharp, what is doing MergeChroma(aWarpSharp(cm=0)) ?

[Didée]

C'mon ... if I write cm=0, then of course I mean cm=1. Logically, isn't it? :D
(Script corrected.)

However ... didn't PrunedTree make a "modded" version of aWarpSharp (ref. in this thread (http://forum.doom9.org/showthread.php?t=87514)), without noting what the mod actually had changed? ... perhaps cm=0 is correct with that one? ;)

[Alain2]

Well I thought it was something like that, but I prefer to have your confirmation ^^ Also because I was not sure: as awarpsharp makes edges thinner, I thought this would then make the "chroma edges" thinner, thus going above the thicker luma edges of the source... ? As you said it should correct the chroma bleeding, I am still not sure of my interpretation of this code.. But I like the idea of a "luma-guided chroma warping", hence my interest here ^^

[Chainmax]

Didée: are you sure that would be a good idea? I already have lots of chroma denoising (BiFrost, DeCross, FFT3DFilter) and aWarpSharp is also on the script already...

[Didée]

Didée: are you sure that would be a good idea? I already have lots of chroma denoising (BiFrost, DeCross, FFT3DFilter) and aWarpSharp is also on the script already...
I didn't care in any way for your filterchain. You complained about an artefact. I looked at the raw source, and just told my immediate thought to improve on that artefact, from the raw. That's all, period.

But the answer is really simple to find:

Q: Does your "lots of chroma denoising" eliminate the problem?

A ="yes": --> problem is already solved (why are we still talking?) ;)

A = "no": --> try what was suggested. :)

[Chainmax]

There's no need to react like that.

[Didée]

Duly noted, but ... either you got me wrong, or not the point.

"The point" is simply this: it seems that the mentioned artefacting is still there after your chroma filtering (else you wouldn't ask at all, would you?). My suggestion (should) improve on the artefact. So, why the question if it's a good idea?

Besides,

and aWarpSharp is also on the script already...

you're using "only" aWarpSharp(depth=16,cm=1)

which is not the same as my suggestion. Mine will warp chroma, and leave luma in place. Yours will warp luma and chroma simultaneously. That's fine if luma and chroma are already correctly aligned. But if they're not, it will warp chroma to the point where luma had been before it got warped, too. See the difference? Like the fairytale of rabbit and hedgehog doing a race.

[Chainmax]

Ok, so I'll try MT_Convolution("1","1 2 1",Y=2,U=3,V=3) and MT_Convolution("1","1 2 1",Y=2,U=3,V=3).MergeChroma(aWarpSharp(cm=1)) and see which one looks better. I intend to put either option right after the FFT3DFilter line, would that be ok or should they be put elsewhere?

[Chainmax]

I tried using each suggestion separately, then both at once and they didn't make much of a difference, as can be seen in this comparison:

Normal Chain:
http://img261.imageshack.us/img261/774/nrmlchn3uf.png (http://imageshack.us)

MT_Convolution + MergeChroma (right after IVTC):
http://img408.imageshack.us/img408/7663/sggstn4ml.png (http://imageshack.us)

The artifact is much more evident in the source though, so if no solution can be found I think it won't be much of an issue to just use the normal chain.

[Sharro]

Another little speed up:

In colormatrix use (*d2v="Epi1.d2v") if in same folder of avs or full path if it's not. Remove the hints in colormatrix and info=3 on mpeg2source.

also use, in colormatrix, parameter threads=0 (auto, will use thread=processors found)

Both give me a 10% extra fps on first pass.

[Chainmax]

You should post that in the ColorMatrix thread, not here.

[Sharro]

You should post that in the ColorMatrix thread, not here.

Sorry Chainmax.

I guessed giving a hint about this avs script wouldn't harm anyone.

All the best,

Sharro

[Chainmax]

You misunderstood me, what I meant is that your hint would have a much bigger exposure in the ColorMatrix thread. I don't mind you posting it here, after all you gave the thread a bump :).

[Sharro]

After a long time away from irc.freenode, I did a visit to #X264, even though I don't use it, and asked how X264 behaved with the Red's cause beyond the case on this thread I did an encode where the effect was terribly visible.

About the answer itself, X264 should behave the same way as Xvid.

Then Microchip_ the creator of Xvidenc (http://sourceforge.net/projects/xvidenc), a script for Mencoder, gave me an explanation about the problem of Red's.

With his permission I quote part of his readme that comes with the script that I'll test myself but could be interesting for this thread:

"Do not scale down too much
~~~~~~~~~~~~~~~~~~~~~~~~~~

Scaling is always been an issue in MPEG compression. One might want to scale down
a movie for different reasons, to lower the bitrate or file size of the encode.
However, the MPEG compression does not like scaling down too much. If you scale
down the original source to, lets say, 512x208, then you'll get the annoying stair
steps in red colors, though this is not really MPEG's fault but has also to do with
software scaling. Every time you see a bright/full red color in the movie, it will
have lines (stair steps) in it. Another point in favour of not trying to scale down
too much is that the MPEG compression has to compress high frequencies much more than
low frequencies and it doesn't like that at all.

XviD does offer an option that tries to reduce the red stair steps in the video by doing
some color magic on it. That option is called a Chroma Optimized Prefilter and you should
use it every time you scale down a lot."

I'll try an anamorphic encode without resizing on the movie I had problems with and revert with the results.

I've also noted a very similar problem with fluorescent green on animated movies.

All the best,


Sharro

[Chainmax]

[...] I don't always have a problem when resizing animated content. As far as I know, stairstepping is a problem for some resampling methods at big upsampling factors.

As a side note and since it hasn't been answered yet:


...
By the way, this thread has given me a couple of new ideas on how to deal with my infamous Simpsons S1E1 clip. Could you please tell me how would I go about using FunkyDeBlock() on both chroma planes?
...


Edit: Profanity removed.
Edit2: Thanks :).

[Chainmax]

Anyone?

[sh0dan]

@Chainmax: Watch your language. Using profanities aren't going to get you answers.

[Sharro]

Profanities aside.

My blocking in red-colored areas without any filtering remained even after no resizing (just cropped), it was slightly better, but still...blocky/stairstepped.

@Chainmax: Any chance of trying your script without any resizing ?

http://members.netmadeira.com/carlos.santos/Blocky.Reds.png

Xvid had both Chroma Optimizer and Chroma Motion estimation active.

I wonder if "MPEG compression has to compress high frequencies much more than low frequencies and it doesn't like that at all" is not a profanity and if the blocking could be improved by the right quantization matrix, without any extra filtering.

All the best,

Sharro

[Chainmax]

Sbarro: as you can see from the images I posted above, both the original script and Didée's suggested modification were tried without resizing. Resizing actually slightly helps to hide the artifacting, just not enough for it to become unnoticeable.

[Chainmax]

foxyshadis, Mug Funky: could you please tell me how would I ago about using DeBlock() or FunkyDeBlock() on the chroma planes?

[Didée]

A bird flew by and sang a song of "all deblockers natively are doing their work on the chroma planes, too ..."

[Chainmax]

I didn't know that, but be that as it may I still want to use them only on the chroma planes. That might not help here, but it could be of big help in my Simpsons torture clip (not the one with horrendous halos, another one).

[Boulder]

org=last
deblock_to_death()
MergeLuma(org)

[Chainmax]

Thanks for the tip :). My current script is this:

MPEG2Source("C:\smps\Epi1.d2v",info=3)

ColorMatrix(hints=true,interlaced=true)

BiFrost()

DeCross()

DeDot()

AssumeTFF()
Deinted=TDeint(order=1,field=1,type=1)
TFM(d2v="C:\smps\Epi1.d2v",order=1,mode=6,PP=7,slow=2,mChroma=false,Clip2=Deinted)
TDecimate(mode=1)

FFT3DFilter(sigma=3,plane=3,bw=32,bh=32,bt=5,ow=16,oh=16)

DeGrainMedian()

DeHalo_Alpha()

Crop(8,0,702,480,align=true)

Spline36Resize(512,384)

aWarpSharp(depth=16,cm=1)

dull=last
sharp=dull.LimitedSharpenFaster(SMode=4,Strength=150)
Soothe(sharp,dull,25)

gradfun2db()

Would putting your suggestion right after IVTCing be ok or is there a better place to use it on?

[Boulder]

I'd place the deblock right after IVTC because the sharp block edges are still there. The deblocker needs them to determine what is a block and what is detail.

[Chainmax]

I'll post a before-after comparison as soon as I try it, thanks for the help :) http://smilies.vidahost.com/otn/wink/thumb.gif.


[edit]deleted
[edit 2]Oops, read the advice too quickly :o.

[Chainmax]

Well, it definitely isn't chroma blocking, as you can see in this comparison:

http://img201.imageshack.us/img201/1351/testwithchromadeblockinqy4.png (http://imageshack.us)

I'm really stumped right now :confused:.

[Soulhunter]

Isnt this just the usual YV12 chroma subsamplig effect?


Bye

[Boulder]

Exactly what I thought it might be, but I thought that the more experienced users would have pointed it out already if it was so.

[Sharro]

Bahahaha :),

Sorry about this... but ... ehehe ... I've also followed a few hints on how to remove the red blocks...

In the end forcing output of Xvid decoder to YV12...

Sorry... can't stop this smile :) :stupid:

All the best,

Sharro

PS: Soulhunter Great crappy page you got :D

[Soulhunter]

@ Boulder

Yeah, its funny nobody noticed this... >.>


@ Sharro

Thanks! ^^;

Wrote it in 2-3 days with zero html knowledge!


Bye

[Chainmax]

Exactly what I thought it might be, but I thought that the more experienced users would have pointed it out already if it was so.

But how come (IIRC) this never happened to any of my past animated content rips? Besides, from the pictures posted, it's clear that the current filterchain helps alleviate the problem, so there should be some extra filtering ideas that are escaping me.