Sharpest HDV>DVD workflow?

[2Bdecided]

I'm trying to nail the conversion from HDV>DVD.

I'm happy with most of it, but the thing I can't crack is making the output look really sharp without ringing. Most of the BBC HD content, when shown in SD, has a "super sharp" kind of look to it. I know they're using slightly better cameras, lenses etc ;) - but the problem I have isn't lack of sharpness, it's ringing when I do sharpen.

In this thread...
http://forum.doom9.org/showthread.php?t=140776&page=2
...there was a suggestion to use ImageMagik for re-sizing, but I don't understand how to include this into an AVIsynth workflow.

So far, I'm trying things like this...


# 1440x1080i50 source, bobbed already, so now progressive

# resize:
spline36resize(704,576)

# sharpen horizontally:
limitedsharpenfaster().Sharpen(0.5,0.0)

# prevent interlace twitter:
Blur(0.0,1.0).Sharpen(0.0,0.5)

# re-interlace:
assumetff()
separatefields().SelectEvery(4,0,3).Weave()

...which is sharp, but has ringing. Of course you can remove the Sharpen(0.5,0.0) part, which reduces the ringing, but then it looks soft.


Here an alternative - I think the approach is silly, but it rings slightly less while looking sharper...

# 1440x1080i50 source, bobbed already, so now progressive

# sharpen HD:
limitedsharpenfaster()
limitedsharpenfaster()
limitedsharpenfaster()

# denoise HD:
mc_spuds()

# resize:
spline36resize(704,576)
limitedsharpenfaster()

# prevent interlace twitter:
Blur(0.0,1.0).Sharpen(0.0,0.5)

# re-interlace:
assumetff()
separatefields().SelectEvery(4,0,3).Weave()

...the HD just before resizing looks terrible, but the resized version looks quite nice!


I understand filtering very well, so I know that sharpness, ringing, and aliasing are all trade-offs - however, lsf manages to cheat the compromise between sharpness and ringing up to a point.

The problem with anamorphic 16x9 PAL is that the pixels are so stretched horizontally than any softness or ringing in the horizontal direction is magnified greatly.

Any suggestions?

Cheers,
David.

[2Bdecided]

Here are some images showing:

the original HD
SD without sharpening
SD with lsf+sharpen
SD with lsf four times!

http://rapidshare.de/files/40876150/sharpening.zip.html

Cheers,
David.

[Sagekilla]

Read me: link (http://forum.doom9.org/showthread.php?t=139102)

Rambling:
There was a thread on this problem a while back, I can't remember where but if you do search you'll find it (I have to sift through the posts a bit to find it for you).

I don't remember the details perfectly, but it has to do with the fact that resizing by that huge of a step makes it hard to represent all the details present in the 1920/1440x1080 frame in a 720x480 frame without introducing artifacts. You usually get aliasing or a soft picture. In your case, when you resharpen the soft image to get back that "sharp" look of HD, you end up introducing ringing. I do know that M4G recommended using a FIR filter to filter out frequencies that were too strong (caused aliasing). So you can removing the aliasing + sharpen without ringing if you do that.

I'll look around and link it when I find it.

[2Bdecided]

Sagekilla,

Thanks, but I was in that thread, and other recent ones too. This has come up quite a lot lately.

Most of those discussions were about how to make things sharp in the vertical dimension while avoiding interlaced flicker. I'm quite happy with my results in that respect.

It's the horizontal direction where I want something better. That's why I started a new thread. The H/V resolution discrepancy is worse for "PAL" than for "NTSC" (1.45 PAR instead of 1.21 PAR), which exacerbates the problem.

Cheers,
David.

[*.mp4 guy]

This (http://img142.imageshack.us/img142/9169/lessoversharpsm2.jpg) is the best I could manage, using an absurdly slow script, and oversharpening the source by a karge margin, then using an extremely sharp interpolator. It dowsn't look much sharper then your lsf X4 image unless you view it fullscreen with mpc or something similar, in which case it looks much sharper.

This is a great example of crap in crap out. The source is very blurry, and you can fix this to an extent, but it will never look as good as something that was never blurry.

if you are willing to go well into sub 1fps range to get this source to look sharp, I'll post the script, but I don't want to waste time trying to find all the dependencies etc. when that probably isn't the case.

[2Bdecided]

This (http://img142.imageshack.us/img142/9169/lessoversharpsm2.jpg) is the best I could manage ... It dowsn't look much sharper then your lsf X4 image unless you view it fullscreen with mpc or something similar, in which case it looks much sharper.I think you're being too modest - it looks far sharper - and you've made/faked/brought out lots of extra apparent detail too.

This is a great example of crap in crap out. The source is very blurry, and you can fix this to an extent, but it will never look as good as something that was never blurry.The source isn't too bad - the blurriness is because that's a moving shot. When things aren't moving, it's quite sharp on edges, but really lacking "detail / texture" (typical consumer HDV it seems).

I think tgmc makes it a little softer than with mcbob. Here's the same frame mcbob, and another frame with both...

http://rapidshare.de/files/40878996/sharpening2.zip.html


if you are willing to go well into sub 1fps range to get this source to look sharp, I'll post the script, but I don't want to waste time trying to find all the dependencies etc. when that probably isn't the case.mp4 guy - I'm intrigued.

I almost daren't ask (I've seen your ~1fps sharpening scripts before!) but can you share? Don't worry about unpicking dependencies just yet if it's too painful - just give me a clue what you're doing.

I think your result will be way too sharp vertically for interlaced display, but that's OK - I can easily blur it vertically! It looks a little grainy too, but a little grain might be OK.

It's the fact you've made the SD version look far more detailed than the HD version that's quite amazing.

Cheers,
David.

[*.mp4 guy]

Well, the script itself is pretty regular, its the functions I used.

ImageReader("C:\Documents and Settings\\Desktop\sharpening2\4520mcbob.jpg")
spline36resize(1408, 1152).converttoyv12()# automttap3 works best when resizing by factors of 2, though it can resize by any factor aslong as at no point the image is less then 144*144 pizels
limitedsharpenfaster(smode=2, strength=400, ss_x=1, ss_y=1)#modified to use a different sharpening kernel
sssharp(denoise=0, iter=2)#in the avisynth development forum, absurdly slow sharpener
automttap3(704, 576)#a sub function of an interpolation script, uses backprojection to adaptively choose the number of taps to use on a per source pixel pasis, avoidsmost ringing while otherwise performing similarly to high tap lanczos

sssharp (http://forum.doom9.org/showthread.php?t=132330)

automttap3
function automttap3(clip clp, int "dx", int "dy", int "mtaps3", int "thresh"){

c = clp
#g = clp.converttoy8()

dx = default(dx, c.width*2)
dy = default(dy, c.height*2)
mtaps3 = default(mtaps3, 1)
thresh = default(thresh, 256)

t1 = lanczosresize(clp, dx, dy, taps=1)
t2 = lanczosresize(clp, dx, dy, taps=2)
t3 = lanczosresize(clp, dx, dy, taps=3)
t4 = lanczosresize(clp, dx, dy, taps=4)
t5 = lanczosresize(clp, dx, dy, taps=5)
t6 = lanczosresize(clp, dx, dy, taps=9)
t7 = lanczosresize(clp, dx, dy, taps=36)


m1 = mt_makediff(clp, lanczosresize(t1, clp.width, clp.height, taps=1), u=1, v=1)
m2 = mt_makediff(clp, lanczosresize(t2, clp.width, clp.height, taps=1), u=1, v=1)
m3 = mt_makediff(clp, lanczosresize(t3, clp.width, clp.height, taps=1), u=1, v=1)
m4 = mt_makediff(clp, lanczosresize(t4, clp.width, clp.height, taps=2), u=1, v=1)
m5 = mt_makediff(clp, lanczosresize(t5, clp.width, clp.height, taps=2), u=1, v=1)
m6 = mt_makediff(clp, lanczosresize(t6, clp.width, clp.height, taps=3), u=1, v=1)
m7 = mt_makediff(clp, lanczosresize(t7, clp.width, clp.height, taps=6), u=1, v=1)


cp1 = mt_merge(t1.blur(1.42), t2, lanczosresize(mt_lutxy(m1, m2, "x 128 - abs y 128 - abs - "+string(thresh)+" *", u=1, v=1), dx, dy, taps=mtaps3))
m100 = mt_makediff(clp, bilinearresize(cp1, clp.width, clp.height), u=3, v=3)

cp2 = mt_merge(cp1, t3, lanczosresize(mt_lutxy(m100, m3, "x 128 - abs y 128 - abs - "+string(thresh)+" *", u=1, v=1), dx, dy, taps=mtaps3))
m101 = mt_makediff(clp, bilinearresize(cp2, clp.width, clp.height), u=3, v=3)

cp3 = mt_merge(cp2, t4, lanczosresize(mt_lutxy(m101, m4, "x 128 - abs y 128 - abs - "+string(thresh)+" *", u=1, v=1), dx, dy, taps=mtaps3))
m102 = mt_makediff(clp, bilinearresize(cp3, clp.width, clp.height), u=3, v=3)

cp4 = mt_merge(cp3, t5, lanczosresize(mt_lutxy(m102, m5, "x 128 - abs y 128 - abs - "+string(thresh)+" *", u=1, v=1), dx, dy, taps=mtaps3))
m103 = mt_makediff(clp, bilinearresize(cp4, clp.width, clp.height), u=3, v=3)

cp5 = mt_merge(cp4, t6, lanczosresize(mt_lutxy(m103, m6, "x 128 - abs y 128 - abs - "+string(thresh)+" *", u=1, v=1), dx, dy, taps=mtaps3))
m104 = mt_makediff(clp, bilinearresize(cp5, clp.width, clp.height), u=3, v=3)

cp6 = mt_merge(cp5, t7, lanczosresize(mt_lutxy(m104, m7, "x 128 - abs y 128 - abs - "+string(thresh)+" *", u=1, v=1), dx, dy, taps=mtaps3))
m105 = mt_makediff(clp, bilinearresize(cp6, clp.width, clp.height), u=3, v=3)

return(mergechroma(cp6, spline36resize(clp, dx, dy), 1))}

modified lsf# LimitedSharpen() ( a modded version, 29 Oct 2005 )
#
# A multi-purpose sharpener by Didée
#
#
# Changes in this mod:
#
# - RemoveGrain >= v0.9 IS REQUIRED!!
# ==================================
#
# - Smode=4 / sometimes does the magic ;-)
# - a separate "undershoot" parameter, to allow for some line darkening in comic or Anime
# - Lmode=3 / on edges, limited sharpening with zero OS & US. On not-edges, limited sharpening with specified OS + LS
# - "soft" acts different now: no more boolean true/false, but instead integer 0 - 100 (or -1 -> automatic)
# instead of blurring before finding minima/maxima, it now softens the "effect-of-sharpening"
# - edgemode=-1 now shows the edgemask. (scaling still not implemented :p )
#
## - MODIFIED version using MaskTools 2.0
#modified to use unsharp (from variable blur plugin) for smode2

function LimitedSharpenFaster( clip clp,
\ float "ss_x", float "ss_y", float "vary", float "varc",
\ int "dest_x", int "dest_y",
\ int "Smode" , int "strength", int "radius",
\ int "Lmode", bool "wide", int "overshoot", int "undershoot",
\ int "soft", int "edgemode", bool "special",
\ int "exborder" )
{
ox = clp.width
oy = clp.height



vary = default(vary, 1)
varc = default(varc, vary)
Smode = default( Smode, 3 )
ss_x = (Smode==4)
\ ? default( ss_x, 1.25)
\ : default( ss_x, 1.5 )
ss_y = (Smode==4)
\ ? default( ss_y, 1.25)
\ : default( ss_y, 1.5 )
dest_x = default( dest_x, ox )
dest_y = default( dest_y, oy )
strength = (Smode==1)
\ ? default( strength, 160 )
\ : default( strength, 100 )
strength = (Smode==2&&strength>100) ? 100 : strength
radius = default( radius, 2 )
Lmode = default( Lmode, 1 )
wide = default( wide, false )
overshoot = default( overshoot, 1)
undershoot= default( undershoot, overshoot)
softdec = default( soft, 0 )
soft = softdec!=-1 ? softdec : sqrt( (((ss_x+ss_y)/2.0-1.0)*100.0) ) * 10
soft = soft>100 ? 100 : soft
edgemode = default( edgemode, 0 )
special = default( special, false )
exborder = default( exborder, 0)
#radius = round( radius*(ss_x+ss_y)/2) # If it's you, Mug Funky - feel free to activate it again
xxs=round(ox*ss_x/8)*8
yys=round(oy*ss_y/8)*8
smx=exborder==0?dest_x:round(dest_x/Exborder/4)*4
smy=exborder==0?dest_y:round(dest_y/Exborder/4)*4

clp.isYV12() ? clp : clp.converttoyv12()

ss_x != 1.0 || ss_y != 1.0 ? last.lanczos4Resize(xxs,yys) : last
tmp = last

edge = mt_logic( tmp.mt_edge(thY1=0,thY2=255,"8 16 8 0 0 0 -8 -16 -8 4")
\ ,tmp.mt_edge(thY1=0,thY2=255,"8 0 -8 16 0 -16 8 0 -8 4")
\ ,"max") .mt_lut("x 128 / 0.86 ^ 255 *") #.levels(0,0.86,128,0,255,false)

tmpsoft = tmp.removegrain(11,-1)
dark_limit1 = tmp.mt_inpand()
bright_limit1 = tmp.mt_expand()
dark_limit = (wide==false) ? dark_limit1 : dark_limit1 .removegrain(20,-1).mt_inpand()
bright_limit = (wide==false) ? bright_limit1 : bright_limit1.removegrain(20,-1).mt_expand()
minmaxavg = special==false
\ ? mt_average(dark_limit1, bright_limit1)
\ : mt_merge(dark_limit,bright_limit,tmp.removegrain(11,-1),Y=3,U=-128,V=-128)

dfg = MT_lutxy(last, fq2d("bcl", 256, 0, gamma=1, rescale=false), "y "+string(round(strength/100))+" * 127 + X + 127 -", u=2, v=2).invert

#smode 2 is the modification
Str=string(float(strength)/100.0)
normsharp = Smode==1 ? MT_lutxy(dfg, fq2d(dfg, "bcl", 256, 0, gamma=1, rescale=false), "y "+string(round(strength/100))+" * 127 + X + 127 -", u=2, v=2).invert
\ : Smode==2 ? unsharp(vary=1.5, varc=1.5, strength=1)
\ : Smode==3 ? mt_lutxy(tmp,minmaxavg,yexpr="x x y - "+Str+" * +")
\ : mt_lutxy(tmp,tmpsoft,"x y == x x x y - abs 16 / 1 2 / ^ 16 * "+Str+
\ " * x y - 2 ^ x y - 2 ^ "+Str+" 100 * 25 / + / * x y - x y - abs / * + ?")

OS = string(overshoot)
US = string(undershoot)
mt_lutxy( bright_limit, normsharp, yexpr="y x "+OS+" + < y x y x - "+OS+" - 1 2 / ^ + "+OS+" + ?")
mt_lutxy( dark_limit, last, yexpr="y x "+US+" - > y x x y - "+US+" - 1 2 / ^ - "+US+" - ?")

Lmode==1 ? mt_clamp(normsharp, bright_limit, dark_limit, overshoot, undershoot) : last

normal = last
zero = mt_clamp(normsharp, bright_limit, dark_limit, 0,0)

Lmode==3 ? mt_merge(normal,zero,edge.mt_inflate()) : normal

edgemode==0 ? last
\ : edgemode==1 ? mt_merge(tmp,last,edge.mt_inflate().mt_inflate().removegrain(11,-1),Y=3,U=1,V=1)
\ : mt_merge(last,tmp,edge.mt_inflate().mt_inflate().removegrain(11,-1),Y=3,U=1,V=1)

AMNT = string(soft)
AMNT2 = string(100-soft)
sharpdiff=mt_makediff(tmp,last)
sharpdiff2=mt_lutxy(sharpdiff,sharpdiff.removegrain(19,-1),
\ "x 128 - abs y 128 - abs > y "+AMNT+" * x "+AMNT2+" * + 100 / x ?")

soft==0 ? last : mt_makediff(tmp,sharpdiff2)

(ss_x != 1.0 || ss_y != 1.0)
\ || (dest_x != ox || dest_y != oy) ? lanczos4Resize(dest_x,dest_y) : last

ex=blankclip(last,width=smx,height=smy,color=$FFFFFF).addborders(2,2,2,2).coloryuv(levels="TV->PC")
\.blur(1.3).mt_inpand().blur(1.3).bicubicresize(dest_x,dest_y,1.0,.0)
tmp = clp.lanczos4Resize(dest_x,dest_y)

clp.isYV12() ? ( exborder==0 ? tmp.mergeluma(last)
\ : mt_merge(tmp,last,ex,Y=3,U=1,V=1) )
\ : ( exborder==0 ? tmp.mergeluma(last.converttoyuy2())
\ : tmp.mergeluma( mt_merge(tmp.converttoyv12(),last,ex,Y=3,U=1,V=1)
\ .converttoyuy2()) )

(edgemode!= -1) ? last : edge.lanczos4Resize(dest_x,dest_y).greyscale

return last
}

[2Bdecided]

Ah, super slow sharpen at HD resolutions!

Thank you mp4 guy - that gives me plenty to play with. I reckon about 1 week per minute of video on my PC!

Cheers,
David.

[Adub]

Sweeeeeeeetttt. Now that I am upgrading my comp, and this has been brought back to life, I my just have to break in my new beast with this left-right-left combo.

[scharfis_brain]

try this little detail enhancer:


x1=subtract(source.deen("a2d",5,4,0),source)
result=subtract(source,x1)


5 is spatial radius
4 is luma threshold
0 is chroma threshold (you usually don't want to enhance nonexistent chroma detail, i.e. noise)


this script will only amplify faint detail/textures while leaving edges alone.

[2Bdecided]

Thank you scharfus_brain - I'm sure I'll find a use for that, but the effect of subtracting deen is more subtle than I was looking for in this case.

mp4 guy - I love this script (apart from the speed!).

btw, the modified LSF above crashes on start-up for me, so I'm using my old version for now. The error I'm getting is ": expected at start of line 88" - which is strange, given that there is one! I don't think I have the function unsharp - remind me what that's part of again please?


I need a new PC!

Cheers,
David.

[Gavino]

btw, the modified LSF above crashes on start-up for me, so I'm using my old version for now. The error I'm getting is ": expected at start of line 88" - which is strange, given that there is one!
Remove the comment from the line before.
\ : Smode==2 ? unsharp(vary=1.5, varc=1.5, strength=1)#modification

Comments are not allowed inside a continued line.

EDIT: (Or if using v2.58, change to /* ... */ which I think is allowed)

[kemuri-_9]

Remove the comment from the line before.
\ : Smode==2 ? unsharp(vary=1.5, varc=1.5, strength=1)#modification

Comments are not allowed inside a continued line.

EDIT: (Or if using v2.58, change to /* ... */ which I think is allowed)

/* + */ and [* + *] are fine on continued lines in 2.58.

[halsboss]

I have the same "softening" issue for PAL 1080i25 -> 576i25 DVD. With respect to post #1 and resizing interlaced ... I'd thought this was the quick way to resize without having to bob and still get a reasonable output/speed tradeoff (ignoring sharpening for the moment) ?

AssumeFPS(25)
AssumeTFF()
Global NewHeight=576
Global NewWidth=720
# PURE VERSION PER http://forum.doom9.org/showthread.php?p=1185790#post1185790
SetMTmode(mode=2,threads=4) # mode=2 for temporal multi-threading (interleaved frames)
SeparateFields()
#LimitedSharpenFaster(smode=4,strength=100) # doesn't seem to do much if done here
Shift = (GetParity() ? -0.25 : 0.25) * (Height()/Float(NewHeight/2)-1.0)
E = SelectEven().Spline36resize(NewWidth, NewHeight/2, 0, Shift)
O = SelectOdd( ).Spline36resize(NewWidth, NewHeight/2, 0, -Shift)
Ec = SelectEven().Spline36Resize(NewWidth, NewHeight/2, 0, 2*Shift)
Oc = SelectOdd( ).Spline36Resize(NewWidth, NewHeight/2, 0, -2*shift)
Interleave(E, O)
IsYV12() ? MergeChroma(Interleave(Ec, Oc)) : Last
#LimitedSharpenFaster(smode=4,strength=100) # doesn't seem to do much if done here either
Weave()
Distributor() # use this when using HC and SetMTmode, per http://forum.doom9.org/showthread.php?p=1063622#post1063622





limitedsharpenfaster(smode=2, strength=400, ss_x=1, ss_y=1)#modified to use a different sharpening kernel

Just wondering the reason for a modified kernel ?

[*.mp4 guy]

It's more accurate, and its adjustable (though I didn't code the adjustability into lsf).

[halsboss]

I must be missing something with that new limitedsharpenfaster - as far as I can tell, for smode=2 it

sets vary and varc and doesn't use them (must be preparation for adjustability)
calculates clip dfg and doesn't use it in smode=2
changes smode=1 processing
substitutes unsharp for sharpen in smode=2


Just wondering how to interpret automttap3(704, 576)#a sub function of an interpolation script, uses backprojection to adaptively choose the number of taps to use on a per source pixel pasis, avoidsmost ringing while otherwise performing similarly to high tap lanczos Does that mean it's sharpening as it resizing ?

[*.mp4 guy]

I must be missing something with that new limitedsharpenfaster - as far as I can tell, for smode=2 it

[1]sets vary and varc and doesn't use them (must be preparation for adjustability)
[2]calculates clip dfg and doesn't use it in smode=2
[3]changes smode=1 processing
[4]substitutes unsharp for sharpen in smode=2


[5]Just wondering how to interpret Does that mean it's sharpening as it resizing ?

1 - it uses them, but they are not directly accesable through the lsf funtion, which is what I was saying.
2 - probably an oversight on my part
3 - see 2
4 - this combined with 1 results in a slightly larger, much more accurate sharpening kernel, which produces different results then the sharpen function.

The sharpen function aplieas a simple and inaccurate 3X3 sharpening FIR filter, that uses in total 5 pixels (iirc), the unsharp function, applies an accurate gaussian distribution derived unsharp mask that accurately uses many pixels, even at relatively low radii.

The differences aren't very big, but its one of the versions of lsf that I use, and its what was used to produce the screenshot, so I had to post it when I posted the script.

5 - No.

[halsboss]

OK, thanks. Re 5. would this

function automttap3mod(clip clp, int "dx", int "dy", float "src_left", float "src_top", int "mtaps3", int "thresh"){
# http://forum.doom9.org/showthread.ph...73#post1211873
# automttap3(720, 576)
# a sub function of an interpolation script,
# uses backprojection to adaptively choose the number of taps to use on a per source pixel pasis,
# avoids most ringing while otherwise performing similarly to high tap lanczos.
# modified to be compatible with float src_left, float src_top

c = clp
#g = clp.converttoy8()

dx = default(dx, c.width*2)
dy = default(dy, c.height*2)
src_left = default(src_left, 0.0)
src_top = default(src_top, 0.0)
mtaps3 = default(mtaps3, 1)
thresh = default(thresh, 256)

t1 = lanczosresize(clp, dx, dy, src_left, src_top, taps=1)
t2 = lanczosresize(clp, dx, dy, src_left, src_top, taps=2)
t3 = lanczosresize(clp, dx, dy, src_left, src_top, taps=3)
t4 = lanczosresize(clp, dx, dy, src_left, src_top, taps=4)
t5 = lanczosresize(clp, dx, dy, src_left, src_top, taps=5)
t6 = lanczosresize(clp, dx, dy, src_left, src_top, taps=9)
t7 = lanczosresize(clp, dx, dy, src_left, src_top, taps=36)

m1 = mt_makediff(clp, lanczosresize(t1, clp.width, clp.height, src_left, src_top, taps=1), u=1, v=1)
m2 = mt_makediff(clp, lanczosresize(t2, clp.width, clp.height, src_left, src_top, taps=1), u=1, v=1)
m3 = mt_makediff(clp, lanczosresize(t3, clp.width, clp.height, src_left, src_top, taps=1), u=1, v=1)
m4 = mt_makediff(clp, lanczosresize(t4, clp.width, clp.height, src_left, src_top, taps=2), u=1, v=1)
m5 = mt_makediff(clp, lanczosresize(t5, clp.width, clp.height, src_left, src_top, taps=2), u=1, v=1)
m6 = mt_makediff(clp, lanczosresize(t6, clp.width, clp.height, src_left, src_top, taps=3), u=1, v=1)
m7 = mt_makediff(clp, lanczosresize(t7, clp.width, clp.height, src_left, src_top, taps=6), u=1, v=1)

cp1 = mt_merge(t1.blur(1.42), t2, lanczosresize(mt_lutxy(m1, m2, "x 128 - abs y 128 - abs - "+string(thresh)+" *", u=1, v=1), dx, dy, src_left, src_top, taps=mtaps3))
m100 = mt_makediff(clp, bilinearresize(cp1, clp.width, clp.height, src_left, src_top), u=3, v=3)

cp2 = mt_merge(cp1, t3, lanczosresize(mt_lutxy(m100, m3, "x 128 - abs y 128 - abs - "+string(thresh)+" *", u=1, v=1), dx, dy, src_left, src_top, taps=mtaps3))
m101 = mt_makediff(clp, bilinearresize(cp2, clp.width, clp.height, src_left, src_top), u=3, v=3)

cp3 = mt_merge(cp2, t4, lanczosresize(mt_lutxy(m101, m4, "x 128 - abs y 128 - abs - "+string(thresh)+" *", u=1, v=1), dx, dy, src_left, src_top, taps=mtaps3))
m102 = mt_makediff(clp, bilinearresize(cp3, clp.width, clp.height, src_left, src_top), u=3, v=3)

cp4 = mt_merge(cp3, t5, lanczosresize(mt_lutxy(m102, m5, "x 128 - abs y 128 - abs - "+string(thresh)+" *", u=1, v=1), dx, dy, src_left, src_top, taps=mtaps3))
m103 = mt_makediff(clp, bilinearresize(cp4, clp.width, clp.height, src_left, src_top), u=3, v=3)

cp5 = mt_merge(cp4, t6, lanczosresize(mt_lutxy(m103, m6, "x 128 - abs y 128 - abs - "+string(thresh)+" *", u=1, v=1), dx, dy, src_left, src_top, taps=mtaps3))
m104 = mt_makediff(clp, bilinearresize(cp5, clp.width, clp.height, src_left, src_top), u=3, v=3)

cp6 = mt_merge(cp5, t7, lanczosresize(mt_lutxy(m104, m7, "x 128 - abs y 128 - abs - "+string(thresh)+" *", u=1, v=1), dx, dy, src_left, src_top, taps=mtaps3))
m105 = mt_makediff(clp, bilinearresize(cp6, clp.width, clp.height, src_left, src_top), u=3, v=3)

return(mergechroma(cp6, spline36resize(clp, dx, dy), 1))}
make it more "compatible" with replacing standard calls to a resizer like Spline36 (per post 14), by adding a couple of parameters ? I'm not sure I've added stuff in the right places.

If it doesn't sharpen, is its advantage that it mitigates ringing then or are there other benefits too ?

[halsboss]

Wow. Using that seems to slow post 14 script down from
pass 1 encoding time: 0:00:32 (32.16 s)
fps: 23.3
to
pass 1 encoding time: 0:04:18 (258.01 s)
fps: 2.9

For a footy game, the convert time has gone from ~3h to ~30h :D
The file size has gone up by a few % so it's done something. Now I have 2 .mpv's how can I compare them (it's late and my eyes are going).

[*.mp4 guy]

making the script compatable with crops/pixel shifts is going to be much more complicated then that.

its benefit is that it gives you the interpolative performance of high tap lanczos (wich is very good at eliminating aliasing, and maintaining detail) while greatly reducing the amount of ringing. Unless your source is extremely sharp, and causes other interpolators to leave aliasing behind, or blur detail, then you shouldn't use it.

It was usefull in this case because I had to oversharpen the source so much, many of the lines became extremely (over)sharp and would leave aliasing behind when using other interpolators to downsize the image, in this case automttap3 was usefull, because it could remove the aliasing while maintaing (slightly) better sharpness, which is not something that many filters can do.

The vast majority of images won't cause problems when using normal interpolators to downsize an image, so it is only usefull when your source is tough, or you want every last drop of detail at your final resolution, without worrying about speed.

If you really want to see what it does, take a really sharp, high res image, downsize it with a a regular resizer by 2x, then enlarge by 2x, then compare it to the same procedure, using automttap3 instead.

for your football game, if it was sufficiently high res, and sufficiently sharp, you should be able to see a reduction in aliasing on lines, and extremely fine detail will be preserved a little better.

[2Bdecided]

I have the same "softening" issue for PAL 1080i25 -> 576i25 DVD. With respect to post #1 and resizing interlaced ... I'd thought this was the quick way to resize without having to bob and still get a reasonable output/speed tradeoff (ignoring sharpening for the moment) ?Yes, from this thread...
http://forum.doom9.org/showthread.php?t=139102&highlight=1080i&page=6
...as well as others.

However, it's both ringy and blurred - and there's no progressive image created at any point in the script, so there's nowhere to use a 2-D sharpener.

I'm still playing with mp4 guy's scripts - tweaking is a little slow! I'm hoping to back off the effect a little and speed it up a little at the same time. As it is, it's creating a little ringing (over quite a large distance) to existing sharp edges (there are some!); whitening the edge of the frame; and adding a little too much grain. And taking an eternity, of course!

I'm separately playing with it when the target is 960x540 - currently the sharpened output from my HDV via this script to this resolution (with the spline36 dropped) is a little messy.

Cheers,
David.

[*.mp4 guy]

you cant use the same level of pre sharpening, and use a higher resolution. The entire trick is that all of the sharpened artifacts go away when you downsize the image. You have to aproach things differently if you are aiming for a higher resolution. Also, the spline36 call is imprtant, just set it to double your destination resolution in each dimension. If the "ringing over a large distance" is a problem you may have to use a different downsizer and live with some aliasing.

[2Bdecided]

Thanks mp4 guy. The source was 1440x1080, so was already double the target vertically. I did try spline36 to 1920x1080, but ran out of memory, so ran it directly on 1440x1080 as a compromise.

Thank you for all your help - I might be back with more questions when I've played some more!

Cheers,
David.

[halsboss]

making the script compatable with crops/pixel shifts is going to be much more complicated then that.
Oh. I wonder if you'd got the time to knock it up, or could give some pointers on doing so.
... so it is only usefull when your source is tough, or you want every last drop of detail at your final resolution, without worrying about speed. That describes the cases where my team wins a game. :)

... for your football game, if it was sufficiently high res, and sufficiently sharp, you should be able to see a reduction in aliasing on lines, and extremely fine detail will be preserved a little better. Yes please, that about settles it for being a good thing for some games :D

[*.mp4 guy]

Why exactly do you need crops/pixel shifts anyway? I'm not enitrely sure a sub pixel shift won't cause problems with the backprojection choices, even if its implemented correctly.

[halsboss]

Just taking a lead from the discussion over here http://forum.doom9.org/showthread.php?t=139102&highlight=1080i&page=6 about 1080i->576i via interlaced resizing. If I interpret it right, it deals with peculiarities of chroma sampling.

[halsboss]

*.mp4 guy, incorporated you LSF changes into "lsfmod" as smode=5 and smode=6 ... hope it's right.
# LimitedSharpenFasterMod() ( a modded version, 29 Oct 2005 )
#
# A multi-purpose sharpener by Didée
#
#
# Changes in this mod:
#
# - RemoveGrain >= v0.9 IS REQUIRED!!
# ==================================
#
# - Smode=4 / sometimes does the magic ;-)
# - a separate "undershoot" parameter, to allow for some line darkening in comic or Anime
# - Lmode=3 / on edges, limited sharpening with zero OS & US. On not-edges, limited sharpening with specified OS + LS
# - "soft" acts different now: no more boolean true/false, but instead integer 0 - 100 (or -1 -> automatic)
# instead of blurring before finding minima/maxima, it now softens the "effect-of-sharpening"
# - edgemode=-1 now shows the edgemask. (scaling still not implemented :p )
#
## - MODIFIED version using MaskTools 2.0
#
#2# ALSO per modification by mp4guy in http://forum.doom9.org/showthread.php?p=1211873#post1211873
#2# - changed explicit smode=4 (was a "default" if smode not recognised as one of the others)
#2# - added smode=5 which is mp4guy's modified smode=1
#2# - added smode=6 which is mp4guy's modified smode=2
#2# - unsharp plugin is a part of the variableblur plugin by tsp
#2# http://forum.doom9.org/showthread.php?t=88645&highlight=variable+blur
#2# - F2Quiver <not fq2d> plugin is a part of the FFTQuiver <not FQuiver> plugin by vcmohan
#2# http://avisynth.org/vcmohan
#2# * Hmm, FFTQuiver is a newer version of FQuiver which runs much faster according to vcmohan
#2# FFTQuiver needs FFTw3.dll as does Fizick's fft3dfilter, so most people should have FFTw3.dll anyway
#2# so let's use the newer FFTQuiver instead of fq2d
#2#
#2# If I had any gumption, I'd list the normally required plugins here too. Maybe later.
#2#

function LimitedSharpenFasterMod( clip clp,
\ float "ss_x", float "ss_y",
\ int "dest_x", int "dest_y",
\ int "Smode" , int "strength", int "radius",
\ int "Lmode", bool "wide", int "overshoot", int "undershoot",
\ int "soft", int "edgemode", bool "special",
\ int "exborder",
\ float "vary", float "varc")
{
#2# above, added vary, varc as parameters

ox = clp.width
oy = clp.height

Smode = default( Smode, 3 )
ss_x = (Smode==4)
\ ? default( ss_x, 1.25)
\ : default( ss_x, 1.5 )
ss_y = (Smode==4)
\ ? default( ss_y, 1.25)
\ : default( ss_y, 1.5 )
dest_x = default( dest_x, ox )
dest_y = default( dest_y, oy )
strength = (Smode==1)
\ ? default( strength, 160 )
\ : default( strength, 100 )
strength = (Smode==2&&strength>100) ? 100 : strength
radius = default( radius, 2 )
Lmode = default( Lmode, 1 )
wide = default( wide, false )
overshoot = default( overshoot, 1)
undershoot= default( undershoot, overshoot)
softdec = default( soft, 0 )
soft = softdec!=-1 ? softdec : sqrt( (((ss_x+ss_y)/2.0-1.0)*100.0) ) * 10
soft = soft>100 ? 100 : soft
edgemode = default( edgemode, 0 )
special = default( special, false )
exborder = default( exborder, 0)

#2# added defaults vary, varc
vary = default(vary, 1)
varc = default(varc, vary)
#2# end change

#radius = round( radius*(ss_x+ss_y)/2) # If it's you, Mug Funky - feel free to activate it again
xxs=round(ox*ss_x/8)*8
yys=round(oy*ss_y/8)*8
smx=exborder==0?dest_x:round(dest_x/Exborder/4)*4
smy=exborder==0?dest_y:round(dest_y/Exborder/4)*4

clp.isYV12() ? clp : clp.converttoyv12()

#2# Change lanczosresize to lanczos4resize
#2#ss_x != 1.0 || ss_y != 1.0 ? last.lanczosresize(xxs,yys) : last
ss_x != 1.0 || ss_y != 1.0 ? last.lanczos4resize(xxs,yys) : last
#2# end change
tmp = last

edge = mt_logic( tmp.mt_edge(thY1=0,thY2=255,"8 16 8 0 0 0 -8 -16 -8 4")
\ ,tmp.mt_edge(thY1=0,thY2=255,"8 0 -8 16 0 -16 8 0 -8 4")
\ ,"max") .mt_lut("x 128 / 0.86 ^ 255 *") #.levels(0,0.86,128,0,255,false)

tmpsoft = tmp.removegrain(11,-1)
dark_limit1 = tmp.mt_inpand()
bright_limit1 = tmp.mt_expand()
dark_limit = (wide==false) ? dark_limit1 : dark_limit1 .removegrain(20,-1).mt_inpand()
bright_limit = (wide==false) ? bright_limit1 : bright_limit1.removegrain(20,-1).mt_expand()
minmaxavg = special==false
\ ? mt_average(dark_limit1, bright_limit1)
\ : mt_merge(dark_limit,bright_limit,tmp.removegrain(11,-1),Y=3,U=-128,V=-128)

#2# added calculation of clip dfg ready for mode=5
dfg = Smode==5 ? MT_lutxy(last, F2Quiver("bcl", 256, 0, gamma=1, rescale=false), "y "+string(round(strength/100))+" * 127 + X + 127 -", u=2, v=2).invert : NOP()
#2# end change

Str=string(float(strength)/100.0)
#2# Change Smode processing - comment out old method and insert new below it
#2#normsharp = Smode==1 ? unsharpmask(strength,radius,0)
#2# \ : Smode==2 ? sharpen(float(strength)/100.0)
#2# \ : Smode==3 ? mt_lutxy(tmp,minmaxavg,yexpr="x x y - "+Str+" * +")
#2# \ : mt_lutxy(tmp,tmpsoft,"x y == x x x y - abs 16 / 1 2 / ^ 16 * "+Str+
#2# \ " * x y - 2 ^ x y - 2 ^ "+Str+" 100 * 25 / + / * x y - x y - abs / * + ?")
#2# Still leave the "unknown" at the old Smode=4
normsharp = Smode==1 ? unsharpmask(strength,radius,0)
\ : Smode==2 ? sharpen(float(strength)/100.0)
\ : Smode==3 ? mt_lutxy(tmp,minmaxavg,yexpr="x x y - "+Str+" * +")
\ : Smode==4 ? mt_lutxy(tmp,tmpsoft,"x y == x x x y - abs 16 / 1 2 / ^ 16 * "+Str+" * x y - 2 ^ x y - 2 ^ "+Str+" 100 * 25 / + / * x y - x y - abs / * + ?")
\ : Smode==5 ? MT_lutxy(dfg, F2Quiver(dfg, "bcl", 256, 0, gamma=1, rescale=false), "y "+string(round(strength/100))+" * 127 + X + 127 -", u=2, v=2).invert
\ : Smode==6 ? unsharp(vary=1.5, varc=1.5, strength=1)
\ : mt_lutxy(tmp,tmpsoft,"x y == x x x y - abs 16 / 1 2 / ^ 16 * "+Str+" * x y - 2 ^ x y - 2 ^ "+Str+" 100 * 25 / + / * x y - x y - abs / * + ?")
#2# end change

OS = string(overshoot)
US = string(undershoot)
mt_lutxy( bright_limit, normsharp, yexpr="y x "+OS+" + < y x y x - "+OS+" - 1 2 / ^ + "+OS+" + ?")
mt_lutxy( dark_limit, last, yexpr="y x "+US+" - > y x x y - "+US+" - 1 2 / ^ - "+US+" - ?")

Lmode==1 ? mt_clamp(normsharp, bright_limit, dark_limit, overshoot, undershoot) : last

normal = last
zero = mt_clamp(normsharp, bright_limit, dark_limit, 0,0)

Lmode==3 ? mt_merge(normal,zero,edge.mt_inflate()) : normal

edgemode==0 ? last
\ : edgemode==1 ? mt_merge(tmp,last,edge.mt_inflate().mt_inflate().removegrain(11,-1),Y=3,U=1,V=1)
\ : mt_merge(last,tmp,edge.mt_inflate().mt_inflate().removegrain(11,-1),Y=3,U=1,V=1)

AMNT = string(soft)
AMNT2 = string(100-soft)
sharpdiff=mt_makediff(tmp,last)
sharpdiff2=mt_lutxy(sharpdiff,sharpdiff.removegrain(19,-1),
\ "x 128 - abs y 128 - abs > y "+AMNT+" * x "+AMNT2+" * + 100 / x ?")

soft==0 ? last : mt_makediff(tmp,sharpdiff2)

#2# Change lanczosresize to lanczos4resize
#2# (ss_x != 1.0 || ss_y != 1.0)
#2#\ || (dest_x != ox || dest_y != oy) ? lanczosresize(dest_x,dest_y) : last
(ss_x != 1.0 || ss_y != 1.0) || (dest_x != ox || dest_y != oy) ? lanczos4resize(dest_x,dest_y) : last
#2# end change

ex=blankclip(last,width=smx,height=smy,color=$FFFFFF).addborders(2,2,2,2).coloryuv(levels="TV->PC")
\.blur(1.3).mt_inpand().blur(1.3).bicubicresize(dest_x,dest_y,1.0,.0)
#2# Change lanczosresize to lanczos4resize
#2#tmp = clp.lanczosresize(dest_x,dest_y)
tmp = clp.lanczos4resize(dest_x,dest_y)
#2# end change

clp.isYV12() ? ( exborder==0 ? tmp.mergeluma(last)
\ : mt_merge(tmp,last,ex,Y=3,U=1,V=1) )
\ : ( exborder==0 ? tmp.mergeluma(last.converttoyuy2())
\ : tmp.mergeluma( mt_merge(tmp.converttoyv12(),last,ex,Y=3,U=1,V=1)
\ .converttoyuy2()) )

#2# Change lanczosresize to lanczos4resize
#2#(edgemode!= -1) ? last : edge.lanczosresize(dest_x,dest_y).greyscale
(edgemode!= -1) ? last : edge.lanczos4resize(dest_x,dest_y).greyscale
#2# end change

return last
}

[halsboss]

Darn. Just spotted this thread LSFmod [v1.1 - Update 2008/11/14] (http://forum.doom9.org/showthread.php?t=142706). I'll go over there and see what it does by way of comparison.


Edit: there seems to be a bit of debate going on over there, and the modes aren't 1:1 with the old LSF... I think I'll stick with the old smode=4 and smode=6 above (your modded smode=2) for the time being.

[halsboss]

I know these images aren't quite the same, aspect ratio and size wise, and that there's probably much else happening, but - these 2 images seem to show that Vdub has done "something good" in the resize stakes. Why does the Vdub image appear much crisper and less noisy than the avisynth down-sized image ? Is Vdub doing something special ? :confused:

What the images are -
1. the source http://rapidshare.com/files/166173220/vdub50pct.png (1.7Mb) is a screen capture (control-prtscrn) from vdub and pasted into irfanview and saved where the source output view switched on and set to resized to 50% (and to 4:3) ... the original "shown at 50%" from is 1080i (see edit 2 below)

2. that 1080i source poked through the interlaced-resizing method in post 14 into HCenc set at fox1 matrix @ 9200k http://rapidshare.com/files/166173219/spline36.png (1.2Mb) then opened with Vdub and "copy source frame to clipboard" and pasted into irfanview and saved.

Yes, I know they're different methods of saving but they do look like that on my screen. Check out the detail of the bike and the 2 girls at front.

And the vdub shrunk image is much crisper and cleaner. What is Vdub doing, that it can shrink and display it at much apparent better visual quality than through that on post 14 ? Unless my eyes are shot (it's possible) and you think the HC pic is cleaner - feedback welcomed.

If I could get a resizing result like vdub's "show at 50%" display via AVIsynth then I'd be a very very happy chappy. :D

edit 1: I'll try to open the avisynth resizing script in vdub to mitigate any HCenc "processing" and post that too.

edit 2: Source frame at full size (from vdub, via menu Video, Copy frame to clipboard) http://rapidshare.com/files/166178254/SourceFrame.png (6Mb).
Frame from Vdub directly from the AVS http://rapidshare.com/files/166178556/spline36-from-avs-into-vdub.png (1.2Mb)

edit 3: comparing http://rapidshare.com/files/166173220/vdub50pct.png and http://rapidshare.com/files/166178556/spline36-from-avs-into-vdub.png seem to indicate it's the means of resizing rather than HC

[*.mp4 guy]

1 - post an unresized source frame and your script
2 - you implemented smode 6 correctly, smode 5 shoudn't be there. I have no idea what it does.

[halsboss]

OK.

1. http://rapidshare.com/files/166202206/NICE-1080i-couple-of-frames.mpg (2.5Mb) is a second's worth of the 1080i clipped using VideoReDo
2. smode=5 is hopefully your smode=1 per post #7 (which is different to what I had in what I thought to be the standard LSF MT2) using the newer F2Quiver rather than fq2d. If it's not recognizable then it's probably worth removing :)


Interestingly, MediaPlayerClassic with that clip and right-click "video frame" "half size" and pause on the relvant frame, seems to give a result with apparent clarity "about halfway" between the avisynth resize per that spline36 .png and the Vdub "50%" ... I wonder how it resizes ?

The more you compare the bike and bike-rack in the pics, the more noticeable it really is that the Vdub internal resizing to 50% for display of the input frame seems to be doing a superb job @ good speeds. There's got to be a catch and I really must be missing something.

[*.mp4 guy]

You are doing something wrong.

pointresize (http://img253.imageshack.us/my.php?image=thisty2.png)
spline36resize (http://img122.imageshack.us/my.php?image=thatur3.png)

[halsboss]

Wow, I sure must be. Yours is much sharper and even the right aspect ratio.

Your spline36 - http://rapidshare.com/files/166248204/spline36-mp4guy-thatur3.png
Your pointresize - http://rapidshare.com/files/166248205/pointresize-mp4guy-thisty2.png
Mine from "copy source frame to clipboard" in vdub) :- http://rapidshare.com/files/166247278/spline36-mine.png
Vdub "view at 50%" of original 1080i - http://rapidshare.com/files/166252532/vdub50pct-sameframe.png

SetMemoryMax(512)
LoadPlugin("C:\SOFTWARE\DGindex\DGDecode.dll")

MPEG2Source("G:\HDTV\1\gif\NICE-1080i-couple-of-frames.d2v",info=0,ipp=true,cpu=6)
#MPEG2Source("G:\HDTV\1\gif\NICE-1080i-couple-of-frames.d2v",info=0,ipp=true,cpu=4)
#MPEG2Source("G:\HDTV\1\gif\NICE-1080i-couple-of-frames.d2v",info=0,ipp=true)
AssumeFPS(25)
AssumeTFF()
# -------------------------------------------------------------------------------------
# PURE VERSION PER http://forum.doom9.org/showthread.php?p=1185790#post1185790
# -------------------------------------------------------------------------------------
Global NewHeight=576
Global NewWidth=720
SeparateFields()
Shift = (GetParity() ? -0.25 : 0.25) * (Height()/Float(NewHeight/2)-1.0)
LL = LAST
sE = LL.SelectEven().Spline36resize(NewWidth, NewHeight/2, 0, Shift)
sO = LL.SelectOdd( ).Spline36resize(NewWidth, NewHeight/2, 0, -Shift)
sEc = LL.SelectEven().Spline36Resize(NewWidth, NewHeight/2, 0, 2*Shift)
sOc = LL.SelectOdd( ).Spline36Resize(NewWidth, NewHeight/2, 0, -2*shift)
s=Interleave(sE, sO)
s = IsYV12() ? s.MergeChroma(Interleave(sEc, sOc)) : s
s = s.Weave()
s.ScriptClip("""subtitle("spline36 Frame " + string(current_frame),size=25)""")
#Converttoyv12(interlaced=true)
#SetPlanarLegacyAlignment(True)

May I enquire as to your script ?

[*.mp4 guy]

mpeg2source("file")
spline36resize(960, 540)

The source is progressive, why the complex interlaced script.

[halsboss]

I've done something very wrong and don't know how or why. The original source clip was 1080i interlaced and only every chopped up with VideoReDo... the issue for me was how to get the best out of interlaced resizing.

Hang on, here's the log from DGIndex which I'd thought meant it was interlaced :-
Stream Type: MPEG2 Program
Profile: main@high
Frame Size: 1920x1080
Display Size: 1920x1080
Aspect Ratio: 16:9 [3]
Frame Rate: 25.000000 fps
Video Type: PAL
Frame Type: Interlaced
Coding Type: B
Colorimetry: SMPTE 240M
Frame Structure: Frame
Field Order:
Coded Number: 31
Playback Number: 2
Frame Repeats: 0
Field Repeats: 0
VOB ID:
Cell ID:
Bitrate:
Bitrate (Avg):
Bitrate (Max):
Audio Stream: 80: AC3 2/0 384
Timestamp: 0:00:01
Elapsed: 0:00:00
Remain: FINISH
FPS:
Info:

[um3k]

What camera was it recorded with?

[halsboss]

Hm, dgindex is nice and crisp in it's 1/2 size display too. Funny. Not sure about the camera, this was a follow on about the sub-topic of sharpening whilst shrinking and the clip is a TV capture (legal in Aus for timeshifted viewing, and of relevance to others trying to shrink/sharpen interlaced material per the OP).

[halsboss]

Ran a few tests and it seems for DGIndex
Frame Type: Interlaced can contain Coding Type: B Coding Type: I Coding Type: P
and for this particular clip it's P which I suppose means it must be progressive.

Darn it, you can forget all that's gone before in that case. And I'll need to find a real "I" clip to try these things on.

Sorry about that people ... broadcast 1080i isn't 1080i after all, sometimes it's progressive etc.

Nice catch, *.mp4 guy so thankyou for that insight.

[Leak]

Hang on, here's the log from DGIndex which I'd thought meant it was interlaced:
Just because it says "interlaced" (which means the video was treated as if it had been interlaced when encoding) doesn't mean it can't be perfectly progressive - and in fact the MPG you posted above is...

Don't trust any flags, just watch it in VirtualDub (with the MPEG2 plugin) or DGIndex and look for combing - if there is none, it obviously isn't interlaced...

np: B. Fleischmann - A Letter From Home (Welcome Tourist (Disc 1))

[*.mp4 guy]

If you have HD interlaced content, and are format shifting to SD, there is no good reason to keep it interlaced, unless your stuck in the past, technologically.

[halsboss]

Thankyou, I learned something at some cost, here. I had scripts to convert things on the assumption that 1080i was in fact 1080i. Pity about that, thers' no auto way to tell by the looks. http://www.mod16.org/hurfdurf/?p=12 gives some info on the sad state of affairs of how studios do things.

If you have HD interlaced content, and are format shifting to SD, there is no good reason to keep it interlaced, unless your stuck in the past, technologically. Yes, that'd be me I guess. I recall somewhere from in this forum that keeping 25i interlaced as 25i interlaced retained some sort of perception of fluidity of motion as compared to 25p (remembering the target is DVD) especially for fast-moving sports action. For converting from a camera (the OP query) is that true in your view and hence does that also apply to this case ?

[*.mp4 guy]

It can help, but its a matter of taste. There are very few cases where I would sacrifice more then half of my vertical resolution (interlacing creates aliasing, which you can't easily get rid of, even by aggressively blurring the picture) to get better fluidity, but I don't watch sports.

Though to be clear, dvd is a technologically limiting factor, otherwise you could use 50p/60p instead of this interlaced nonsense.

[halsboss]

Thanks. OK, I'll try "p" and compare to "i" from as proper 1080i source with fast sports the action to get a subjective take on it. I wish DVD players played 50p. :)

edit: I wonder if some of the newer cheapie DVD players DO play 50p since some also play divx and whatnot ? It's offtopic, so where to post that query I wonder

[*.mp4 guy]

There is a hardware players forum here.

[um3k]

HD DVD players will play nonstandard 50p and 60p DVDs. It's a little tricky to author them, though.

[scharfis_brain]

is this documented somewhere?

[2Bdecided]

If you have HD interlaced content, and are format shifting to SD, there is no good reason to keep it interlaced, unless your stuck in the past, technologically.We don't all like the stuttery fake film look of 25 images per second - some of us actually like the video look of 50 images per second!

Resolution isn't everything. I can get 7fps at 10Mpixel from a DSLR - great resolution - but it's not video! ;)


Of course if the 1080i is really 1080p-wrapped-in-1080i then of course it should be treated as progressive.

btw halsboss: I, B and P are types of MPEG frame - any primer on compressed video will explain them to you - they have nothing to do with interlacing (or lack of it).

The relevant encoding mode of MPEG video (i.e. specifically flagged interlaced or progressive) tells you nothing about the actual content - I wouldn't even bother checking it, I'd just look at the content! MPEG "Interlaced" mode can use interlaced or progressive DCTs, MPEG "Progressive" mode cannot use interlaced DCTs. It's no wonder TV stations send everything out in MPEG interlaced mode - it does almost no harm to encode progressive content this way (except for the chroma encoding).

(These comments are for "PAL" countries, like yours and mine. In "NTSC" countries hard telecine as a way of encoding progressive content in an interlaced stream is obviously an abomination in an MPEG stream in terms of quality and efficiency - there correct progressive encoding is essential - but still rarely done by TV stations!).

Cheers,
David.

[*.mp4 guy]

@2Bdecided

...Er what? The post you quoted was advocating using a non interlaced format, at full 50/60 framerate, when you have a reason to downsize from interlaced HD to a resolution that will allow you to effectively remove all interlacing artifacts. I never said anything about the merits of 25P vs. 50I; I was proposing the third option: non bastardized resolution, non bastardized framerate.

This is the digital age, I can have my cake, and eat it as often as I want.

[Sagekilla]

@M4G: Unfortunately we have to jump through numerous loops of fire and barbed wire traps before we can get to said cake in certain circumstances :(

[2Bdecided]

Exactly - anyway, you did clearly say SD. 50p is not SD! At least, not on my TV, DVB, or DVD devices!

Where I have the luxury of 50p, I also have the luxury of HD, so wouldn't be targeting 704x576.


EDIT: I suppose I should have expected it, but the problem with a much sharper source is it's much harder to encode! Still playing though...

Cheers,
David.