OMG! Interlaced resizing!

[scharfis_brain]

Everytime I read this and other Forums I saw:

for interlaced resizing use:

separatefields().bicubicresize(width,height/2).weave()

I am afraid, why everyone uses it, since it is giving bad quality.

A MUCH better solution will be this one:

kernelbob(7).bicubicresize(width,height)
separatefields().selectevery(4,1,2).weave()


try stacking both methods horizontally and you'll see, what I mean.

a traditionnal upscale will result in false extra details on fine horizontal borders and a downscale will be not as crisp it could be.

my method doesn't have thoss disadvantages.

[Mug Funky]

would a lossless stupid bob work as well? that's what i've been using.

like:

bob(0,.5)
someresizer()
separatefields().selectevery(4,0,3).weave()

[scharfis_brain]

no. a lossles bob won't give the same amount of image detail and crispness like a thresholdbased bobber.

I think, the method I am using should become standard, because of its much better quality.
It is slower than the old method, but I always give quality more importance than speed.

[scharfis_brain]

here two examples

the source was a 640x480 NSTC-Clip
(which I found somewhere here in the Forum and now always use for testing deinterlacers and other methods)

downscale from 640x480 to 480x360:
http://home.arcor.de/scharfis_brain/samples/interlaced-downscale.jpg

original NTSC (640x480) Frame:
http://home.arcor.de/scharfis_brain/samples/interlaced-original.jpg

upscale from 640x480 to 480x576:
http://home.arcor.de/scharfis_brain/samples/interlaced-upscale.jpg

20 Frames video of that sequence. Frame 10 is the frame shown here.
http://home.arcor.de/scharfis_brain/samples/d9-cut.avi

btw. I don't know, what those asian letters mean.
Can someone tell me?

[mf]

How about SimpleResize's InterlacedResize?

[scharfis_brain]

interlacedresize()

does the same like

separatefields().bicubicresize().weave()

so, no difference here. both return bad quality.

kernelbob().resize().reinterlace()

is better

[scharfis_brain]

made a function (again! hurry hurry! run away! scharfis_brain is scripting interlaced!) out of my ideas:

here it is:

function interlacedscale(clip a, int w, int h, int "th", int "order")
{ th=default(th,5)
ord = getparity(a) ? 1 : 0
order = default(order,ord)

a=a.addborders(0,4,0,4)
f=a.kerneldeint(order=ord, sharp=true, twoway=false, threshold=th)
e=a.separatefields.trim(1,0).weave.kerneldeint(order=1-ord, sharp=true, twoway=false, threshold=th)
interleave(f,e).assumeframebased
crop(0,4,0,-4)

lanczosresize(w,h)
separatefields()
(order == 0) ? selectevery(4,0,3) : selectevery(4,1,2)
weave()
}

quick and dirty, the params:

w -> width in pixels
h -> height in pixels (not inches! hehe)
th -> kerneldeint threshold to deinterlace the video. (default=5)
order -> override automatic output fieldorder (default=input field order)
0 BFF
1 TFF
this means interlaced scale can also be abused changing the fieldorder WITHOUT introducing a temporal shift, like doubleweave().selectodd() does.

Tell me, wether this thing is usable or not.

[ssaga]

Originally posted by scharfis_brain
here two examples


btw. I don't know, what those asian letters mean.
Can someone tell me?
Those words mean "you can hear the director speaking":D

[DDogg]

again! hurry hurry! run away! scharfis_brain is scripting interlaced! Perfect translation - I thought you said you couldn't read the letters? :cool:

Just for the record, none of this is needed when the horizontal is not changed like in 352x480?

[Mug Funky]

nope. only for vertical resizing.

[Kika]

@scharfis_brain

Can you post the non-resized Image (the Original)?
I can see some differences between the two ways of resizing, but i can't judge the Quality without the Original-Picture.
Some Details are totaly different in the Pics - and some of them do imho look better in the Pic produced by the "old" way.

[mf]

From SimpleResize.txt
These have the same paramaters as before but are designed to operate on interlaced source,
without either blending even/odd data or messing up the coordinates because of the
even/odd line offsets. Theoretically these can lose a small amount of vertical detail
or confuse a subsequent deinterlace or IVTC function but so far in my own testing I have
not found it to be a problem.

So if you intend to keep your video in interlaced form, certainly use these. And if
you are downsizing you may find that doing the InterlacedResize first before a more
costly deinterlacing step can give you a small performance advantage on other material.
But this is still experimental. YMMV.
It is certainly not the same, scharfis_brain.

[scharfis_brain]

I editited my post above.
now the unresized image is included.
A short video clip, too.

Okay, I've tested interlacedresize more and found it a little bit better then the spefields().resize().weave() method.

but my method gives much more detail in static areas.

use something like this to compate the three:

a=separatefields().lanczosresize(480,180).weave()
b=interlacedresize(480,360)
c=interlacedscale(480,360)
interleave(a,b,c)

[HLW]

Hi!

Any chance anyone could attach the kernelbob to a reply to this thread? Or tell me where to find it? Thanks!

Best regards

Haakon

[scharfis_brain]

Or tell me where to find it?

search the forums for kernelbob*
and you'll find it....

[neuron2]

Scharfis's idea *is* theoretically better.

If you have a non-moving area, it is effectively progressive and should be resized as such, using all the lines. I don't see how anyone can doubt it. The issue is whether the adaptive bobbing process introduces sufficient artifacts to outweigh the sharper image. His evidence suggests that it doesn't.

I have some HDTV I need to resize for a DVD. I plan to use the scharfis_brain approach.

My hat is off to you, scharfis_brain!

[mf]

Originally posted by neuron2
I have some HDTV I need to resize for a DVD. I plan to use the scharfis_brain approach.

My hat is off to you, scharfis_brain!
With HDTV, you are working with such a wealth of data, that even IF the method showed considerable artifacts they would not be readily apparent when resizing from HDTV to DVD res :). So you're safe both ways.

[smok3]

sorry for bringing up this old thread, but as it seems it is still relevant,

what i have is 1920x1080 50i (which is TFF), now i would like to have (for offline editing) a pal-wide DV (BFF) proxies. Whatever combo of fieldswap (i have tried several methods and several filters) fails miserably (from jumpy picture to incredibly jumpy picture), any clues? if i just leave it TFF everything is fine.

(i have build around dumb separatefields.resize(720,576/2).weave method)

so what i need is 1920x1080 50i TFF -> 720x576 50i BFF method (speed is a virtue) and the problem seems to be going from TFF to BFF for some reason.

[Mug Funky]

for offlining this should be fine:

assumetff()
bob(height=576)
separatefields().selectevery(4,1,2).weave()
assumebff()

the 4,1,2 will swap the field order. to keep the same order, go 4,0,3

[Gavino]

assumetff()
bob(height=576)
separatefields().selectevery(4,1,2).weave()
assumebff()
Unfortunately, this won't work because Bob unilaterally resets its output to assume BFF. So you need to use

assumetff()
bob(height=576)
# now is assumed BFF
separatefields().selectevery(4,0,3).weave()

[Alex_ander]

bob() resets field order to default bff, so (4,0,3) is needed after field separation; the last assumebff() is not necessary

[smok3]

tnx a lot, this seems to work;

ffmpegSource("film.avi")

assumebff()
bob(height=576)
resize(720,576)
# now is assumed BFF
separatefields().selectevery(4,1,2).weave()

[Alex_ander]

For input tff it can only work by mutual compensation of 2 wrong things :):
a) assumed wrong field order before bob() (different from actual tff, as you say) results in wrong sequence of motion phases in 50p (you can test it by frame using '->' key)
b)in absence of that error, fields separated in bff order (as tff always forced by this particular bob) would be turned to tff on output (which you don't want) by using (4,2,1) at selection. By fortunate coincidence (analysis confirms this), wrong 'a)' step 'repairs' wrong motion phase sequence + inverts field order to the wanted bff.

[smok3]

i doubt the results are completely correct really, but it will be fine for this offline purpose.

[henryho_hk]

smok3, you may get a better aspect ratio by resizing to 704x576 and then pad 8 pixels to both left and right.

[smok3]

the HD version will be borderless, so to simulate CG and motion graphics it is in any case better/easier to leave the picture in digital full-scan, regardless of the aspect error imho.