Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
22nd January 2007, 05:44 | #1 | Link |
Huh?
Join Date: Sep 2003
Location: Uruguay
Posts: 3,103
|
Blocking in red-colored areas: what could it be?
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...muxed.m2v.html Any idea what this is and how it can be eliminated?
__________________
Read Decomb's readmes and tutorials, the IVTC tutorial and the capture guide in order to learn about combing and how to deal with it. |
22nd January 2007, 10:20 | #2 | Link |
ангел смерти
Join Date: Nov 2004
Location: Lost
Posts: 9,556
|
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. |
22nd January 2007, 14:07 | #3 | Link |
Huh?
Join Date: Sep 2003
Location: Uruguay
Posts: 3,103
|
Would it be something like this (deduced from mediawiki's explanation of SWAP):
Code:
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) Code:
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)
__________________
Read Decomb's readmes and tutorials, the IVTC tutorial and the capture guide in order to learn about combing and how to deal with it. |
22nd January 2007, 14:57 | #5 | Link |
Huh?
Join Date: Sep 2003
Location: Uruguay
Posts: 3,103
|
Why is that? Also, how should it be located if used more than once?
__________________
Read Decomb's readmes and tutorials, the IVTC tutorial and the capture guide in order to learn about combing and how to deal with it. |
22nd January 2007, 16:01 | #6 | Link |
Registered User
Join Date: Feb 2004
Posts: 1,348
|
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.
|
23rd January 2007, 00:04 | #7 | Link |
interlace this!
Join Date: Jun 2003
Location: i'm in ur transfers, addin noise
Posts: 4,555
|
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.
__________________
sucking the life out of your videos since 2004 |
23rd January 2007, 01:15 | #8 | Link |
Huh?
Join Date: Sep 2003
Location: Uruguay
Posts: 3,103
|
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?
__________________
Read Decomb's readmes and tutorials, the IVTC tutorial and the capture guide in order to learn about combing and how to deal with it. |
23rd January 2007, 09:14 | #9 | Link | |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,389
|
Quote:
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 Code:
vid = whatever vid.deblock_qed().mergeluma(vid)
__________________
- We´re at the beginning of the end of mankind´s childhood - My little flickr gallery. (Yes indeed, I do have hobbies other than digital video!) Last edited by Didée; 23rd January 2007 at 09:16. |
|
23rd January 2007, 13:45 | #10 | Link |
Huh?
Join Date: Sep 2003
Location: Uruguay
Posts: 3,103
|
So, if using DeBlock(), would this:
Code:
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)
__________________
Read Decomb's readmes and tutorials, the IVTC tutorial and the capture guide in order to learn about combing and how to deal with it. |
23rd January 2007, 14:20 | #11 | Link |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,389
|
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.
__________________
- We´re at the beginning of the end of mankind´s childhood - My little flickr gallery. (Yes indeed, I do have hobbies other than digital video!) |
23rd January 2007, 14:50 | #12 | Link |
Huh?
Join Date: Sep 2003
Location: Uruguay
Posts: 3,103
|
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.
__________________
Read Decomb's readmes and tutorials, the IVTC tutorial and the capture guide in order to learn about combing and how to deal with it. |
23rd January 2007, 15:17 | #13 | Link |
ангел смерти
Join Date: Nov 2004
Location: Lost
Posts: 9,556
|
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... |
23rd January 2007, 16:46 | #14 | Link |
Huh?
Join Date: Sep 2003
Location: Uruguay
Posts: 3,103
|
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.
__________________
Read Decomb's readmes and tutorials, the IVTC tutorial and the capture guide in order to learn about combing and how to deal with it. |
23rd January 2007, 22:34 | #15 | Link |
ангел смерти
Join Date: Nov 2004
Location: Lost
Posts: 9,556
|
ІдштвЗЗ шы уйгшюююю
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. |
23rd January 2007, 22:42 | #16 | Link |
Huh?
Join Date: Sep 2003
Location: Uruguay
Posts: 3,103
|
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 .
__________________
Read Decomb's readmes and tutorials, the IVTC tutorial and the capture guide in order to learn about combing and how to deal with it. Last edited by Chainmax; 23rd January 2007 at 23:51. Reason: Update |
24th January 2007, 02:01 | #17 | Link |
Registered User
Join Date: Dec 2006
Location: Heidelberg (DE), Kraków (PL)
Posts: 519
|
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.
__________________
"Only two things are infinite: the universe and human stupidity, and I'm not sure about the former."
Last edited by HeadBangeR77; 24th January 2007 at 02:05. |
24th January 2007, 14:48 | #18 | Link | |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,389
|
Quote:
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.
__________________
- We´re at the beginning of the end of mankind´s childhood - My little flickr gallery. (Yes indeed, I do have hobbies other than digital video!) Last edited by Didée; 25th January 2007 at 13:01. |
|
24th January 2007, 23:02 | #20 | Link |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,389
|
C'mon ... if I write cm=0, then of course I mean cm=1. Logically, isn't it?
(Script corrected.) However ... didn't PrunedTree make a "modded" version of aWarpSharp (ref. in this thread), without noting what the mod actually had changed? ... perhaps cm=0 is correct with that one?
__________________
- We´re at the beginning of the end of mankind´s childhood - My little flickr gallery. (Yes indeed, I do have hobbies other than digital video!) Last edited by Didée; 24th January 2007 at 23:10. |
Thread Tools | Search this Thread |
Display Modes | |
|
|