Hi sh0dan,

You can reproduce the effect with the current script, which is this:

And change the line that reads FrameEvaluate("val = (lf / 16) + 0.2") to read FrameEvaluate("val = (lf / 16) ")
That will make the value for mergeluma to go from ~0 to 1.58

-kwag

No, but I would suspect that it would be caused by the STMedian filter :idea:
Try removing that filter and encode that scene. I don't think it's related at all to the current script, which basically changes luma values. The other filters are applied statically and evenly throughout all frames. So I don't think luma variations, specially low variations, would make any shifting of pixels.

-kwag

@kwag: "Simple"???

Anyway - it would seem like it is a blur() issue. It's coded by someone who isn't any longer in touch with us, so it might be hard to track down. For now - you seem to do fine with values > 0.2!

Could it be this ?

doom9: green pixels in leftmost column, but only when using Virtualdub to decode XviD fourCC

:( that kinda sucks that we have to stick with Blur values >0.2 ...
I still think this blurs the picture a lot, even at 704x480/576...
Well I guess we have to live with it...

That didn't fix the problem 8O

Are you interested in seing a small sample? Follow this link:
http://www.geocities.com/dorvalcs/meettheparents.zip

The file is less than 700k... But it is very noticeable!

I'm cureous to see what you think... As usual! :wink:

Don't worry :!:
We'll find a fix or a workaround in a few "centons" :mrgreen:

-kwag

Says link is unavailable :!:

-kwa

Sorry... :oops: Try again... I setup this site especially so that I could share files like this... The link is available now.

Thanks for taking the time to look at it!!

The 0.2 luma problem fixed!
 

Get rid of STMedianFilter NOW :!: :twisted:
It screwes up the luma somehow :!: That was the problem.
I just found that out, and I just updated the script. Now the luma varies from 0 to MaxTreshold again, for an extra "crispy" movie without "flashes"

Edit: This sucks :!: The STMFilter definitely causes a shift in color balance at some scenes, but I'm still getting some flashes when I lowered the value to MIN on luma. So I guess we'll have to stick to 0.2 for a while until this is further debugged :cry: :evil:

-kwag

I can see it clearly, but it's the whole frame shifting :!:
Are you positive this doesn't show, even minimal, if you encode without filters :?:

-kwag

Mmmmmm.... I should have done this before :oops: ... I've been encoding all morning with various setting to see how I could get rid of this :evil:

After removing ALL the filters... The image is still shifting :x

Sooooooo.... I put my DVD in my player.... And guess what??? The shifting is part of the source :oops: :oops: :oops:

Oh boy!!! Sorry for the trouble Kwag... Next time I'll know what to look at first :wink:

No trouble at all. I do that too :twisted: :lol:

-kwag

Kwag,

i test all the last scripts from 2 days ago at the last.(really new)
i ever see that less filters is better,
is a question of choice of arguments like you did...and you was great :!:
the last script is faster and give more details. :wink:
i can't find words to write sometimes and
the opinions of girv are great to me.
i can speak like he posted.
he always see the same as me and he wrote with big details.

go ahead friends, is really better.

:wink:

thanks.

Would some kind soul care to test this please :roll:
I hope I'm finally hitting the nail correctly, and hope that we can all have a stable script that we can start to depend on, without changing every hour :!:

Hopefully, this one won't "blink" :!: This one also blurs the frames adjacent to a scene change. That is, the frame before the scene change, AND the frame after the scene change. Not visibly detectable, but softer to the encoder and final file size.
Encode a small clip, and then load it up in Vdub. Move slowly through your clip, and notice the scene changes. See if you can see the small blur between scene changes and if there are any frames with any color bleed or flashes. THERE SHOULDN'T. I'm trying to reproduce the problems, but right now I can't. It seems that it's working. I added the STM filter again, because apparently it was some interaction with STM and the way scene detection was working. I really can't pin point what was happening. But the way the script is now, it seems that the anomalies don't show anymore 8O
I won't update the current script until I see some reports about this script that it works flawlessly :!:

Well man i think is kicking now i just did the same clip that i been doing now 4 2 friking days and the the change between Blur and sharp scenes it much much better so i think we cooking now we almost if not done. :wink:

PS: i just love this crop :lol:

@ Girv

I don't know if you have already fixed your problem. But i got also a green bar at the bottom when i forgot to change the resize and addborders values when i started a new project. When i used the correct values (from moviestacker) the bar was gone.

@ Kwag

I used the script for avs 2.52 yesterday and everything was ok. But today I wanted to do some tests and the script doesn't work corect anymore. The color is messed up, so know i have blue people. Quite funny but it's not what I want. Do you have any idea what this can be? I am using your optimal script.

Thanks

I don't have any idea (yet!), but I'm not stopping until I find out and get this right, no matter how many times I have to twist this script :!:
It's either a mathematical problem ( floating point error or something deep in the blur code ) of some other logical software control flow error.

-kwag

@ovg64 and all,

Make sure this line reads: FrameEvaluate("val = (lf / 16) + 0.05")
I forgot the "+" sign on the script above. I edited the script.

-kwag

Yeah its Kool now, using the old adaptine script there was a part where actually the face was sharp and the mouth was a blur 8O :lol: , no more of that.