Sharpest HDV>DVD workflow?

[halsboss]

Of course if the 1080i is really 1080p-wrapped-in-1080i then of course it should be treated as progressive. ... 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!

Thankyou, neuron2 is very kindly and patiently explaining this in the DVD2AVI/DGIndex forum and how to spot the various kinds - now I understand what field-shifted progressive in an interlaced frame is and how to spot it (I think).

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).
Ah, this is what I have been wondering: a question - when an OTA broadcast is in 1080i (or supposing, say, a hdv camera manufacturer chooses to do silly things -like TV broadcasters- inside 1080i sometime in the future, to be on-topic) then the actual content can be just about anything - but it must fit within an 1080i interlaced frame ... and hence the "content" cannot be 50p since it needs to fit into 50i specs of 25 "interlaced" frames per sec (50 fields per sec if indeed it is really interlaced) in that context ??

[2Bdecided]

Correct - 1080i50 cannot contain 50 progressive images per second. It can contain 25 progressive images per second.

There's always 720p50 for that. And I'm sure we'll see 1080p50 camcorders (not HDV of course) sooner or later.

I don't think we'll see 1080p50 from broadcasters (for a long time, if ever).

Cheers,
David.

P.S. The Canon HV20 does 1080p25-wrapped-in-1080i50. It's a very common format.

[um3k]

is this documented somewhere?

If you're replying to my post, look here: http://eugenia.gnomefiles.org/2008/02/19/creating-an-hd-disc-in-plain-dvds-for-free/

[2Bdecided]

Here's an idea that's nowhere near as good as mp4_guy's script, but it's very fast...

# start with progressive source, 1440x1080 in my case

spline36resize(880,1080)
spline36resize(1408,1080)
sharpen(1.0)
spline36resize(1408,576)
pointresize(704,576)

# preventing twittering on interlaced displays:
blur(0.0,1.0)
sharpen(0.0,0.5)

# re-interlace:
assumetff()
separatefields()
selectevery(4,0,3)
weave()


Nothing clever - it just does this:
Horizontally:
1. filters some of the high frequencies (but not enough to remove all aliasing) with the first resize
2. performs a simple sharpen(1.0) at double the resolution
3. does a point resize down to the require resolution, so maintaining some of the aliasing from step 1
Vertically:
4. does a blur-then-sharpen to stop twittering on interlaced displays

(I tried doing the same tricks vertically that I'm doing horizontally, but it doesn't work as well.)

Sadly, a simple spline36resize(704,576).limitedsharpenfaster() encodes much more nicely, even though (because!) it's slightly softer and more ringy.


I haven't managed to figure out how to speed up mp4_guy's script while maintaining enough of the quality to keep me happy. It's a shame, because I'm throwing a lot of it away by having to blur the result vertically before re-interlacing.

Cheers,
David.

[Gavino]

spline36resize(880,1080)
spline36resize(1408,1080)
sharpen(1.0)
...
Horizontally:
2. performs a simple sharpen(1.0) at double the resolution
Vertically:
4. does a blur-then-sharpen to stop twittering on interlaced displays

Would sharpen(1.0, 0.0) be better at this point or does it not matter?

[2Bdecided]

TBH I didn't compare. sharpen(1.0) made sense before I added step 4 ;) , and was necessary when I was trying to do something clever vertically too, but I think you're right.

Cheers,
David.

[PALpilot]

Why do you deinterlace if half the vertical resolution is allmost equal to SD. I'd use something like:

MPEG2Source("1080i_source.d2v")
SeparateFields()
SelectEven()
Spline36Resize(720,576)

For PAL you'll loose some quality by upsizing 540 to 576. With NTSC it's even sort of lossless.

[*.mp4 guy]

Deinterlacing by throwing aways half the fields is the same as taking a picture and pointresizing it down to half its vertical resolution. to be more clear, it creates lots of aliasing. One of the main goals of a deinterlacer is to remove this aliasing.

[halsboss]

Why do you deinterlace if half the vertical resolution is allmost equal to SD. I'd use something like: ... snipped ...

For PAL you'll lo-se some quality by upsizing 540 to 576. With NTSC it's even sort of lossless.

Here's a quickish-by-comparison-to-deinterlaced-resizing script http://forum.doom9.org/showthread.php?p=1215354#post1215354 which isn't as good as deinterlaced resizing but is better than a throw-away-stuff script

Here's the thread why http://forum.doom9.org/showthread.php?p=1185790#post1185790

[PALpilot]

Thank you both. I'll look into it and do some testing.

[2Bdecided]

Why do you deinterlace if half the vertical resolution is allmost equal to SD. I'd use something like:

MPEG2Source("1080i_source.d2v")
SeparateFields()
SelectEven()
Spline36Resize(720,576)

For PAL you'll loose some quality by upsizing 540 to 576. With NTSC it's even sort of lossless.But you've just halved the temporal resolution by throwing every other field away!

We had this discussion earlier in the thread.

Cheers,
David.

[Gavino]

Deinterlacing by throwing aways half the fields is the same as taking a picture and pointresizing it down to half its vertical resolution. to be more clear, it creates lots of aliasing.
Either this is wrong, or you're explaining it badly. After SeparateFields, how can throwing away some frames create aliasing in the ones that are left behind?

Do you mean SeparateFields itself creates aliasing?
Wouldn't that depend on how the original fields were sampled?

Your underlying point may be right, but I'd like to understand it better.

[Leak]

Either this is wrong, or you're explaining it badly. After SeparateFields, how can throwing away some frames create aliasing in the ones that are left behind?
Any non-moving part in the image will lose half it's resolution due to SeparateField-ing. While the interlaced fields come from different points in time, the lines in the fields are still interwoven spatially - that's why deinterlacers try to find static parts and leave them untouched...

np: B. Fleischmann - Sleep (Welcome Tourist (Disc 1))

[Gavino]

Any non-moving part in the image will lose half it's resolution due to SeparateField-ing.
Yes, sure. My question was: Does this necessarily lead to aliasing?

Would that not depend on how the original interlaced image was created? If you take a DV capture and separate the fields, will you see aliasing? (I don't know, I'm just asking.)

[Mug Funky]

here's something i just tested on some sony f900 footage:

lanczosresize(720*2,576*2)
pointresize(720,576)

it's pretty sharp... not hugely aliased, but it will increase noise necessarily.

edges wont ring though. and you could probably use some edgemasking to merge in a properly sampled version of the non-edge areas to keep noise and aliasing only to the edges.

[edit]

actually, lanczosing straight to 720 width will help horizontal aliasing, as that could become a problem. if only the vertical is aliased, it will resemble what telecine transfers looked like before "Scan'dal" was introduced (ie. the spot that was scanned missed about 50% of the film area in the space between scanlines).

btw, the BBC are probably just using the SDI outputs of their HD decks. i can't imagine them using anything too fancy for downrezzing, unless they've got some crazy hardware box (snell and wilcox make a very fancy box for cross-converting everything to everything)

[edit edit]

bah. i should have read the entire thread :) my apologies

[Leak]

Yes, sure. My question was: Does this necessarily lead to aliasing?
Of course. Just halve the height of any image with point resizing, which does simply throw out every other line, and you'll get aliasing galore.

Take a high-contrast diagonal from an image, like this:

http://img237.imageshack.us/img237/2984/diag1fp6.png

The edge will have a smooth gradient along it's edge.

Now throw away ever other line:

http://img135.imageshack.us/img135/3949/diag2yd8.png

As you can see, some of the gradient that made the diagonal smooth is now totally missing.

On the other hand, linear interpolation would have given you this:

http://img146.imageshack.us/img146/95/diag3dw1.png

[2Bdecided]

Yes, sure. My question was: Does this necessarily lead to aliasing?Yes, and on typical video, it's far worse than Leak's artificial example, and looks very strange when things start to move.

It depends what you're aiming for though - I have no worries doing it this way for YouTube! 1080 > 540 > 480 > "really bad compression" isn't a situation where the deinterlacing is at all important.

(Denoising might be though, and careful deinterlacing and resizing might have more of an implicit denoising effect than the drop fields bodge)

Cheers,
David.

[Gavino]

Thanks for your replies, Leak and David.
Let me try and explain what lies behind my question.

Clearly, point-downsizing an arbitrary image can introduce aliasing, because the Nyquist limit is correspondingly lower.
But in the case of SeparateFields, you are simply recovering the original fields as captured by the camera.
Do these have aliasing?.

My confusion comes from having only a hazy understanding of how digital cameras actually do their sampling, especially when interlacing. Don't they incorporate an appropriate anti-aliasing (low-pass) filter, as found for example in an audio sampler?
(If not, then do all images potentially include aliasing?)

[2Bdecided]

You can't say what "all" cameras do, since all are different.

Certainly most HD cameras have usable information above that which 540-lines can accommodate, but less than 1080-lines can accommodate. So there will be some aliasing. Optical filtering (which is all you will find in current consumer HD cameras, since none are oversampled) isn't that accurate anyway.

If you did filter an interlaced image so that there was only 540-lines of vertical resolution, you might as well capture 540p as opposed to 1080i!


To look at it another way - a camera sensor doesn't have a pixel grid which captures fields - it has a pixel grid which captures frames, but ignores half the lines on each pass.

Cheers,
David.

[2Bdecided]

It probably won't get approved for a while, but I've attached an image straight from my HV20 in 1440x1080 50i mode.

1= crop from original frame.

2= downsampled properly (bicubic), upsampled properly (bicubic).

3= downsampled by dropping alternate lines (point resize or separate fields), upsampled properly (bicubic).

You can clearly see the aliasing in 3.

Cheers,
David.

[Leak]

But in the case of SeparateFields, you are simply recovering the original fields as captured by the camera.
Do these have aliasing?.
But of course - like I said, both fields are from a different point in time, but because the lines of one field lie between the lines of the other field (i.e one field's lines are offset by half a line vs. the other field's lines) a static, interlaced image has the same resolution as a progressive one. And of course throwing away half of that resolution causes the same aliasing as would doing the same on a purely progressive image.

If anything, SeparateFields recovers the temporal resolution of the video, but no the spacial one. That's what sophisticated deinterlacers (at the expense of temporal resolution) or bobbers (at a minimal overall resolution expense) do.

[LaTo]

@2Bdecided:

If speed is a problem, you can also try this:

function SSSharpFaster(clip c, float "strength", int "hthr", int "hbias")
{
hthr = default(hthr, 256)
hbias = default(hbias, -128)
strength = default(strength, 6.0)

w = c.width()
h = c.height()

s = c.spline36resize(w*2,h*2)
a = s.awarpsharp(cm=0, depth=3, blurlevel=1, thresh=0.99)

Mblur = s.removegrain(4 ,-1)
Gblur = s.removegrain(19,-1)
Hmask = mt_lutxy(Mblur, Gblur, "y x - abs "+string(hthr)+" * "+string(hbias)+" +", U=1, V=1)

MT_merge(mt_lutxy(s, Gblur, yexpr="x x y - "+string(strength)+ " * +",U=1,V=1),
\ mt_lutxy(s, a, yexpr="x y x - "+string(strength/3.0)+" * +",U=1,V=1),
\ Hmask,
\ U=1,V=1)

spline36resize(w,h).mergechroma(c)

return(last)
}

If you follow the same script as *.mp4 guy, replace:
sssharp(denoise=0, iter=2) #in the avisynth development forum, absurdly slow sharpener

by
sssharpfaster().sssharpfaster() # 2 times because iter=2

I got more or less the same result (less accurate), but much faster (0.5fps vs 3fps) ;)

Screenshot:

SSsharp(denoise=0, iter=2) (http://img155.imageshack.us/img155/1342/sourcemi9.jpg)
SSsharpFaster().SSsharpFaster() (http://img185.imageshack.us/img185/7307/sssharpfasterfx9.jpg)

[Gavino]

Certainly most HD cameras have usable information above that which 540-lines can accommodate, but less than 1080-lines can accommodate. So there will be some aliasing. Optical filtering (which is all you will find in current consumer HD cameras, since none are oversampled) isn't that accurate anyway.

If you did filter an interlaced image so that there was only 540-lines of vertical resolution, you might as well capture 540p as opposed to 1080i!

To look at it another way - a camera sensor doesn't have a pixel grid which captures fields - it has a pixel grid which captures frames, but ignores half the lines on each pass.
Thanks for the explanation, and the example pics. I understand better now.

It does seem though that at least some (older?) cameras do capture fields at the lower resolution by combining scanlines, effectively doing a vertical blur. ("Dual-row scanning" - see this article (http://www.adamwilt.com/TechDiffs/FieldsAndFrames.html).)

EDIT: See also this post.

[Mug Funky]

the CCD thing is quite interesting.

generally a camera sensor incorporates an optical lowpass filter coating on top of the CCD, just before the bayer-pattern of colour filters. this would certainly reduce aliasing, but not eliminate it (as it's an optical filter, with probably a much gentler rolloff than a digital filter would have).

typically the sensor will capture full vertical resolution, but will expose and offload even and odd lines at different times. while the top field is being exposed, the bottom field is being read out to memory and vice-versa on the next field. this means slower (cheaper) sensors can be used in 1080@50i but effectively work at 25Hz.

[PALpilot]

Also thanks a lot for all the explaining.
It clears a lot of issues.

[SilaSurfer]

Sorry to bring this thread back into discussion. Mp4guy I am very impressed by autoMTtap3 function for downsizing 1080p to SD resoulution but it is extremly slow, 1.32fps on my system.

Spline36resize(width*0.5,height*0.5)
automttap3(final resolution)

Could it be somehow optimised or do you have some newer function in your cook book?

[*.mp4 guy]

I have new functions, but it is unlikely they are significantly faster (never checked). Additionally they were designed with slightly different goals so, they probably don't do precisely what you want.