downsize interlaced

[pantau]

i'm trying to downsize 1920x1080 to 720x484

using lanczosresize, the material gets de-interlaced

how could i downsize the fields separately, and the join them again?

thanks!

[Guest]

Use a high quality double rate bobber. Resize the result. Finally, re-interlace.

[pantau]

Use a high quality double rate bobber. Resize the result. Finally, re-interlace.

thanks...

unfortunately my avisynth knowledge is still to basic for that. i was starting with

QTInput ("E:\EcoHHH\temp.mov")
AssumeTFF()
SeparateFields()
Lanczos4Resize(720,486)

but of course this only produces half of the video...

could you help with a sample script??

[Atak_Snajpera]

simple yadif will be enough . no need to use qtmc

yadif
resize
wave

[pantau]

i thought yadif DEinterlaces??

[Atak_Snajpera]

you have to first deinterlace.

[pantau]

that's exactly what i want to avoid... i want to downsize keeping the material truly interlaced, by downsizing the fields separately, and then joining them again after the downsize.

[Atak_Snajpera]

you won't see difference.

[Didée]

yadif
resize
wave
That's a little sloppy. Give "mode" to yadif, and "wave" is not a filter.

Yadif(mode=1) # bob mode, 25i (30i) becomes 50p (60p)
XyzResize(720,480)
Separatefields().SelectEvery(4,0,3).Weave() # re-interlace 50p/60p to 25i/30i

[pantau]

you will, i have thoroughly tested that... of course you only see it on TV, not when you play it on the computer...

[pantau]

That's a little sloppy. Give "mode" to yadif, and "wave" is not a filter.

Yadif(mode=1) # bob mode, 25i (30i) becomes 50p (60p)
XyzResize(720,480)
Separatefields().SelectEvery(4,0,3).Weave() # re-interlace 50p/60p to 25i/30i

that looks good, maybe i was wrong?? so is yadif not actually deinterlacing (that is, only separating fields) when using mode 1?

[pantau]

That's a little sloppy. Give "mode" to yadif, and "wave" is not a filter.

Yadif(mode=1) # bob mode, 25i (30i) becomes 50p (60p)
XyzResize(720,480)
Separatefields().SelectEvery(4,0,3).Weave() # re-interlace 50p/60p to 25i/30i

As the video is NTSC, would I have to change the SelectEvery parameters??

[pantau]

by "xyzresize" you mean just any resizer, like lanczos? what would be the best for downsizing?

[Didée]

You first bob-deinterlace the video, to turn 30 interlaced-frames/sec, which in fact is 60 fields/sec (that's the idea of "interlacing") into 60 full-frames/sec.

Now you can safely resize the resolution. Doing this on separated-fields creates a vertical field offset. You bob beforehand to avoid this issue.

The Separate/select/weave takes the top(bottom) fields from the even(odd) frames of the 60p video, and weaves them back into a 30i video.


Hence:
so is yadif not actually deinterlacing (that is, only separating fields) when using mode 1? It deinterlaces in "double-rate" mode, as described above.

As the video is NTSC, would I have to change the SelectEvery parameters?? No. You must not change anything. Those numbers are "fixed", both regarding frame rate and field order.

by "xyzresize" you mean just any resizer, like lanczos? what would be the best for downsizing?
Yes, basically "any" resizer will do.

The "usual" practice for downsizing to SD is to also apply some vertical lowpass-filter to the result, to avoid line twittering upon playback. However, this is "common", but not a "must".

[pantau]

thanks! I understand that better now... could you just name one of the lowpass-filters you would recommend?

[Didée]

"Low pass filter" is the technical term that sounds good. In practice, this means just "blurring".

Yadif(mode=1)
XyzResize(720,480)
blur(0,0.8).sharpen(0,0.6) # for example
Separate...etc

[pantau]

thanks again... a final question: what's the difference of using mode 1 and mode 3?

[pantau]

let me add one more question (sorry...)

i do this whole downsizing from avid by exporting via quicktime (downsizing within avid is poor). somehow the colors of the clips get "colder" by this process. any idea why this happens? should I just "Tweak" the result in Avisynth?

[Didée]

The difference between mode 1 / 3 in yadif is related to (false) detection of static areas ... it's a quite technical thing. Just leave it at 1.

Can't tell anything about avid and quicktime, sorry. I never use the former, and always avoid the latter. But in any case, if the video that gets into Avisynth has wrong colors, then something is going wrong, obviously. It's not a good idea to have a false/unwanted conversion in the chain, and then make another conversion to compensate for that. You will lose data in that process. Better figure out how to make that avid/quicktime thing behave properly. Or avoid it alltogether.

[sneaker_ger]

Some renderers assume BT.601 colors for SD content and BT.709 for HD.
Try to putting "ColorMatrix(mode="Rec.709->Rec.601")" into your script.

(But like Didée, I have no clue about avid and quicktime.)

[poisondeathray]

Search for "Quicktime gamma shift bug"

(It's not really a "bug" ). Macs and quicktime typically use ~1.8 gamma, rest of the world 2.2 gamma

[pantau]

Some renderers assume BT.601 colors for SD content and BT.709 for HD.
Try to putting "ColorMatrix(mode="Rec.709->Rec.601")" into your script.

(But like Didée, I have no clue about avid and quicktime.)

wow, that did the trick!

i'm not really sure about the "interlaced" parameter; it doesn't seem to have any effect in my case, neither the "clamp" parameter:

ColorMatrix(mode="Rec.709->Rec.601", clamp=false, interlaced=true)

so in my case apparently it was no gamma shift problem.

thank you all!

[sneaker_ger]

If you put Colormatrix() somewhere between Yadif() and Weave(), "interlaced" must be "false" of course.

[pantau]

I had put it the top, just after AssumeTFF()

does it make any difference where i put it, in terms of quality?

[sneaker_ger]

I don't actually know. I'd put it after yadif with interlaced=false just to be sure.
Maybe someone else can provide more info.

[hydra3333]

If you're not tooo fussed about quality, would this do it without the time-cost of deinterlacing ?
# PURE VERSION PER http://forum.doom9.org/showthread.php?p=1185790#post1185790
Global NewHeight=484
Global NewWidth=720
SeparateFields()
Shift = (GetParity() ? -0.25 : 0.25) * (Height()/Float(NewHeight/2)-1.0)
N = Spline36resize(NewWidth, Height())
E = N.SelectEven().Spline36resize(NewWidth, NewHeight/2, 0, Shift)
O = N.SelectOdd( ).Spline36resize(NewWidth, NewHeight/2, 0, -Shift)
Ec = N.SelectEven().Spline36Resize(NewWidth, NewHeight/2, 0, 2*Shift)
Oc = N.SelectOdd( ).Spline36Resize(NewWidth, NewHeight/2, 0, -2*shift)
#N = Lanczos4resize(NewWidth, Height())
#E = N.SelectEven().Lanczos4resize(NewWidth, NewHeight/2, 0, Shift)
#O = N.SelectOdd( ).Lanczos4resize(NewWidth, NewHeight/2, 0, -Shift)
#Ec = N.SelectEven().Lanczos4resize(NewWidth, NewHeight/2, 0, 2*Shift)
#Oc = N.SelectOdd( ).Lanczos4resize(NewWidth, NewHeight/2, 0, -2*shift)
Interleave(E, O)
IsYV12() ? MergeChroma(Interleave(Ec, Oc)) : Last
Weave()
AssumeTFF()
# NOW IT IS RE-SIZED AND STILL INTERLACED
Don't forget colormatrix

Others will know better and comment, but I assume something like this deinterlacing could work at the other end of the quality-worrying scale :)
# For RE-INTERLACING http://forum.doom9.org/showthread.php?p=1110741#post1110741
# AssumeTFF().SeparateFields().SelectEvery(4, 0, 3).Weave() -> TFF
# * AssumeBFF().SeparateFields().SelectEvery(4, 0, 3).Weave() -> BFF
# AssumeTFF().SeparateFields().SelectEvery(4, 1, 2).Weave() -> BFF
# AssumeBFF().SeparateFields().SelectEvery(4, 1, 2).Weave() -> TFF
# DE-INTERLACING and RE-INTERLACING http://forum.doom9.org/showthread.php?p=1374335#post1374335
#QTGMC(Preset="Ultra Fast",EdiThreads=2,Sharpness=1.1,SLMode=1) # result is double framerate progressive, so re-interlate it later
#QTGMC(Preset="Super Fast",EdiThreads=2,Sharpness=1.1,SLMode=1) # result is double framerate progressive, so re-interlate it later
#QTGMC(Preset="Very Fast",EdiThreads=2,Sharpness=1.1,SLMode=1) # result is double framerate progressive, so re-interlate it later
#QTGMC(Preset="Faster",EdiThreads=2,Sharpness=1.1,SLMode=1) # result is double framerate progressive, so re-interlate it later
#QTGMC(Preset="Fast",EdiThreads=2,Sharpness=1.1,SLMode=1) # result is double framerate progressive, so re-interlate it later
#QTGMC(Preset="Medium",EdiThreads=2,Sharpness=1.1,SLMode=1) # result is double framerate progressive, so re-interlate it later
QTGMC(Preset="Slow",EdiThreads=2,Sharpness=1.1,SLMode=1) # result is double framerate progressive, so re-interlate it later
#QTGMC(Preset="Slower",EdiThreads=2,Sharpness=1.1,SLMode=1) # result is double framerate progressive, so re-interlate it later
#QTGMC(Preset="Very Slow",EdiThreads=2,Sharpness=1.1,SLMode=1) # result is double framerate progressive, so re-interlate it later
Spline36resize(720,484)
#Lanczos4resize(720,484)
#LimitedSharpenFaster(smode=4,strength=100)
#UnFilter(10,10)
# Re-Interlace and halve framerate
AssumeTFF()
Blur(0,0.5).SeparateFields().SelectEvery(4,0,3).Weave() #reinterlace - ASSUMED TFF HERE # BLUR(0,1) per http://forum.doom9.org/showthread.php?p=1488308#post1488308

[2Bdecided]

IME there is no point using anything better than bob() when resizing interlaced HD to interlaced SD. The difference isn't visible in the output. If you're targeting 24p/25p/30p/50p/60p instead of 50i/60i, then it can be worth using a better deinterlacer than bob() on the HD source.

The separated fields resizing at the top of the previous post doubles the height of any ringing from the resizer. For that reason, I subjectively don't like what it looks like, and prefer using bob followed by the blur(0.0,1.0).sharpen(0.0,0.5) trick mentioned earlier to soften the image vertically to prevent twitter on interlaced displays (and make deinterlacing on progressive displays a bit easier).

For anamorphic (16x9) SD, there are a few tricks to improve horizontal sharpness. I note that many commercial HD>SD conversions (including all the real time ones I see on UK TV) allow some aliasing in order to give a super-sharp look to the SD.

further approaches:
various:
http://forum.doom9.org/showthread.php?t=139102&page=6
strict filtering:
http://forum.doom9.org/showthread.php?p=1165270#post1165270
"sharpest":
http://forum.doom9.org/showthread.php?t=142682

Cheers,
David.

[Didée]

Yes indeed. A plain bob should be sufficient for most practical cases.
However, using a smart bob-deinterlacer will make a difference in perfectly-static areas. Try:

blankclip(color=$808080,pixel_type="YV12")
subtitle("Testcase",size=32)
a=bob().bicubicresize(320,240).separatefields().selectevery(4,0,3).weave() # result is BFF, no matter the input
b=Yadif(mode=1).bicubicresize(320,240).separatefields().selectevery(4,0,3).weave() # TFF stays TFF, BFF stays BFF
interleave(a,b)

Obviously, the smart-deinterlacing route is sharper, i.e. it keeps more detail in static areas. But then, when you follow-up with a lowpass filter anyway, then the difference will mostly vanish.
And/or: when using a smart bob, you would need a stronger lowpass. Dumb bob can get away with less.

In any case ... when using Avisynth's internal bob filter, always remember that it defaults everything to BFF. If you have a TFF source, you must manually set the correct fieldorder again, before the final separatefields/weave.

[pandy]

Agree with Didée - there is no sense to reinvent wheel - Yadif is anyway better than plain Bob and pretty fast - my point is only that vertical Blur 0.8 is to high - 0.7 should be fine to.

[pantau]

hum... I admit that you're confusing me with your insights... I thought I was actually not deinterlacing (in the sense of turning and interlaced source into a progressive source), but simply separating the fields, downsize, and join the fields again. let me paste my whole script here to be sure I didn't understand thing wrong:

QTInput ("E:\EcoHHH\ecohhh20.mov")

AssumeTFF()
SwapFields()

Load_Stdcall_Plugin("C:\Program Files (x86)\MeGUI 0.3.5\tools\yadif\yadif.dll")

Yadif(mode=1) # bob mode, 25i (30i) becomes 50p (60p)

ColorMatrix(mode="Rec.709->Rec.601", clamp=false, interlaced=false)

LanczosResize(720,486)

blur(0,0.8).sharpen(0,0.6) # for example

Separatefields().SelectEvery(4,0,3).Weave() # re-interlace 50p/60p to 25i/30i

ColorYUV (levels="PC->TV")

ConvertToRGB24()

[ajk]

You are deinterlacing by calling yadif(), and it is the correct way to do this kind of resizing (as explained by Didee in post 14).

[2Bdecided]

Obviously, the smart-deinterlacing route is sharper, i.e. it keeps more detail in static areas.You could say that's a bit of a trick though - neither the input nor the output are acceptable interlaced signals, because they include single pixel transitions that would flicker like mad on CRTs, and would cause havoc with pixel-adaptive deinterlacers (i.e. "decent" LCDs and plasmas) if scrolled across the screen.

This, OTOH, is how it works in real life (IME - YMMV!)...

loadCplugin("C:\Program Files\AviSynth 2.5\selected plugins\yadif.dll")
blankclip(width=1920, height=1080,color=$808080,pixel_type="YV12")
info()
subtitle("Testcase",size=32,align=8)
blur(0.0,1.0).sharpen(0.0,0.5) # the interlaced original isn't pixel-sharp vertically
a=bob(0.0,1.0).bicubicresize(720,576).blur(0.0,1.0).sharpen(0.0,0.5).assumetff().separatefields().selectevery(4,0,3).weave().crop(0,0,0,-240).subtitle("Bob HD input",size=16,align=5) # result is BFF, no matter the input
b=Yadif(mode=1).bicubicresize(720,576).blur(0.0,1.0).sharpen(0.0,0.5).assumetff().separatefields().selectevery(4,0,3).weave().crop(0,0,0,-240).subtitle("Yadif HD input",size=16,align=5) # TFF stays TFF, BFF stays BFF
stackvertical(a,b)
crop(0,0,-120,0)
stackhorizontal(last.subtitle("what it looks like on a progressive display (i.e. weaved)",size=16,align=2),last.Bob().subtitle("what it looks like on an interlaced display (i.e. re-bobbed)",size=16,align=2))


I've tried burning vertically-pixel-sharp interlaced SD to DVD, and watching it on various displays. 1) it's difficult to encode without artefacts. 2) it flickers like mad on CRTs. 3) it breaks up on flat screen displays.

By all means make the extra effort to get that extra sharpness if you want - but it gives you a poorer product at the end IME unless you remove that sharpness again - because interlaced video isn't supposed to be vertically pixel-sharp.

Remember too that Yadif occasionally makes false field matches, giving real weird artefacts. While the extra vertical sharpness of Yadif is invisible if smoothed, and unwanted if not - the artefacts could be perfectly visible in the output.

In any case ... when using Avisynth's internal bob filter, always remember that it defaults everything to BFF. If you have a TFF source, you must manually set the correct fieldorder again, before the final separatefields/weave.I think it's good practice to always include assumetff() before (as part of!) the re-interlacing step anyway, so you know what field order you're passing to your encoder. No need to preserve the original field order when you're destroying the original fields.

Cheers,
David.

[pantau]

You are deinterlacing by calling yadif(), and it is the correct way to do this kind of resizing (as explained by Didee in post 14).

sorry for my ignorance...

but could somebody explain me why it is better to deinterlace? if I resize per field, there shouldn't be any combing, and by avoiding deinterlacing there should be more of the original info present in the resulting clip than by going through the interlace process.

so shouldn't be hydra3333's first suggestion be at least in theory be the best way?

[ajk]

@pantau

The script you asked about uses yadif(), ie. it deinterlaces. You can resize the fields directly too, but that usually gives a visually unpleasant end result, which is why a (smart) bob() type deinterlacer is generally used. Nobody here can tell you what is the best way, you should try different ones and see what works best for you. It depends on the source.

[pantau]

thanks, in fact the script already has brought me to a very superior result compared to downsizing within avid. so I keep testing...

[pandy]

but could somebody explain me why it is better to deinterlace?

http://www.apl.jhu.edu/Notes/Beser/525759/beukershah1994.pdf

[pantau]

thanks, I work through it one day...

http://forum.doom9.org/showthread.php?t=139102 (as pointed to by 2Bdecided) has also a huge amount of info

[2Bdecided]

if I resize per field, there shouldn't be any combingNo, there won't be any combing, but just a dumb separate fields, resize, weave doesn't take account of how the lines in each field line up (or won't actually line up, after you've resized them). For some resizing ratios, the misalignment isn't easily visible, which is why it kind of works. However, that more complicated looking script at the top of hydra3333's post fixes the misalignment.

and by avoiding deinterlacing there should be more of the original info present in the resulting clip than by going through the interlace process.deinterlacing can easily be made lossless - with most methods, you can choose to keep all the original lines when bobbing. The new lines inbetween the original lines are created with some kind of interpolation - depending on which deinterlacer you choose, this could be the exact same interpolation used by a resizer - or it could be more intelligent. So you can lose nothing, and even gain something...

so shouldn't be hydra3333's first suggestion be at least in theory be the best way?It's certainly doing what it's doing properly - but it takes no account of the other field. If you resize, it's obvious that some of the new lines will be at positions (or need data from positions) that were previously filled by lines from the "other" field. Really good bobing/deinterlacing lets you use that information (though I've argued above that it's not needed when you're downscaling HD>SD and the target is interlaced because you already have more than enough information).

The subjective disadvantage I see with it is that you're running the resizer on half resolution images (input and output) - making the effects of the resizer (ringing, aliasing, etc - depends what resizer you pick) doubly obvious. Running the resizer at full res (by bobbing first) makes these things less obvious - and gives you the choice of using data from the other field and/or a better bobber, and/or gives you the opportunity to tune/control/tweak the vertical filtering/bluring of the image before you re-interlace it. You can't do that with separate fields resizing (even when alignment corrected) because you don't any correct "other" field data to work with at the right point in the workflow.

You're not allowed to discuss what's best on doom 9, partly to avoid arguments. But partly because there's rarely one "best" - and that's certainly true here. It depends (at least) on the content and the display.

Cheers,
David.

[pantau]

thanks for that thorough reply... i'm starting to understand things a little bit better now...

by reading through the other thread's i came to notice that i'm actually not squeezing the right way, as LanczosResize(720,486) doesn't give the same pixel aspect ration as 1920x1080, allthough the difference is minimal. should I crop then before resizing?

[2Bdecided]

I'm surprised you're going to 486. (and I'm surprise no one else has questioned this!). What use do you have for it?

704x480 (ITU PAR) and 720x480 (generic PAR) are the most common destinations.

Cheers,
David.

[pantau]

i was preparing output for tv broadcast on betacam

[TheSkiller]

Ah, now we're gettin' deep into the NTSC standard! :D

There are basically two ways to think about it.

1) You just make it rather simple and do it like you would do for ITU compliant (or not compliant) DVD and add 6 black scanlines.
In Avisynth for example:

Resize(704,480)
AddBorders(8,3,8,3) #field order changes!

...and you end up with a valid anamorphic 720x486 NTSC frame that is perfectly correct aspect ratio wise but overall a little smaller than it's supposed to if we take it very seriously.


2) Sticking strictly to the active image in NTSC of 710.85x486 is a bit nasty because the numbers are not as nice.
The theory would look like this:

Resize(711,486)
Addborders(4,0,5,0)


Edit: If you resize from 1920x1080 to 720x486 you have an error of 720/710.85 – ~1.3% too wide, not that bad, but I'm always in for doing it as accurate as possible.

[pantau]

I would actually prefer not to add any black borders, but stay with the whole picture frame. So to avoid the 1.3% distortion, couldn't I rather crop before resizing?

But as far as I understand you, these 9 lines (or 9.25 lines) actually do not show up anywhere? So actually it wouldn't make a difference if they are black or "picture"?

[TheSkiller]

I would actually prefer not to add any black borders, but stay with the whole picture frame. So to avoid the 1.3% distortion, couldn't I rather crop before resizing?Yes, you can do that. Cropping to 1920x1066 will allow resizing straight to 720x486 without borders, still keeping the NTSC aspect ratio.

However,
think of it like this: no matter how you format it (with or without black bars) the viewer will always see a centered window of your 720x486 frame which will be approximately 656x448 (just a good number to calculcate with, some sets show slightly more and some slightly less).

So in return this means that...
But as far as I understand you, these 9 lines (or 9.25 lines) actually do not show up anywhere? So actually it wouldn't make a difference if they are black or "picture"?The only difference it makes to the viewer is that the amount of picture which gets chopped off at the sides due to overscan is increased or decreased, nobody watching it on a TV will ever see the bars.
With an active area of 704x480 the picture is a bit smaller than it is supposed to while with 720x486 + cropping before resize it is bigger than supposed (speaking strictly of NTSC active image area).
The only reason the extra lines (hor and vert) do not show up is overscan, they still count as part of the picture. What exceeds 710.85x486 is redundant.

But in the end the difference is not that big, and which one should be chosen also depends on the content. If you have titles placed rather close to the frame borders it might be preferable to go for 704x480 inside 720x486.

[pantau]

I guess I rather go for the cropping to 1920x1066 and then resizing to 720 x 486, as this is what would be the output directly from Avid for non-DV SD resolutions, so I presume this is what is expected for broadcast delivery, independently of what in the end will be seen of it or not.

[pantau]

But according to my calculations, 1066 wouldn't be right:

1066 / (1920 / 720*1,21) = 483,6975

[TheSkiller]

Hm, I don't know how you calculated that. If I type what you posted in my calculator I get 330.37.

But 1066 is correct:

1920/1066 = 1.801
(720 * (40/33)) / 486 = 1.796

Almost perfect.

Edit: Actually, I was using a PAR of 5760/4739 for my original calculations. If using 40/33 (1.21), like here, there may be a neglectable difference of 1-2 pixel.

[2Bdecided]

This doesn't make much sense to me. An analogue SD broadcast (you still have those?) wouldn't be (anamorphic) widescreen. A digital SD broadcast might be anamorphic widescreen (common in Europe, rare in the USA AFAIK), but wouldn't use those extra lines.

So resizing a 16x9 video to fill 720x486 seems strange. But I know nothing about the American broadcast world!

(but I do know that you haven't had 486 full active video lines since the introduction of closed captioning on line 21. line 21 isn't even the top line (http://www.pembers.freeserve.co.uk/World-TV-Standards/Raster-Top.jpg) so logically you lose line 283 as well (image from here (http://www.pembers.freeserve.co.uk/World-TV-Standards/Line-Standards.html#Vertical)) plus you lose 284 for extended CC/XDS)

Cheers,
David.

[pantau]

Hm, I don't know how you calculated that. If I type what you posted in my calculator I get 330.37.

Sorry, I meant (720*1.21)... but 1.21 was also wrong, as 40/33 is not 1.21

So what is then the real NTSC PAR? 40/33 or 5760/4739?

[pantau]

This doesn't make much sense to me. An analogue SD broadcast (you still have those?) wouldn't be (anamorphic) widescreen. A digital SD broadcast might be anamorphic widescreen (common in Europe, rare in the USA AFAIK), but wouldn't use those extra lines.

In this case delivery was for Brazilian TV, which is NTSC based. But even in Germany I saw and see people deliver 16:9 programs on BetaSP.