Proper interlaced -> interlaced vertical resize

[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.

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.ph...ght=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):

[Guest]

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 ~~~#

[Guest]

@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?

[Guest]

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 (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.ph...0&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.ph...ize#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))