Yellow parts in frames

[loa-ash]

What's that type of problem?

frame N is clear, but next frame has these yellow parts absolutely noisely...

Frame N (http://img309.imageshack.us/img309/2603/before5xs.jpg)
frame N+1 (http://img316.imageshack.us/img316/994/after5iv.jpg)

what's in your opinion?? and how can I fix that?

[Guest]

Post the unprocessed source clip and give us your script.

[loa-ash]

the source is here:

Source (9MB)** (http://loalainhtp.altervista.org/vob/prew.vob)

this is my script:

mpeg2source("I:\K141\VIDEO_TS\texho2.d2v")
Telecide(order=1, guide=1).Decimate()
Temporalsoften(3,5,5,mode=2,scenechange=10)
Convolution3d("animeHQ")
FluxSmoothST(5,7)
LanczosResize(704,384)


**= if the click on link dosen't work copy the url in a new web page then download it. (URL = http://loalainhtp.altervista.org/vob/prew.vob)

[loa-ash]

Maybe I've fixed...With DGindex 1.2.1 I've used Force Film than I haven't that problem... someone can explain why??? It's strange... After that I've created the .d2v using (Force film) -> none, that has created the yellow parts...

the script is now:

mpeg2source("I:\K141\VIDEO_TS\ForceFilm.d2v")
Telecide(hints=true, order=1, guide=1).Decimate()
colormatrix()
Temporalsoften(3,5,5,mode=2,scenechange=10)
Convolution3d("animeHQ")
FluxSmoothST(5,7)
LanczosResize(704,384)


@edit: No... it's equal.. the problems remains... using force film or NoForceFilm both...

:( :( :(

[Wilbert]

1) Post frame N+2.

2) Try the same with script

mpeg2source("I:\K141\VIDEO_TS\ForceFilm.d2v")
Telecide(hints=true, order=1, guide=1).Decimate()

If that works correctly, add the filters one by one till the pb shows up.

[loa-ash]

frame N+2 is ok :(

the problem remain also with the new script.. :(

[Wilbert]

frame N+2 is ok
The reason i ask this is that i suspect that the chroma of frame N+2 is blended into frame N+1. So, please post frame N+2.

After that, try this script

mpeg2source("I:\K141\VIDEO_TS\ForceFilm.d2v")

I suspect the pb will also be there, but just want to be sure.

[Guest]

mpeg2source("I:\K141\VIDEO_TS\ForceFilm.d2v")
Telecide(hints=true, order=1, guide=1).Decimate() I'll have a look at your VOB, but in the meantime I have to point out that it makes no sense to run Telecide after sourcing a Force-Film'ed D2V!

[loa-ash]

@neuron2: yes it's true wrong script :D ... but the prob there is...

@wilbert: N+2 frame is equal to N frame... there aren't problems....

[LocalH]

What he's saying, is it the exact same image? Or is it just free from chroma problems? N+2 must be seen to deduce if the chroma issue in N+1 is based on the image data from N+2, regardless of whether or not there are chroma problems. This might help in determining what the problem is.

[loa-ash]

yes it's the same image.. here the N+2 (http://img34.imageshack.us/img34/9805/n23vs.jpg) Frame

[LocalH]

It might have something to do with your temporal soften, because it looks like something is bringing chroma from what is probably one of the earlier frames. Especially if you went straight to that frame after seeking around instead of going a few frames before it and stepping to the frame you want. Does this also occur in a proper encode, where each frame is processed sequentially? I've had weird issues like this, both in luma and chroma, when using a temporal filter then jumping around nonsequentially, where some of the frames you seek through are treated as "previous" frames by the temporal filter. I recommend going to frame N-30, and then stepping forward one frame at a time until you get to frame N+1. If you still get the chroma issue then I'm not sure what it could be.

[Guest]

You have hard telecining and the problem is there in the source material. It is not caused by any of the filters.

You can easily prove that by making a D2V with "Ignore Pulldown Flags" (or "Honor Pulldown Flags"; it doesn't matter because no flags are present) and then making a script like this:

mpeg2source("file.d2v")
assumetff.separatefields

Serve it into VirtualDub. You will see the problem present in the source fields, so it has nothing to do with pulldown, interlacing, or your filters.

[loa-ash]

I'll try your your test neuron2... thanks a lot... it's incredibile... :eek:

[LocalH]

Ah, that makes sense, I didn't actually look at the VOB. Yeah, if the chroma issue is in the VOB, then you'll just have to deal with it. Even though it's frustrating, the issue may not even be noticeable when actually watching the finished product.

[loa-ash]

Ah, that makes sense, I didn't actually look at the VOB. Yeah, if the chroma issue is in the VOB, then you'll just have to deal with it. Even though it's frustrating, the issue may not even be noticeable when actually watching the finished product.

I see that maybe to the finished product I can't see the problem, but I'd like to found the better rip as possible.. it's an heat for me...
I want to believe that the neuron2 post tells me that maybe I've a little hope to fix this.. :o

[LocalH]

Actually, there's a low chance of fixing it. It's much harder to remove artifacts like those from a video, than to prevent them from showing up in the first place (here you can tell that the crew that handled the DVD production screwed up). It's possible that one of the chroma filters available might fix it somewhat, but then you run the risk of doing even further damage to the video. If it were me, I'd probably just deal with it and leave the artifacts in there, especially if they only appear every now and then. If they appear every other frame then you are probably screwed.

[Guest]

Just to completely eliminate DGMPGDec's decoding as the cause, you can open the VOB directly in VirtualDubMod and see the artifacts there too. There was a discussion about similar symptoms in the DGMPGDec 1.4.0 thread initiated by scharfis_brain. We concluded that the sources were screwed up. :(

[loa-ash]

@neuron2: I haven't found the scharfis_brain's thread that you speak about...

edit: maybe is this thread?

http://forum.doom9.org/showthread.php?t=94184&page=15&pp=20

[loa-ash]

Actually, there's a low chance of fixing it.

:( :(


It's possible that one of the chroma filters available might fix it somewhat, but then you run the risk of doing even further damage to the video.


now I have many doubts if use chroma or not :confused:
I don't want put to risk video quality...



If it were me, I'd probably just deal with it and leave the artifacts in there, especially if they only appear every now and then. If they appear every other frame then you are probably screwed.


I've check only one episode of my DVD to rip... in this case there is this "chroma problem" but I don't know the other episode as they are...
:scared:

[MOmonster]

@loa-ash
You ask me to have a look at your source, so I´ll try to help you. First, yes it has nothing to do with dgindex. This problems you can also see in the still telecined source with every mpeg2 decoder I have. So the problem is in the vob. It looks like it is used a bad temporal chroma denoiser on the telecined stuff, or it was just a bug in the encoder.
I don´t know any filter that can help you with this probleme.
Theoretical it´s possible to create a filter that only compares the luma channel of the frames and then use the chroma of the better fields instead.
But I never saw such a problem before, so I don´t think that anybody will create such a filter or a complex function for avisynth.
But there is still a way I can help you a little bit. Your source is telecined, so every field is there twice or more. I could create a function that will choose the fields with the better chroma channel.
Oh, I just watched the chroma channel. Looks like there was made a blend conversion only on the chroma channel (I really don´t believe it). Maybe it could help to use my Cdeint as a chroma deblender. I won´t have a solution for you before this weekend. I just have not enough time for this. :rolleyes:

[loa-ash]

I'll try your Cdeint MOmonster.. thanks a lot...and I'll post the results!!!

:D

[MOmonster]

Oh, sorry, maybe I don´t say it clear enough. I´ll create a mod of my cdeblend function that works only with your chroma and then the chroma channels of this deblended version can be used instead (with mergechroma). My Cdeint version now work only with the luma channel, so this won´t help you. :)

[MOmonster]

@loa_ash
So here is my solution for you. If this function makes his own chroma problems, please post me. There is also a safer mode, you can use chromadeblend, but of course it wouldn´t be that effective.
Ok, for you small clip I worked on, it seems to help you. Just try it out.

ord = last.getparity() ? 1 : 0

a = telecide(order=ord)

c = a.BilinearResize(440,240)

b = Chromadeblend(a, tclip=c, thresh=12)

mergechroma(a, b, 1)


Function Chromadeblend(clip input, clip "tclip", float "thresh")
{
###### PREPARATION ######
global diff = default(thresh/100 + 1,1.22)
global output = input
global blendclip = tclip

###### FRAMES FOR BLENDPARAMETERS ######
global combingc1 = blendclip.trim(1,0)

###### VAR.. ######
global comblc2 = 1
global btestc1 = 1
global btestc0 = 1
global combllc1 = 1

###### Conditional Function Chain, evaluated from bottom to top (!) ######
c99=scriptclip(input, "Outputer()")

c10=FrameEvaluate(c99, "global isblend = (btestc0*diff < btestcb) && (btestc0*diff < btestc1) ? true : false")
c9=FrameEvaluate(c10, "global btestc1 = ChromaUDifference(blendmadec1, blendpicc1) / (comblc1 < comblc2 ? comblc1 : comblc2)")
c8=FrameEvaluate(c9, "global btestc0 = btestc1")
c7=FrameEvaluate(c8, "global btestcb = btestc0")
c6=FrameEvaluate(c7, "Evaluatec1()")
c5=FrameEvaluate(c6, "global blendlc1 = comblc1 < comblc2 ? 0.5 * Exp(0.8 * Log(comblc1 / comblc2)) :
\ 1 - 0.5 * Exp(0.8 * Log(comblc2 / comblc1))")
c4=FrameEvaluate(c5, "global comblc2 = UDifferenceToNext(combingc1)")
c3=FrameEvaluate(c4, "global comblc1 = comblc2")
c2=FrameEvaluate(c3, "global combllc1 = YDifferenceFromPrevious(combingc1)")
c1=FrameEvaluate(c2, "global combllc0 = combllc1")
return(c1)
}


# (running inside of the Conditional Environment)

function Evaluatec1()
{
vid0 = blendclip
vid1 = blendclip.trim(2,0)

global blendmadec1 = MergeChroma(vid0,vid1,blendlc1)
global blendpicc1 = blendclip.trim(1,0)
}

function Outputer()
{
(isblend == true) && (combllc1 < combllc0) ? output.trim(1,0) : (isblend == true ? output.duplicateframe(0) : output)
}

Use decimate after mergechroma.
I don´t know how stable this function is, so please don´t use to much filters after (just try it out).
Hope I could help you. ;)

Edit: If you have still some little chromaproblems (from the source, not the funtion) you can lower the thresh value (if the function creates chromaproblems higher this value).
And of course you should use your own tweaked telecide settings, this is just an example (maybe it is helpful for some little chroma damages to use the postprocessing with a smaller thresh value, I don´t know exact what value, but it is worth a try, if the results still not satisfy you)

[loa-ash]

MOmonster the function works fine!!! thanks a lot!! I'll apply to my source...:D

[MOmonster]

@loa_ash
Nice to hear that :D

Cu (with your next problem source ;) )

[loa-ash]

Actually I'm thinking for next rip to buy only japanese anime dvd... zero problems for rips.. better quality.... but expensive :(.... to obtain quality... it's need to spend a lot of money :(

[MOmonster]

This wouldn´t be half that interesting :)
But of course quality is also for me one of the most important thinks (else I wouldn´t use avisynth).
In hope that your next dvd looks better :)