Manipulating U and V values with AviSynth

[alexh110]

Is it possible to use AviSynth's scripting language on a YV12 avi, to compare U and V values from neighbouring pixels in a row?

Then manipulate the sign of U and V based on a set of conditions, and write the new values to an avi file?

Or would it require a bespoke dll?

[Manao]

Have a look at the masktools (in my signature). The function mt_luts might be able to do what you want. If not, try being clearer on what you exactly want to do.

[alexh110]

Thanks.
I tried using YV12LUTxy; but it's not going to achieve what I want.

I need to stop the U/V phase flipping to a different quadrant if the new magnitudes of both U and V are identical to the old ones.

Since it's very unlikely you'd have two such colours next to each other within a frame, this represents an error that needs correcting.

[foxyshadis]

YV12Lutxy is a completely different function from mt_luts. Here's the docs on the function (http://manao4.free.fr/mt_masktools.html#mt_luts), though it might be a bit iffy to cajole it into doing what you want to do.

[alexh110]

I don't think it's going to work either, as I need to work on U and V together within the same expression. As far as I can see mt_luts only allows you to work on them separately.

What I need to do is something like this (in old-fashioned BASIC):

IF U2=U1 AND V2=-V1 THEN LET V2=V1
IF U2=-U1 AND V2=V1 THEN LET U2=U1
IF U2=-U1 AND V2=-V1 THEN LET U2=U1 AND V2=V1

(Ideally I would like to use approximately equals in these expressions; rather than requiring exactly identical values.)

Also I need to do this recursively, to cope with groups of neighbouring pixels that have been incorrectly flipped.
So I would need to advance these expressions forwards pixel by pixel until all the bad pixels have been corrected.

[Didée]

For the case of compairing a pixel's UV values with those of one direct neighbor, this can definetly be done with a chain of like 5 times mt_lutxy(), give or take another one.

Things I don't get yet:

a) what exactly means "recursively"? Compairing the (x+2) neighbor pixel with the original (x), the processed (x), the original (x+1), or the processed (x+1) pixel?

b) With all that flipping, how do you ensure that you end up with the correct result? From my understanding so far, you have a 50/50 chance that either all bad pixels get corrected, OR that all good pixels get flipped to the "bad" state.

c) Can you post a screenshot of something that shows the actual problem?

[LaTo]

IF U2=U1 AND V2=-V1 THEN LET V2=V1
IF U2=-U1 AND V2=V1 THEN LET U2=U1
IF U2=-U1 AND V2=-V1 THEN LET U2=U1 AND V2=V1

function UNKNOW(clip i) {

y1=i.greyscale()
u1=i.utoy()
v1=i.vtoy()

i2=i.trim(1,0)
u2=i2.utoy()
v2=i2.vtoy()

u=frameevaluate(u1,"global udiff = YDifferenceFromNext()")
v=frameevaluate(v1,"global vdiff = YDifferenceFromNext()")

v3 = ( udiff == 0 && vdiff == 255 ) ? v2 : v1
v3 = ( vdiff == 255 && udiff == 255 ) ? v2 : v1
u3 = ( vdiff == 0 && udiff == 255 ) ? u2 : u1
u3 = ( udiff == 255 && vdiff == 255 ) ? u2 : u1

process = uvtoy(clipU=u3,clipV=v3,clipY=y1)

return ( process ) }

I don't understand the alexh110's problem, but i have made this function quickly for training with avisynth... :rolleyes:

So Didée, is this correct with the alexh110's request?

[Didée]

We've to wait for alexh110 to elaborate a bit more, but I think no, it's probably not correct. You're taking the average of all differences in a frame, and evaluate their temporal relationship. But alexh110 posted to compare U and V values from neighbouring pixels in a row which means that spatial relations between pixel values are to be evaluated: Take the pixel at location (x,y), then compare it with (x+1,y), then with (x+2,y), (x+3,y), and so forth.

[LaTo]

...alexh110 posted which means that spatial relations between pixel values are to be evaluated...
I didn't saw this... Thanks for the reply ;)

[alexh110]

By recursively I meant compairing the (x+2) neighbour pixel with the processed (x+1) pixel, then (x+3) with processed (x+2), etc...

As the good colours tend to dominate over the bad, I'm hoping that the first pixel in the row will have the correct colour most of the time. (If it doesn't then CNR filtering could be used afterwards to fix the remaining errors.)
Otherwise I would have to use some kind of area-based process, which would be much more complicated.

[2Bdecided]

Where did you get the clip from? Is it something the restoration team are working on? Or BBC R&D?

Cheers,
David.

[alexh110]

R&D, though I probably shouldn't distribute it, so have taken it down.

Can you think of any filters that will remove the errors?

I tried LaTo's function just out of interest; but kept getting the error: "I don't know what udiff means". Odd since udiff is defined as a global variable within the FrameEvaluate function.
I'm at a loss to know what is wrong?
Am using AviSynth version 2.57.

[gzarkadas]

...but kept getting the error: "I don't know what udiff means". Odd since udiff is defined as a global variable within the FrameEvaluate function.
I'm at a loss to know what is wrong?...

IMHO: u (and v) are not used anywhere inside the function and thus are out of the filter chain. The runtime scripts in them are never get evaluated and thus the global vartable is not updated with udiff and vdiff. Since udiff is the first variable used at the next line of the function, it is the place where the avisynth interpreter chokes with an error.

[gzarkadas]

By recursively I meant compairing the (x+2) neighbour pixel with the processed (x+1) pixel, then (x+3) with processed (x+2), etc...

Since you want to recursively compair processed pixels in a row, you most probably need to develop a C++ plugin for this purpose.

Trying to script a solution of this type typically (except for clips with quite small width, height) produces very long filter chains that either take an unacceptable time to encode or cannot encode at all due to memory overflow (be it overall memory, stack space, etc.).

I think you should start studying the Avisynth FilterSDK (http://avisynth.org/mediawiki/Filter_SDK) :); your task-at-need is not that complicated and you could easily adapt one of the SimpleSample examples.

[Gavino]

IMHO: u (and v) are not used anywhere inside the function and thus are out of the filter chain. The runtime scripts in them are never get evaluated and thus the global vartable is not updated with udiff and vdiff. Since udiff is the first variable used at the next line of the function, it is the place where the avisynth interpreter chokes with an error.
That's completely correct. And even if u and v were used, it still wouldn't work. Using the values of udiff and vdiff also needs to be inside a FrameEvaluate, and that has to come before the ones that set their values.
Plus as Didee pointed out the function compares across frames rather than within frames. So all in all, ... :confused:

[2Bdecided]

Found an article about this...

http://www.guardian.co.uk/technology/2008/mar/06/research.bbc

...and the working group...

http://colour-recovery.wikispaces.com/

...fascinating!

Cheers,
David.

[gzarkadas]

Yes, indeed! :cool: