Proper interlaced -> interlaced vertical resize

[balazer]

I've spent some time thinking about the proper way to vertically resize interlaced video when the target format is also interlaced, e.g. 1080i -> 480i.

First, you should convince yourself that separating the fields and then resizing is not the proper way to do it. (if you have any doubts, try that as an experiment) Bobbing and then resizing should align everything correctly, but this strikes me as a less-than-accurate way of doing it, since you interpolate once, and interpolate again.

My math assumes a point sample-based theory of pixels and images (which is the correct view, as far as I know).

If you intend to scale from 1080i to 480i, where the top line of the 1080i image will correspond with the top line of the 480i image, and the bottom line of the 1080i image will correspond with the bottom line of the 480i image, then I think the following should work:

AssumeTFF()
SeparateFields()
top=BicubicResize( selecteven(last), 720, 240, 0, 0, -0, -0.626)
bottom=BicubicResize(selectodd(last), 720, 240, 0, 0.626, -0, -0)
interleave(top,bottom)
weave()

Here's how the math works: a 480 line image is composed of 480 lines, with a distance of 479 pixels from the top line to the bottom line. The bottom line of the 480i top field, i.e. line 478, is 1/479th of the picture height from the bottom of the picture, which corresponds to a point 1/479*1079=2.2526 pixels from the bottom of the 1080i image (measured in 1080i pixels), i.e. line 1076.747, which corresponds to a point (2.2526-1)/1078*539=0.626 pixels from the bottom of the 1080i top field, measured in 1080i field pixels (distance 539 from top to bottom), i.e. line 538.374 of the 1080i top field. The whole thing is switched around when calculating the bottom field.

The problem is that I've tried this, and the resulting image is incorrect. Either my math is wrong, or AVISynth is not performing its resize resampling in the way that I imagined.

Can anyone provide some insight?

[balazer]

I realize that I probably should multiply 0.626 by 1/539*540 to convert it from a point sample distance back to a block pixel distance that the Resize filter probably expects before plugging the value it into the filter, but that hardly makes a difference in the number.

[neuron2]

ViewFields()
[resize at will]
UnviewFields()

[scharfis_brain]

@neuron2:
this method will result in a vertical mis-alignment.

better use:

*any*bob()
resize()
separatefields().selectevery(4,0,3).weave()

[neuron2]

Originally posted by scharfis_brain
this method will result in a vertical mis-alignment.
I don't see why (without thinking about it very much). Have you tried it?

[scharfis_brain]

thanks to my new Dvorak-keyboard-layout, I am currently too lazy to describe it again.


Please read this thread:
http://forum.doom9.org/showthread.php?s=&threadid=88116&highlight=misalig%2A

[Si]

This must be something that is :-

A - very counter-intuitive

or

b - Wrong :)

Interlaced is interlaced AFAIK, QED etc.

If you want to adjust the size of interlaced video then I'm with Don - separate the fields - resize them - put them back together again.


How do get 1080i on a computer anyway?

Is 1080i an HDTV standard?

Which plonker decided to keep HDTV interlaced?????

Why didn't they make it progressive.

Or are they progressive and that where things are going wrong.

Enlighten me please :)

regards

Simon

PS The proud owner of a 50hz, 32inch, WS(16:9) PAL CRT Interlaced TV. :p

[L'il Jerry]

Originally posted by Si
Is 1080i an HDTV standard?

Which plonker decided to keep HDTV interlaced?????

Why didn't they make it progressive.

1080i is the standard because there are still plenty of things shot pure interlaced such as sporting events, the olympics, etc. Movies are shown telecined 1080i, but any good HDTV, or the HDTV receiver, should have 3:2 pulldown removal built in so this would be a moot point. And from what I've heard 1080p broadcasts take up more bandwidth then a 1080i broadcast so this could also be a contributing factor to why even movies are broadcasted 1080i (this is just what I've read and it may or may not be right).

[neuron2]

Originally posted by scharfis_brain
Please read this thread:
http://forum.doom9.org/showthread.php?s=&threadid=88116&highlight=misalig%2A I didn't say to separate fields! I said to ViewFields/Unviewfields. It's not the same thing.

[Si]

Well call me Thomas but I just don't believe this vertical misalignment thingy.

Can someone post some source example(s) so I can try it out for myself?

(And then I'll come back and eat humble pie :o )

I don't even know why sep/size/weave is different from unfold/size/fold (apart from the top/bottom field border that is) :confused: :confused: :confused:

regards
Simon
(I'm an ENTP so this is a typical reaction :) )

[scharfis_brain]

actually, there is NO difference between
viewfields().resize().unviewfields()
and
separatefields().resize().weave()

both are very bad

I've used this script to simulate a 1080i to 480i conversion
(resize factor of 1/2.25):

loadplugin("d:\x\tdeint.dll")
loadplugin("d:\x\viewfields.dll")
loadplugin("d:\x\unviewfields.dll")

i=avisource("doom9.avi").assumetff()

a=i.viewfields().lanczos4resize(320,216).unviewfields().subtitle("viewfields().resize().unviewfields()")
b=i.separatefields().lanczos4resize(320,108).weave().subtitle("separatefields().resize().weave()")
c=i.bob().lanczos4resize(320,216).assumetff().separatefields().selectevery(4,0,3).weave().subtitle("bob().resize().reinterlace()")
d=i.tdeint(mode=1,link=0,type=3).lanczos4resize(320,216).separatefields().selectevery(4,0,3).weave().subtitle("TDeint().resize().reinterlace()")

stackvertical(stackhorizontal(a,b),stackhorizontal(c,d))


results:

http://home.arcor.de/scharfis_brain/samples/vertical-mialigned1.jpg

http://home.arcor.de/scharfis_brain/samples/vertical-mialigned2.jpg

[Si]

@scharfi
I don't understand your example :o

What do you think it it showing ?

Do you have a true 1080i source (not a made up one) that I could play with for myself?

regards

Simon

[scharfis_brain]

It doesn't matter of which size your source is!
only the resize ratio counts!

eg.: 1080i to anamorpic 480i results in a ratio of 1080/480 = 2.25

for my example I took my all-purpose 480i testclip, which I downsized by 2.25 which leads to 213 (here: 216 for mod8 height!)

so my example is valid for showing the weird effects when using (un)viewfields or separatefields/weave for HDTV to SDTV conversions.

In past I made some 1080i50 HDTV to anamorphic interlaced PAL conversions.

separatefields/weave { (un)viewfields } :
http://home.arcor.de/scharfis_brain/samples/jmj-beijing5-13-un-viewfields.png

bob().resize().reinterlace()
http://home.arcor.de/scharfis_brain/samples/jmj-beijing5-13-standard.png

leakkernelbob().resize().reinterlace()
http://home.arcor.de/scharfis_brain/samples/jmj-beijing5-13-advanced.png

leakkernelbob().sharpen(0,1).resize().reinterlace()
(very nice detals, but flickers far too much!)
http://home.arcor.de/scharfis_brain/samples/jmj-beijing5-13-extreme.png

now tell me, do you really need HTDV source to proove that the first method is not recommendable?

EDIT: here is the original sized HDTV image:
http://home.arcor.de/scharfis_brain/samples/jmj-beijing5-13-original.jpg

[neuron2]

Originally posted by scharfis_brain
so my example is valid for showing the weird effects when using (un)viewfields or separatefields/weave for HDTV to SDTV conversions. Please explicitly state and point out what these "weird effects" are. I have no idea what you are talking about. Thank you.

[scharfis_brain]

uhm, what?

don't you see how blurry those separate/(un)viewfields images actally are compared to the bob()-methods?

do you need glasses? :D

[Mug Funky]

the edge on the news desk is jaggy in the top pictures, and smooth (and sharp) in the bottom ones :)

balazer's method will work if the maths is correct, however (and it faster than bobbing). i've played with this, but i keep forgetting which field to move up and which down, and when i think i've got it worked out, i have to swap them... it works in the end, so i might write down a formula or avs function at some point.

i'm just trying to find a way of field-blending that doesn't require bobbing, so i can get realtime standards-conversion going. it's doing my head in and i'm not sure it's possible... (hardware blendboxes seem to use dumb-bobbing or the more expensive ones use adaptive kernel-bobbing/motion-compensation).

[neuron2]

I'd hardly call that a "weird effect".

[Wilbert]

@scharfis_brain

Is this "light reflection" of that building in the background also an effect of resizing improperly?

[Si]

Are we talking about trying to resize interlaced video or are we trying to resize and deinterlace at the same time?

I thought the OP was talking about resizing a true interlaced video from one size to another. Apologies if I'm wrong.

regards

Simon

[neuron2]

Si,

Scharfi's doing interlaced to interlaced.

Scharfi did two frames. One is interlaced (the top four) and one is not (the bottom four).

He's made his point. It can't be denied. :)

[Si]

Of course I can deny it - that's what denial is for :)

We are talking interlaced resize - yes?

If so, no pictures here are worth looking at because we are all looking at them with a progressive screen - yes?

So, you'd need to look at the output video on a TV via proper TV out or DVD player - yes?

So, I think I need a source, do a few tests see the results and then come back and say sorry (or...) :)

regards
Simon

[Steve56]

First I had the same problem to understand the effect, when Scharfi explained it on another thread.

Maybe a simple explanation is, that when you separate the fiels or use view/unview fields, you disregard the fact, that between line 1 (odd) and line 3 (odd) you have line 2 (even), which is just a black scanline at that time. That's why in the further process you should interpolate (that's what a bob does) between line 1 and 3 and not just leave it out!

If you don't do it like this, then you weave together image information of lines, that do not belong together.

Or look at it like this: you decimate line 1 + 3, and line 2 + 4 to one line each, then you could not just put it out like: line 13 + line 24, because in the beginning they were woven together in eachother and in the output they wouldn't!

If this is a complete shot in the dark, I will delete this post later. :cool:

Steve56

[Si]

Maybe a simple explanation is, that when you separate the fiels or use view/unview fields, you disregard the fact, that between line 1 (odd) and line 3 (odd) you have line 2 (even), which is just a black scanline at that time. That's why in the further process you should interpolate (that's what a bob does) between line 1 and 3 and not just leave it out!
Ah - I'm starting to see where the opposition is coming from :)

I'll have to think about this now.


regards

Simon
PS Still wouldn't mind a link to a source video :)

[scharfis_brain]

@neuron2: the bottom 4 ones are still interlaced. They just do not show motion at all!
(but look at the graphics in the bottom right. The are interlaced!)

@wilbert: I don't understand, can you explain a little bit more?
maybe by cutting or marking out the areas of interest in those images?

@Steve56: nice explantation.
but look at the thread I linked previously:
http://forum.doom9.org/showthread.php?s=&threadid=88116&highlight=misalig%2A
there is shown a method to correctly scale without doing stupid bobbing at all.
(Though I never tried it)

@Si:
PS Still wouldn't mind a link to a source video
If you can provide some 100MBs of Space?!?
or maybe donalds FTP has some hundreds MB for various HD (1080i) Samples?!?

If so, no pictures here are worth looking at because we are all looking at them with a progressive screen - yes?

semi-correct.

hard to explain... but if one is working a lot with lacing, one is able to guess how it looks...

[balazer]

Not as easy as it looks, is it? :)

I remain convinced that there's a way to do this using Resize like in my original post. The question is, how do I derive the correct numbers to plug into the resize filter? It might help to have a precise understanding of what resize does.

We know that all of the approaches described here handle motion correctly; the issue is the vertical alignment. So you don't need motion in your tests at all.

Here is a bit of script that will make the problems (or lack of problems) clear:

Blackness(length=10, width=400, height=1080, fps=30)
Info()
#then resize by your favorite method

The small text of the Info() filter makes it easy to see any misalignment. You should compare the picture scaled with each method to a picture scaled as if the picture were progressive. Progressive scaling gives the perfect alignment that we should be able to duplicate in interlaced.

[balazer]

On second thought, we can probably never get interlaced scaling to look quite as good as progressive scaling. But if we get the alignment right, it should look pretty darn close.

[scharfis_brain]

man.
take a look at the thread I linked to!

[balazer]

O.k., I see it now. Before I was only looking for your posts.

[Si]

Here is a bit of script that will make the problems (or lack of problems) clear:
...
The small text of the Info() filter makes it easy to see any misalignment.

Many, many, many times around here, someone says x doesn't work when I do y.

people say - but what does it look like with a real z instead of computer generated x. The answer comes out different.

Have you got say 5 frames Huffyuv coded real stuff you could upload somewhere (If you'd PM me I'd give you access to 25MB of server space thats temp unused)

regards

Simon

[Wilbert]

@scharfis,

I meant this (your viewfields resize):

http://www.geocities.com/wilbertdijkhof/sep_weave.png

[neuron2]

Originally posted by scharfis_brain
@neuron2: the bottom 4 ones are still interlaced. They just do not show motion at all!
(but look at the graphics in the bottom right. The are interlaced!) That's what I meant, Scharfi. I'm blind but not an idiot. :)

[scharfis_brain]

@wilbert: this is the ringing of lanczos4
it is even present in the other images, too.
but there it is halved in size, because the input images had been blowed up before scaling

@neuron2: okay.

@Si: I'll prepare some GOPs for you tomorrow

[Si]

@balazer
Could you supply some of your stuff as well?

regards
Simon

[trbarry]

There is an InterlacedResize() function of my SimpleResize() filter that IMHO adusts for the problems stated above.

But InterlacedResize() is (and always has been) broken for YV12. It only works properly in the YUY2 color space. I think I even fixed the YV12 support once and then got side tracked with something else and lost it before releasing. Sorry.

- Tom

[eswrite]

@trbarry
I'll give your InterlacedResize() a go when I get a chance. I'm pretty sure my input is YV12, so I'll have to convert.

@scharfis_brain

I've tried the two methods you suggest as proper:

c=i.bob().lanczos4resize(320,216).assumetff().separatefields().selectevery(4,0,3).weave().subtitle("bob().resize().reinterlace()")
d=i.tdeint(mode=1,link=0,type=3).lanczos4resize(320,216).separatefields().selectevery(4,0,3).weave().subtitle("TDeint().resize().reinterlace()")


I'm not sure this really helps on my 1080i clip. I see striations (of the sort exemplified by your avatar) on side-to-side motion with either of these methods. If I just do a re-size (comment out steps 2 and 4 in the script I include below), I don't get straiations, though side-to-side motion seems somewhat abrupt at places.


#~~~ HDTV-1920x1080i.avs ~~~#
#ASYNTHER HDTV 1920x1080i 29.970fps

# This script will take a source with a res of 1920x1080i at a
# frame rate of 29.970fps and perform IVTC to get 23.976fps and
# resize it to DVD-NTSC resolution of 720x480i.
# Note: 1080i >>> 480i requires de-interlacing prior to resize;
# use method suggested by scharfis_brain.

LoadPlugin("C:\Program Files\VDubMod\DGMPGDEC\DGDecode.dll")
LoadPlugin("C:\Program Files\VDubMod\AviSynth 2.5\plugins\TDeint.dll")
#LoadPlugin("C:\Program Files\VDubMod\AviSynth 2.5\plugins\BT709ToBT601.dll")
#LoadPlugin("C:\Program Files\VDubMod\AviSynth 2.5\plugins\AC3Source.dll")

# 1) Load .dv2 source generated with DGIndex, which can process
# HDTV .tp/.ts streams or MPEG2 files generated by VideoReDo
# if the latter is used to cut commercials.
Video=MPEG2Source("hdtv_src.d2v")
Assert(Video.height >= 1080, "HDTV_1080: input clip must have 1080 scan lines")
#BT709ToBT601()
#Audio=AC3Source("hdtv_audio.wav")
#AudioDub(Video,Audio)

# 2) De-interlace source material prior to re-sizing
### TDeing sloooow, 96 hrs for 2 hr clip
#TDeint(mode=1,link=0,type=3)
### Dumb Bob much faster, 5 hrs for 2 hr clip
AssumeTTF()
Bob()

# 3) For Source AR of 1.778:1 -- 16:9 Wide-Ssreen
Crop(4,4,-4,-4) # only for 1088 scan lines
#BicubicResize(720,480,0,0.5)
Lanczos4Resize(720,480)

# 4) Interlace output for DVD MPEG2 compliance
AssumeTFF()
Separatefields().Selectevery(4,0,3).Weave()

#~~~ HDTV-1920x1080i.avs ~~~#

[neuron2]

@eswrite

The whole point of this thread is to resize but leave the clip interlaced, so why are you complaining that scharfi's method retains the "striations"?

[eswrite]

@neuron2
The whole point of this thread is to resize but leave the clip interlaced
I may have misunderstood this thread, but I thought the point was one must take care to de-interlace, resize, re-interlace when wishing to resize interlaced material. Perhaps TDeint does not de-interlace?

Also, I didn't make myself clear. These "striations" are not visible when I view the original 1080i content. They are introduced by the Bob + resize or TDeint + resize procedures and are apparent on side-to-side motion. This effect is absent when I do a dumb resize on the 1920x1080i content to generate 720x480i. In other words, if one must take special steps to resize interlaced content--i.e., de-interlace it + resize the progressive/full frame, then re-interlace--why does it appear on my one test that resizing without care gives better results?

[neuron2]

Please post a link to your unprocessed source VOB fragment. Without that, I'd just be guessing. Perhaps scharfi can make a better guess, given that it is apparently his script.

[IanB]

Balazer,

The answer to your very original question, "how to calc the offsets", is in the thread Scharfi pointed you too. Here is a "post" based link that may help you wade thru the wealth of information there. Exact Interlaced Vertical Resize (http://forum.doom9.org/showthread.php?s=&postid=594339&highlight=Exact+Interlaced+Vertical+Resize#post594339) (If broken Ctrl+F for that text)

Short answer is +/- 0.25*Height/(NewHeight-1.0)

Also take serious note of the comments about using some form of inteligent Bob (Deinterlace) in the process, the results are very much superior to offset resizing of the fields. Offset resizing is effectively the same as using dumb Bob() only much faster.

IanB

[eswrite]

@IanB:
I've been meaning to ask you about this, because this isn't working for me at all. You can see what happens in the OInterlacedResize frame at http://eswrite.50megs.com/photo.html. (If you can't see it, the algorithm you suggested produces an image that is compressed to half its expected vertical size, with random scan lines on the bottom 1/2 of the frame.)

I wrote the OInterlacedResize function from your suggested algorithm. See the following script.

@scharfis_brain:
I also wrote BInterlacedResize based on your suggested algorithm. If you look at the screen-shot in the above link, you should notice that all but the brute-force BicubicResize methods yield "jaggies" on edges (see pant legs), particularly when the camera pans from side-to-side quickly. This shows up during playback as well (not just on still images), frame after frame, and is not what I would expect as higher quality output. The brute-force BicubicResize actually looks better!? Since you and others claim that this is the wrong way to resize interlaced material, I'm curious as to what is going on here.


#Load plugins
loadplugin("C:\Program Files\VDM\DGMPGDEC\DGDecode.dll")
loadplugin("C:\Program Files\VDM\AviSynth 2.5\plugins\MSharpen.dll")
loadplugin("C:\Program Files\VDM\AviSynth 2.5\plugins\SimpleResize.dll")

##################################################################################
## Resizing for interlaced material using Bob method.
## Adapted from scharfis_brain's algorithm:
## http://forum.doom9.org/showthread.php?s=&threadid=90950&perpage=20&pagenumber=1
function BInterlaceResize(clip v, int "dstWidth", int "dstHeight")
{
v.Assumetff()
Bob()
Lanczos4resize(dstWidth,dstHeight)
Assumetff().Separatefields()
return Selectevery(4,0,3).Weave()
}

##################################################################################
## Resizing for interlaced material using offset method.
## Equivalent to "dumb Bob", but faster.
## Adapted from IanB's algorithm:
## http://forum.doom9.org/showthread.php?s=&postid=594339&highlight=Exact+Interlaced+Vertical+Resize#post594339
function OInterlacedResize(clip v, int "dstWidth", int "dstHeight")
{
v.AssumeTFF().SeparateFields()

Shift=(v.Height()/Float(dstHeight/2)-1.0)*0.25 # Field shift correction

Tf=SelectEven().LanczosResize(dstWidth, dstHeight/2, 0, -Shift, v.Width(), v.Height())
Bf=SelectOdd().LanczosResize(dstWidth, dstHeight/2, 0, Shift, v.Width(), v.Height())

return Interleave(Tf, Bf).Weave()
}

##################################################################################
#Load Audio & Video sources
Video=MPEG2Source("wed_testclip.d2v")
#Audio=NICMPASource("wed_testclip MPA T01 DELAY 66ms.mpa")
#AudioDub(Video,Audio)

## Straight bicubic resize on interlaced material, bad, bad, bad
vo_1 = Video.BicubicResize(360, 240, 0, 0.5).Subtitle("BicubicResize")

## Straight Bob with Lanczos4 resize on interlaced material, so, so
vo_2 = BInterlaceResize(Video, 360, 240).Subtitle("BInterlaceResize")

## Interlaced resize from SimpleResize.dll: requires YV12->YUY2->YV12 conversion
vo_3 = ConvertToYUY2(Video).InterlacedResize(360, 240).ConvertToYV12().Subtitle("InterlacedResize")

## Offset Interlaced resize
vo_4 = OInterlacedResize(Video, 360, 240).Subtitle("OInterlacedResize")

return StackVertical(StackHorizontal(vo_1, vo_2), StackHorizontal(vo_3, vo_4))

[eswrite]

Well, I have been experimenting, as you can see from my updated script(s) below. I have added LInterlacedResize, which uses LeakKernelBob and produces the same "jaggies" effect as the others. More encouragingly, I ran across SmoothDeinterlacer and used it to write a SInterlacedResize function which, when called with doublerate=false gives nice results. See the 2nd image from the top at http://eswrite.50megs.com/photo.html for comparison.

Comments?


##################################################################################
##
## Script: i_resize.avs
##
## Description: Contains various resizing functions for interlaced video.
##
##################################################################################
LoadPlugin("C:\Program Files\VDM\AviSynth 2.5\plugins\SimpleResize.dll")
LoadPlugin("C:\Program Files\VDM\AviSynth 2.5\plugins\LeakKernelDeint.dll")
LoadPlugin("C:\Program Files\VDM\AviSynth 2.5\plugins\SmoothDeinterlacer.dll")

##################################################################################
## Resizing for interlaced material using Bob method.
## Adapted from scharfis_brain's algorithm:
## http://forum.doom9.org/showthread.php?s=&threadid=90950&perpage=20&pagenumber=1
function BInterlacedResize(clip v, int "dstWidth", int "dstHeight", bool "show")
{
show = default(show, false)
v.Assumetff()
Bob()
Lanczos4resize(dstWidth,dstHeight)
Assumetff().Separatefields()
return show ? Selectevery(4,0,3).Weave().Subtitle("BInterlacedResize") : Selectevery(4,0,3).Weave()
}

##################################################################################
## Resizing for interlaced material using offset method.
## Equivalent to "dumb Bob", but faster.
## Adapted from IanB's algorithm:
## http://forum.doom9.org/showthread.php?s=&postid=594339&highlight=Exact+Interlaced+Vertical+Resize#post594339
function OInterlacedResize(clip v, int "dstWidth", int "dstHeight", bool "show")
{
show = default(show, false)
v.AssumeTFF().SeparateFields()

Shift=(v.Height()/Float(dstHeight/2)-1.0)*0.25 # Field shift correction

Tf=SelectEven().LanczosResize(dstWidth, dstHeight/2, 0, -Shift, v.Width(), v.Height())
Bf=SelectOdd().LanczosResize(dstWidth, dstHeight/2, 0, Shift, v.Width(), v.Height())

return show ? Interleave(Tf, Bf).Weave().Subtitle("OInterlacedResize") : Interleave(Tf, Bf).Weave()
}

##################################################################################
## Resizing for interlaced material using LeakKernelBob method.
##
function LInterlacedResize(clip v, int "dstWidth", int "dstHeight", bool "show")
{
show = default(show, false)
v.LeakKernelBob(order=1,threshold=7)
Lanczos4resize(dstWidth,dstHeight)
AssumeTFF().SeparateFields()
return show ? SelectEvery(4,0,3).Weave().Subtitle("LInterlacedResize") : SelectEvery(4,0,3).Weave()
}

##################################################################################
## Resizing for interlaced material using Smooth de-interlace method.
##
function SInterlacedResize(clip v, int "dstWidth", int "dstHeight", bool "show")
{
show = default(show, false)
v.ConvertToYUY2().SmoothDeinterlace(tff=true, doublerate=false)
BilinearResize(dstWidth,dstHeight).ConvertToYV12()
ChangeFPS(59.94)
SeparateFields()
return show ? SelectEvery(4,0,3).Weave().Subtitle("SInterlacedResize") : SelectEvery(4,0,3).Weave()
}



#Load plugins
LoadPlugin("C:\Program Files\VDM\DGMPGDEC\DGDecode.dll")
LoadPlugin("C:\Program Files\VDM\AviSynth 2.5\plugins\MSharpen.dll")

#Include Interlace resizing functions
Import("i_resize.avs")

##################################################################################
#Load Audio & Video sources
Video=MPEG2Source("wed_testclip.d2v").Crop(0,8,0,-8).AddBorders(0,8,0,8)
#Audio=NICMPASource("wed_testclip MPA T01 DELAY 66ms.mpa")
#AudioDub(Video,Audio)

## Straight bicubic resize on interlaced material, bad, bad, bad
vo_1 = Video.BicubicResize(360, 240, 0, 0.5).Subtitle("BicubicResize")

## Straight Bob with Lanczos4 resize on interlaced material, so, so
#vo_2 = BInterlacedResize(Video, 360, 240, true)
vo_2 = SInterlacedResize(Video, 360, 240, true)

## Interlaced resize from SimpleResize.dll: requires YV12->YUY2->YV12 conversion
vo_3 = ConvertToYUY2(Video).InterlacedResize(360, 240).ConvertToYV12().Subtitle("InterlacedResize")

## Offset Interlaced resize
#vo_4 = OInterlacedResize(Video, 360, 240, true)
vo_4 = LInterlacedResize(Video, 360, 240, true)

return StackVertical(StackHorizontal(vo_1, vo_2), StackHorizontal(vo_3, vo_4))

[Wilbert]

I think your field order changes somewhere when it should change.

First detect the field order. Compare:

clip.AssumeTFF().SeparateFields()

and

clip.AssumeBFF().SeparateFields()

scroll through the frames. Which one runs smooth?

If it's the latter change the function to:


function BInterlacedResize(clip v, int "dstWidth", int "dstHeight", bool "show")
{
show = default(show, false)
v.AssumeBFF()
Bob()
Lanczos4resize(dstWidth,dstHeight)
AssumeBFF().Separatefields()
return show ? Selectevery(4,0,3).Weave().Subtitle("BInterlacedResize") : Selectevery(4,0,3).Weave()
}

[eswrite]

I have verified I have TFF with this function:


##################################################################################
## Determine field order, top or bottom first.
function QueryOrder(clip v)
{
BFF=v.AssumeBFF().SeparateFields().subtitle("Bottom Field First, if motion is smooth use Telecide(order=0)")
TFF=v.AssumeTFF().SeparateFields().subtitle("Top Field First, if motion is smooth use Telecide(order=1)")
StackVertical(TFF,BFF)
}

[Wilbert]

I'm not really sure why you get that stuff. But could you post one more screenshot of the following script

MPEG2Source("wed_testclip.d2v").Crop(0,8,0,-8).AddBorders(0,8,0,8)
ConvertToRGB(interlaced=true)

I want to see the same screenshot as in

http://eswrite.50megs.com/photo.html

[eswrite]

@Wilbert,

Just to make sure, you want me to add this code, then process my 4 test cases to see a difference? Or do you want this one in place of one of the 4 frames? Note that the stack command requires all 4 frames be in the same color space. So I either make them all RGB, or I have a separate screen shot for your suggested test case. Let me know.

EDIT: In case anyone wants to try out this clip and script(s), you may download a sample at this link (http://f2.pg.briefcase.yahoo.com/bc/eswrite/vwp2?.tok=bcFUYIVB_LLeh4yb&.dir=/Video&.dnm=wed_short.zip&.src=bc) for testing.

EDIT2: @Wilbert, I went ahead and posted the image resulting immediately after the ConvertRGB(interlace=true) command. It has similar jaggies as I see after most of the recommended interlaced resize algorithms.

[Si]

Doubting Thomas here again.

Who (in this thread) has
1. 1080i source material
2. A true 1080i display device
3. A true 1080i output device
4. A PC to convert it to 576i or 480i :p
5. A 576i o 480i display device :p
6. A true 576i or 480i output device :p

I've only got 4, 5( a PAL TV) and 6 (a PAL DVD player) :p

So, who here has 1, 2 and 3 as well?

regards
Simon

[neuron2]

I have all of them. What is your point?

[eswrite]

So, who here has 1, 2 and 3 as well?

Guilty as charged. Gott'em and ain't giving them away.

[Si]

My point is that only people with that sort of setup would be able to make real world appraisals of interlaced resizing. :)

I believe that such a person needs two sorts of interlaced displays and output devices and a conversion device to do a proper comparison.:)

As I said before - I'm just in d'nile over the problem expressed here but willing and eager to find out if there is a real problem here.

So if an honest joe with a 1080i system and 1080i material and after resizing using sep.resize.sep or view.resize.unview says the pictures look bad on their TV through their DVD player (or equiv) then I'd be very interested to hear from them (and get a copy of their 1080i material) just to have a look myself :)

I realise that just because something can't be proved doesn't make it false but .... :p

regards
Simon
PS I watch stuff on a 32inch 50Hz PAL TV - most people in the world of broadcast television believe that this is unbearable to do so because of flicker... :p

[neuron2]

@eswrite

OK, this is a big to-do about nothing. Your "bicubicresize" method resizes directly a height=480 video to height=240. This is equivalent to *throwing away* one field, and thereby making the clip progressive and throwing away half of the temporal information. That is not the same thing as an interlaced resize, which is the proper subject of this thread!

Here is a direct resizing like your "bicubicresize":

lanczosresize(360, 240)

and here is a proper interlaced resizing (although a poor one):

separatefields.lanczosresize(360,120).weave

These are not equivalent. You can prove that by doing a further separatefields() on each and stepping through them. You'll see that the second one has a new picture at each field (meaning it is still interlaced), while the first does not (meaning it is now progressive, not interlaced). This also explains your observation that the "bicubicresize" method seemed more abrupt; it has half the temporal resolution after the resizing, whereas a proper interlaced resizing retains the original temporal resolution.

Your "bicubicresize" method is not better quality; it is *not* an interlaced resizing method at all, and consideration of it does not belong in this thread.

[eswrite]

Your "bicubicresize" method is not better quality; it is *not* an interlaced resizing method at all, and consideration of it does not belong in this thread.

It may be of lesser quality and definitely not an interlaced resizing method, but I disagree its evaluation doesn't belong here. It is a "control" experiment to test the assertion that one must not do a blind, brute-force bicubicrezise or any other type of resize that does not take interlacing into account. If that assertion is true, interlaced resize tests should yield at least equal, and hopefully--at the performance cost they incur--better results. My experiment seems to suggest that except for one interlaced resize method (SmoothDeinterlacer), any interlaced resize method won't do and in fact won't do any better than a blind resize. I hope that's on topic and right in line with this thread. If not, my reading comprehension has really taken a dive since High School.

I hear your argument about resizing 720x480 to 360x240. I hadn't thought about that, and it makes sense at some level... until I ran another test resizing high quality 1920x1080i HD material to 720x480i. Most of the resizing algorithms suggested earlier in this thread fail to impress. For a sampling, check out the 2nd screen capture at http://eswrite.50megs.com/photo2.html. The jaggies ain't lyin', and they are quite noticeable during normal playback. The SmoothDeinterlacer method is the only one that seems to carry the day, and yes, notice how BicubicResize screws up in the 2nd screen shot--an illustration of why it too is inadequate.

Here's the script I used for this latest test (using the same i_resize.avs I posted earlier):

#Script for loading HDTV source video.
#De-interlace prior to processing, resize, and re-interlace.

#Load plugins
LoadPlugin("C:\Program Files\VDM\DGMPGDEC\DGDecode.dll")

#Include Interlace resizing functions
Import("C:\Program Files\VDM\include\i_resize.avs")

##################################################################################
#Load Audio & Video sources
MPEG2Source("movie_30sec.d2v").Crop(0,8,0,-8).AddBorders(0,8,0,8)
Video=last
#Audio=NICAC3Source("movie_30sec AC3 T01 3_2ch 384Kbps DELAY 66ms.ac3")
#AudioDub(Video,Audio)
#return ConvertToRGB(interlaced=true)

## Straight bicubic resize on interlaced material, bad, bad, bad
vo_1 = Video.BicubicResize(720, 480, 0, 0.5).Subtitle("BicubicResize")

## Straight Bob with Lanczos4 resize on interlaced material, so, so
vo_2 = BInterlacedResize(Video, 720, 480, true)

## SmoothInterlace with Lanczos4 resize on interlaced material, best
vo_3 = SInterlacedResize(Video, 720, 480, true)

## Interlaced resize from SimpleResize.dll: requires YV12->YUY2->YV12 conversion
vo_4 = ConvertToYUY2(Video).InterlacedResize(720, 480).ConvertToYV12().Subtitle("InterlacedResize")

## Offset Interlaced resize
#vo_5 = OInterlacedResize(Video, 720, 480, true)

## LeakKernelBob Interlaced resize
#vo_6 = LInterlacedResize(Video, 720, 480, true)

## Telecide Interlaced resize
#vo_6 = TInterlacedResize(Video, 720, 480, true)

return StackVertical(StackHorizontal(vo_1, vo_2), StackHorizontal(vo_3, vo_4))
#return StackVertical(StackHorizontal(vo_1, vo_2), StackHorizontal(vo_3, vo_4), StackHorizontal(vo_5, vo_6))
#return vo_2

[neuron2]

Again, please make the source clip available. Is this the one you sent me email about, after I specifically asked you to PM me (I can't access my email at work)?

[eswrite]

Donald,

Please download from this link (http://f2.pg.briefcase.yahoo.com/bc/eswrite/vwp2?.tok=bcLXbIVBQ2qvbqIZ&.dir=/Video&.dnm=movie_short.zip&.src=bc). Let me know if it doesn't work.

[neuron2]

1. You've resized the resulting frames on your HTML page. That means they are unreliable for assessing the results, e.g., proper, expected combing becomes banding.

2. The Smoothdeinterlaced frame you give shows no combing, so it is a progressive frame and is therefore not the correct result of an interlaced resize.

3. What you are calling "jaggies" is the expected combing in the output! If combing is not present then you have not done an interlaced resize.

4. The HD clip is telecined. Use IVTC to recover progressive frames and then resize normally.

I believe you are still confused about what an interlaced resize should produce.

[eswrite]

I believe you are still confused about what an interlaced resize should produce.
I didn't think it should produce more jagged edges during normal playback (not just on a frame-by-frame view) than what the original source has. I'll keep reading, I guess.

[Wilbert]

@neuron2,

If you look at his BInterlacedResize pic, the "combed lines" are two pixels wide instead of one. Perhaps that has something to do with that his source is telecined. Perhaps not, i don't understand it yet ...

[neuron2]

Originally posted by Wilbert
If you look at his BInterlacedResize pic, the "combed lines" are two pixels wide instead of one. Perhaps that has something to do with that his source is telecined. Perhaps not, i don't understand it yet ... No, it's just because he resized the output screenshots for his web page! Those aren't 720x480. Remember, resized combing becomes banding.

I just don't see that he has ever demonstrated any problem. He should show us individual unresized output screenshots (no need for stacking).

[eswrite]

@neuron2

I spent last night going through your Decomb tutorial and users guide, and I think I'm a bit more grounded:

1) For the HD clip, you were right:
a) The combing is normal, and
b) Made worse by not applying IVTC.

2) For the VHS clip, I still see a problem on most frames where there is movement, probably because the whole thing is interlaced. I think that video is of such bad quality, I might as well write it to DVD as is and forget about it. There's not much I can do with it, it seems. Maybe a little Msharpen, if that.

I have had much better luck after I got out of the fog. See this thread (http://forum.doom9.org/showthread.php?s=&threadid=92738) for my latest HD efforts and, of course, questions ;)

[Wilbert]

For your photo2 clip (with the girl). A correct script is


mpeg2source("D:\Captures\Temp\movie.d2v")
Crop(0,0,0,-8)
Telecide(order=0)
Decimate(cycle=5)
BicubicResize(720,480)

but you probably found that out already.

As for your first clip, neuron2 is of course correct.

I used your script and made the following screenshot. I think it looks as it should look.

[neuron2]

Originally posted by Wilbert
As for your first clip, neuron2 is of course correct.
I'm wrong often enough that the "of course" part can be deleted. :)

That's the great thing about the subject matter of this forum; it's so complex and continually evolving that nobody can ever master everything.

Thanks for posting the screenshot. It shows just what I was trying to state in words.

[Si]

This stuff looks very good but I'm having trouble finding a tree in the forest :)

Could someone point me to where they've uploaded a 1080i source avi/mpeg/m2v file.

I had a look at wed_short.zip but it just seems to have 720x480 material (unless I missed something in there :confused: )

regards

Simon

[neuron2]

Si,

I'm off to the pool now, but this weekend I'll send you some laced 1080i material. Anything else you need?

[Si]

Don
Ta.
That'll do for starters.

Si

[eswrite]

@Si: did you try this link (http://f2.pg.briefcase.yahoo.com/bc/eswrite/vwp2?.tok=bcLXbIVBQ2qvbqIZ&.dir=/Video&.dnm=movie_short.zip&.src=bc)?

[neuron2]

That's telecined; I think he wants pure interlaced.

[IanB]

Originally posted by eswrite
@IanB:
I've been meaning to ask you about this, because this isn't working for me at all. You can see what happens in the OInterlacedResize frame at http://eswrite.50megs.com/photo.html. (If you can't see it, the algorithm you suggested produces an image that is compressed to half its expected vertical size, with random scan lines on the bottom 1/2 of the frame.)
...<deleted>...

...<deleted>...
Tf=SelectEven().LanczosResize(..., v.Width(), v.Height())
Bf=SelectOdd().LanczosResize(..., v.Width(), v.Height())
...<deleted>...
Helps if you port it correctly ;)
## Resizing for interlaced material using offset method.
## Equivalent to "dumb Bob", but faster.
## Adapted from IanB's algorithm:
## Exact Interlaced Vertical Resize (http://forum.doom9.org/showthread.php?s=&postid=594339&highlight=Exact+Interlaced+Vertical+Resize#post594339)
function OInterlacedResize(clip V, int "dstWidth", int "dstHeight")
{
V.SeparateFields() # correctly Assume[TB]FF() before calling this function!!

Shift=(Height()/Float(dstHeight/2)-1.0)*0.25 # Field shift correction

Tf=SelectEven().LanczosResize(dstWidth, dstHeight/2, 0, -Shift, Width(), Height())
Bf=SelectOdd().LanczosResize(dstWidth, dstHeight/2, 0, Shift, Width(), Height())

return Interleave(Tf, Bf).Weave()
}The crap at the bottom is the last 2 lines interlace repeated to pad out the height :o

Regards
IanB

[Si]

@eswrite
I tried that link before and now but it just gives an error page.:(

regards
Simon

[darkavatar1470]

I remember that still frames on a interlaced source can be progresive(that is not combed), but if we use a seperate field resizing method, the resulting frame might get combed and have jaggered edges.
So maybe we can check the frame first, and if its progresive, use a normal resizer, instead of seperate field resizing for all frames.

[IanB]

darkavatar1470,

In addition static parts of an otherwise interlaced image will benefit from "progressive" resizing, this is why the highest quality resize of an interlaced image needs to use some form of intelligent Bob/deinterlacing. i.e.
SuperDuperInteligentBob(DoubleRate=True) # Pick one
xyzzyResize(NewW, NewH)
SeparateFields()
SelectEvery(4, 0, 3) # or 1, 2)
Weave()
However a correctly implemented seperate field resizing method won't cause additional combing or jaggered edges, the distortion caused is akin to that caused by using a simple dumb Bob. This is by definition because individual fields can't be combed. Combing requires 2 fields with some elements of the image having moved.

IanB

[eswrite]

@Ianb
Helps if you port it correctly

Thanks. It works now.