PDA

View Full Version : Again about Avisynth Bob. Why shift?


Fizick
28th March 2006, 00:26
Again about Avisynth Bob. :)
Some time ago I discuss, why Avisynth Bob does not preserve parity. http://forum.doom9.org/showthread.php?t=103796

No I ask: Why Bob shift frames.
Consider script.
Forget about parity today. It seems, it must be null transform.
http://forum.doom9.org/showthread.php?p=749760#post749760

avisource("blah.avi")
assume?ff()
somebob()
separatefields().selectevery(4,0.3).weave()

It is null transform for all bobbers (Kernelbob, tdeint(mode=1), etc, besides Avisynth Bob().

You can check it with subtract.
Why?
here is a code

MitchellNetravaliFilter filter(b, c);
return new_AssumeFrameBased(new Fieldwise(new FilteredResizeV(clip, -0.25, vi.height,
new_height, &filter, env),
new FilteredResizeV(clip, +0.25, vi.height,
new_height, &filter, env)));


See -0.25, +0,25.
So, both field are moved (et.est, interpolated).
Why? :)

All other bobbers do not change one of fields.

May be, fix it in Avisynth 2.5.7?

Mug Funky
28th March 2006, 01:53
actually, as i understand it (i checked with subtract ages ago), if you go "bob(0,x)" then you'll get a reversible bob. the default a and b for the mitnet filter add some blur. if you set a to zero then no blurring will happen, and the original fields will be fully recoverable.

...unless something's changed since i did the subtract test last.

foxyshadis
28th March 2006, 04:55
There's also a filter called IBob that duplicates bob, but only interpolates the missing field rather than both. I guess the reasoning behind shifting it a half-pixel is that it's then quick and easy to do the bicubicresize without field jitter, and it looks a bit more stable (both fields equally blurry, instead of lines alternately sharp and slightly blurry).

Fizick
28th March 2006, 05:49
foxyshadis,
I think about equal blurring too as only reason.

IanB
28th March 2006, 06:02
Ask Ben. Thats the way he wrote it.

Seeing the default behaviour is to resize up to the height of the input frame, I guess there must be some aesthetic reason why it is done this way

Maybe it is to make the effect from both resizers compatible. I suppose if 1 resizer just resized and the other shifted 0.5 and resized then the images would not look the same.

This is very easy to checkSeparateFields()
E=SelectEven().BicubicResize(Width(), 2*Height(), 1./3, 1./3, 0, 0.25)
O=SelectOdd().BicubicResize(Width(), 2*Height(), 1./3, 1./3, 0, 0.25)
Interleave(E, O)and then change the shift factors to see what each looks like.

Inc
28th March 2006, 10:21
IIRC When assuming again the Fieldorder behind the bob() command, the output then should be like a NOP.
Up to now I used that also in PARanoia when using filedbased resizings.

avisource("blah.avi")
a=last
b=last
b=b.assumeTFF().bob(0,0.5).assumeTFF()
b=b.separatefields().selectevery(4,0,3).weave()
subtract(a,b)

Mug Funky
28th March 2006, 10:27
hmm. there is indeed a difference. i stand corrected (for some reason, coloryuv(autogain=true) was giving me grey, when i was expecting a wild dancing black and white. using levels or mt_lutxy showed some large differences).

some regions of the picture are completely untouched, but that might be an 8-bit limit thing.