Interlacers - high quality

[xerces8]

Hi!

Are there any (high quality) interlacing programs (scripts, algorithms) available?
(besides the trivial "drop every second line", of course)

I mean a "box" that takes progressive video as input and "spits out" interlaced video as output.

It is for some research I will be doing (private).

Regards,
David

[7ekno]

Avisynth:

AssumeTFF()
SeparateFields()

?

Hope you are able to research your research better than Interlacing ;)

7ek

[manono]

SeparateFields()
Trim(1,0)
Weave()

[xerces8]

Thanks, but:
- SeparateFields assumes the input is already interlaced, just packed into frames

What I search for is something that takes for example 60p and outputs 60i.

- Weave is the opposite of interlacing.
- Trim(1,0) just drops the first field of the clip. (according to the wiki)

[manono]

You said you wanted to interlace a progressive video. If you'd stop writing gibberish and try that simple script you'd see that's exactly what it does.

If by 60i you mean 30 interlaced frames per second, then:

AssumeTFF()
SeparateFields()
SelectEvery(4,0,3)
Weave()

And if that's what you meant, then you should have said so to begin with. You said nothing about changing the framerate.

[xerces8]

Because I did not want to change the framerate.
That idea was suggested by others.

What I want is written in the first post quite nicely.

I also repeat one part that obviously nobody read:

(besides the trivial "drop every second line", of course)


Every programmer can write a program to drop every second line in a minute.

Now, can we please start over?

Maybe with an example:

I have a 10 second progressive video with 60 FPS.
That means (in case I wrote gibberish again) every 16.667 ms a picture of the subject is taken. 600 in total.

Now I want to broadcast the footage over TV (20-30 years back in time, when 60 fields per second interlace was the only option).

So how do convert the data (read: convert, not rearrange. The output must be a sequence of fields) ?
Besides method 1 "Drop every second line in each frame" (alternating between even and odd lines, obviously).

So what would be method 2 (and 3 etc.) ?

[manono]

Nope, none of your posts until the most recent one were the least bit clear. And if you had fooled around with the script yourself you could have figured it out for yourself. What do you think a field is but every other scan line of a frame? Take my last script and leave out the last line and then see if it's what you had in mind:

AssumeTFF()
SeparateFields()
SelectEvery(4,0,3)

Until you change the rules again next time.

[xerces8]

Nope, I wont change anything, I will just repeat the same thing for the third time: I already know the method of dropping half and retaining the other half as is. (It is trivial and obvious. Everyone knows it.)

If there is no other method you know, then let's just wait for someone who does. Deal?

[manono]

Sure thing. Good luck.

[Blue_MiSfit]

Take a look here:
http://svt.se/content/1/c8/02/02/85/31/svt_multiformat_v10.pdf

Specifically the part that has to do with how their 2164p50 sequence was interlaced to 1080i50

5.5. Interlacing
To aid the interlacing process a basic raster of 2164 lines (3840x2164p/50) was used as input.

For interlacing, every second 2164p-frame was shifted vertically two lines downwards. After
deleting the first two and last two lines in the frames that were shifted (and the last four lines
for the frames that were not shifted) to get 2160 lines again, each frame was filtered to 540
lines by line averaging (using Shake’s Box Filter). Horizontal filtering from 3840 to 1920
columns was performed using Shake’s Sinc Filter to benefit in perceived sharpness from the
“oversampled” master.

The two 540-line fields where then weaved into one single 1080-line interlaced frame.
This process resembles the process in any video camera performing interlace in the basic
default ‘Field Integration Mode’ – i.e. like a 2160 line video camera sensor reading out the
average of the sensor’s line 1+2+3+4 to Field 1; line 3+4+5+6 to Field 2; line 5+6+7+8 to
Field 1 etc.


I think this would be feasible in AviSynth, not sure exactly how to code it though, or if it would actually produce better results than the traditional
separatefields.selectevery(4,0,3).weave

Also, I'd suggest reading up on the AviSynth documentation. I think you're a little confused about what some of the filters do / are for.

Derek

[xerces8]

Take a look here:
http://svt.se/content/1/c8/02/02/85/31/svt_multiformat_v10.pdf

Excellent! Thank you very much.

Also, I'd suggest reading up on the AviSynth documentation. I think you're a little confused about what some of the filters do / are for.

SeparateFields - separate even and odd lines of frame
SelectEvery - drop some frames/fields thru the clip
Trim - drop frames/fields at begin and/or end of clip
Weave - combine two and two fields into a frame

What do you think is missing?

[Manao]

function interlace(clip c, bool "bff", float "lowpassing")
{
bff = default(bff, false)
lowpassing = default(lowpassing, 0.75)
width = c.width
height = c.height
low_height = round(height * lowpassing)

downpassed = c.lanczosresize(width, low_height).lanczosresize(width, height)

return (bff ? downpassed.assumebff : downpassed.assumetff).separatefields.selectevery(4,0,3).weave
}It's does something akin to what was done with the SVT sequence, but uses lanczos instead of a plain average in order to low pass the video. If you don't lowpass (lowpassing = 1.0), it gives the same results as separatefields.selectevery.weave. Lowpassing under 0.5 are too strong, but you can use any value between 0.5 and 1.0 (the lower the value, the blurrier the results, but too high value will create visible aliasing, even on a CRT screen or with a good deinterlacer.

[xerces8]

Take a look here:
http://svt.se/content/1/c8/02/02/85/31/svt_multiformat_v10.pdf

1.) The conversion from 3840x2160p to 1080p is not described. Do you know how they did it?

2.) Are the files (or part of them) available for download?

[poisondeathray]

2.) Are the files (or part of them) available for download?

The pdf gives a link where you can download the 16-bit 4:4:4 SGI samples
http://www.its.bldrdoc.gov/vqeg/
ftp://vqeg.its.bldrdoc.gov/HDTV/SVT_MultiFormat/

You can download some of the other versions here
http://media.xiph.org/video/derf/

[GodofaGap]

It's does something akin to what was done with the SVT sequence, but uses lanczos instead of a plain average in order to low pass the video. If you don't lowpass (lowpassing = 1.0), it gives the same results as separatefields.selectevery.weave. Lowpassing under 0.5 are too strong, but you can use any value between 0.5 and 1.0 (the lower the value, the blurrier the results, but too high value will create visible aliasing, even on a CRT screen or with a good deinterlacer.
Doesn't a vertical blur achieve a similar effect? Or is resizing preferred?

[Manao]

Doesn't a vertical blur achieve a similar effect?Somewhat. Blur does a lowpass. But I find it easier to control the cutoff frequency with a resize.

[Blue_MiSfit]

Interesting, I thought this might spark some good discussion!

I'm interested to see how a traditional "drop fields" approach compares to this more comprehensive approach with extremely detailed content.

Not that I often deal with double-rate progressive sources, but still!

Am I correct in assuming that a process like this is designed to minimize flicker / "single field detail" that will look ugly on a proper interlaced CRT or on a progressive display, even with a competent deinterlacer?

Derek

[2Bdecided]

Take a look here:
http://svt.se/content/1/c8/02/02/85/31/svt_multiformat_v10.pdf

Specifically the part that has to do with how their 2164p50 sequence was interlaced to 1080i50Yes, but that's not supposed to be a good way to do it!

It's an intentionally sub-optimal way which mimics the way they think some cameras might do it.


manono has already given the right answer. As subsequently discussed, the only "improvement" is vertically blurring the image before you start, to reduce twitter on interlaced CRTs.

There's plenty of discussion of this in the various HD>SD threads, e.g.
http://forum.doom9.org/showthread.php?t=139102&page=6

My own preference (after trying more complicated solutions) is...
Blur(0.0,1.0).Sharpen(0.0,0.5)
assumetff()
separatefields().SelectEvery(4,0,3).Weave()
...which looks fine on a CRT.

mp4guy has a filter to do a much sharper cut-off (in the frequency domain) here...
http://forum.doom9.org/showthread.php?p=1165270#post1165270
...but I don't like the ringing (or the sharp frequency cut-off for that matter).

Hope this helps.

Cheers,
David.

[*.mp4 guy]

If your going to use a strong lowpass, this is probably better. However, I don't use interlaced displays, so I don't really know.

Function BlurV(clip c, int "rad", Float "CW")
{

Rad = Default(rad, 1)
CW = Default(CW, 0.5)

Center = C
Down = C.PointResize(C.width, C.height, 0, -rad, C.width, C.height)
Up = C.PointResize(C.width, C.height, 0, rad, C.width, C.height)

Average(Center, CW/2, Down, (1-CW)/2, Up, (1-CW)/2, Center, CW/2)

Return(last)
}

Function NLLV(Clip C, int "rad")
{


Rad = Default(Rad, 1)

B1 = C.BlurV(1*rad, 0.439)
B2 = C.BlurV(3*rad, 0.833)
B3 = C.BlurV(5*rad, 0.934)
B4= C.BlurV(7*rad, 0.983)

B1_D = Mt_Makediff(B1, C, u=1, v=1)
B2_D = Mt_MakeDiff(C, B2, u=1, v=1)
B3_D = Mt_MakeDiff(B3, C, u=1, v=1)
B4_D = Mt_MakeDiff(C, B4, u=1, v=1)

B2_DT = Mt_LutXY(B1_D, B2_D, " X 128 - Y 128 - X 128 - abs Y 128 - abs * 1 + * X 128 - abs Y 128 - abs * Y 128 - abs 2.273 * X 128 - abs - 0 > Y 128 - abs 2.273 * X 128 - abs - 0 ? X 128 - abs 0 > X 128 - abs -1 X 128 - abs 0 > X 128 - 1 ? / ^ 1 ? / 1 * + 1 + / + 128 + ", u=1, v=1)
B3_DT = Mt_LutXY(B2_DT, B3_D, " X 128 - Y 128 - X 128 - abs Y 128 - abs * 1 + * X 128 - abs Y 128 - abs * Y 128 - abs 2.67 * X 128 - abs - 0 > Y 128 - abs 2.67 * X 128 - abs - 0 ? X 128 - abs 0 > X 128 - abs -1 X 128 - abs 0 > X 128 - 1 ? / ^ 1 ? / 1 * + 1 + / + 128 + ", u=1, v=1)
B4_DT = Mt_LutXY(B3_DT, B4_D, " X 128 - Y 128 - X 128 - abs Y 128 - abs * 1 + * X 128 - abs Y 128 - abs * Y 128 - abs 2.9 * X 128 - abs - 0 > Y 128 - abs 2.9 * X 128 - abs - 0 ? X 128 - abs 0 > X 128 - abs -1 X 128 - abs 0 > X 128 - 1 ? / ^ 1 ? / 1 * + 1 + / + 128 + ", u=1, v=1)

Mt_AddDiff(B4_DT, C)

Return(last)
}


NLLV()
mt_convolution(horizontal=" 1 ", \
vertical=" 0.000001065433025438 -0.000016063451766901 0.000104412436485276 -0.000360697507858256 0.000574268400669151 0.000417649745941195 -0.003967672586441010 0.007304608821868880 -0.000365443527698423 -0.023179560899734431 0.041660562157630920 -0.003967672586440983 -0.118038259446620930 0.269801735877990670 0.660062134265899660 0.269801735877990670 -0.118038259446620930 -0.003967672586440983 0.041660562157630920 -0.023179560899734431 -0.000365443527698423 0.007304608821868880 -0.003967672586441010 0.000417649745941195 0.000574268400669151 -0.000360697507858256 0.000104412436485276 -0.000016063451766901 0.000001065433025438", u=3, v=3)

[Biggiesized]

http://en.wikipedia.org/wiki/Kell_factor

[2Bdecided]

http://en.wikipedia.org/wiki/Kell_factor
"Kell factor is sometimes incorrectly stated to exist to account for the effects of interlacing.

Interlacing itself does not affect Kell factor, but because interlaced video must be low-pass filtered (i.e., blurred) in the vertical dimension to avoid spatio-temporal aliasing (i.e., flickering effects), the Kell factor of interlaced video is said to be about 70% that of progressive video with the same scan line resolution."


You can filter as much or as little as you like - it's all subjective and there's no standard.


I have a feeling that some 1080i video isn't filtered vertically (especially artificially generated stuff, e.g. captions). The assumption (especially in Europe) is that there are no HD CRTs, so any 1080i video is going to be deinterlaced before display. Therefore any bobbing and/or twitter in the image will never be seen, so can be left in. Hence you get full 1080 resolution in the source, which is presented in full on any display that deinterlaces it nicely.

Cheers,
David.

[Manao]

And I still disagree. You seem to think deinterlacers are things of magic. They are not. In the end, they are still ruled by mathematics.

Bear with me and do the following :
Download mobcal (ftp://ftp.ldv.e-technik.tu-muenchen.de/pub/test_sequences/720p/720p50_mobcal_ter.yuv). It's 660 MB, but I know it will exhibit the problem.
Create an unfiltered interlaced SD version of it, by doing : rawsource("720p50_mobcal_ter.yuv", 1280, 720, "I420").assumefps(50).lanczosresize(720,576).assumetff.separatefields.selectevery(4,0,3).weave

Now, can you manage to find a full-framerate deinterlacer that doesn't twit/bob when the camera slowly dezoom ? I tried a vanilla TGMC (TempGaussMC_beta1mod without any parameters), and it fails here.

If you're wondering why I downscaled to SD and didn't try to interlace/deinterlace in 720p, it is because that way I increase the likelyhood of having details near to nyquist frequency (that, and I am always weary when I don't know how a video has been captured. For all I know, the capture implies a lowpassing to a lower frequency than nyquist's for 720p content).

Finally, if you add lanczosresize(720,384) between assumefps and lanczosresize, the twitter, at least with TGMC, is strongly reduce (still here, but not the first thing you'll notice anymore)

[Didée]

Well, sure, that's no surprise. In this case it's the "black hole problem" (my personal denomination). When vertical motion happens to have an odd pixel pitch (1px, 3px, 5px,...), then the data missing in this field is also missing in the next field, and the over-next field, a.s.o. Consequentially, there is nothing that could be reconstructed by temporal filtering.
Worse, when motion is ~somewhat close~ to such an odd pixel pitch, then there still is almost nothing that could be reconstructed temporally, and you're left back with the funky wavering as the signal slowly travels through the black hole.

The slogan of interlacing is "full temporal resolution on motion, full spatial resolution in static areas". But when blind lowpassing is used, the spatial part is simply not true.

IMO, it would be a worthwhile procedure to apply lowpassing only to areas that are moving. When the image moves, lowpassing makes sense by all means. But when nothing moves, lowpassing should not be necessary (a bob/deinterlacer should pick up nonmoving areas correctly), thereby not reducing resolution in static areas.

[Didée]

Comparison: how bob/deinterlacers are dealing with or without lowpass before interlacing.

RawSource("J:\_IMPORT_\G__DATEN\Video\Samples\720p50_mobcal_ter.yuv",1280,720,"I420")

assumefps(25) # intentionally half speed, for easier viewing of deinterlacing issues

hard = lanczosresize(720,576).crop(40,16,-40,-20,true).assumetff().separatefields().selectevery(4,0,3).weave()
lopass = lanczosresize(720,384).lanczosresize(720,576).crop(40,16,-40,-20,true).assumetff().separatefields().selectevery(4,0,3).weave()

v1 = lopass.tempgaussmc_beta2(2,1,3,0,0,0,"nnedi3",slrad=2) .subtitle("lopass-interlace + TGMC",size=14)
v2 = hard .tempgaussmc_beta2(2,1,3,0,0,0,"nnedi3",slrad=2) .subtitle("hard-interlace + TGMC",size=14)
v3 = lopass.Yadif(mode=1) .subtitle("lopass-interlace + Yadif",size=14)
v4 = hard .Yadif(mode=1) .subtitle("hard-interlace + Yadif",size=14)
v5 = lopass.tdeint(mode=1) .subtitle("lopass-interlace + tdeint",size=14)
v6 = hard .tdeint(mode=1) .subtitle("hard-interlace + tdeint",size=14)

stackvertical( stackhorizontal(v6,v4,v2),\
stackhorizontal(v5,v3,v1) )

Result: MultiUpload (http://www.multiupload.com/35L8C1MT0P) -or- MediaFire (http://www.mediafire.com/?8z379cgvo1te0qn)

Not exactly a "fail" for TGMC. Sure, there are some spots that show issues ... necessarily, for the reasons mentioned in the previous posts. But it's not that bad either. The "simple" bobbers on the lowpassed clip don't look "better" than TGMC on the "hard" clip. Do they?

If anything fails, then it is Yadif. Lots of artifacts, even on the lowpassed clip. :rolleyes:

The main question is, what kind of technique you're expecting to deal with the interlacing. When you're going to play "safe", by "optimizing" for the most simple and dumb deinterlacer only possible, then the choice is indeed simple: Blur, blurr, blurrrr ... blur the crap out of it. Pity for those with better equipment - spend lotsof money to no avail. OTOH, if you decide to not punish the folks with better equipment, then - pity for the masses.

Who are you going to punish? You can't avoid to punish someone.

"Oh, if only they had never invented the idea of interlacing."

[Manao]

The main question is, what kind of technique you're expecting to deal with the interlacing. When you're going to play "safe", by "optimizing" for the most simple and dumb deinterlacer only possible, then the choice is indeed simple: Blur, blurr, blurrrr ... blur the crap out of it. Pity for those with better equipment - spend lotsof money to no avail. OTOH, if you decide to not punish the folks with better equipment, then - pity for the masses.Not really. If you compare frame by frame, you'll see that the lowpass TMGC'ed isn't missing that much details in comparison to the hard TMGC'ed. I would actually say that there are more additional artifacts than additional details (which isn't surprising, since the details that disappeared with the lowpass is exactly the details that is near impossible for a deinterlacer to reconstruct properly).

As a side note, your TMGC with your settings is visibly better than mine. Less artifacts. A bit blurrier though, but that might be due to the encoding (and to the fact that artifacts on still frames have the nasty habit to look like added details)

Still, it fails. It's not its fault, but the source's, which gives another reason to hate interlacing : when somebody messed up, there's nothing you can do.

[Didée]

Perhaps I've been hurt too much by years of "enjoying" the results of TV station's processing. Over here, the typical (SD) TV frame looks like

Lanczosresize( 720/2, 576/2 )
Sharpen(1)
Bicubicresize( 720, 576, 1,0 )
SeparateFields().SelectEvery(4,0,3).weave()

It's really that bad. Ridiculously blurry with little details, yet lots of (over)sharpening halo's everywhere.

Maybe that's why I get green in the face as soon as I hear "lowpassing" in the context of interlacing. ;)


Edit - quick dig, a random frame from TV:

http://img139.imageshack.us/img139/2830/interlacinglowlowpassed.th.png (http://img139.imageshack.us/i/interlacinglowlowpassed.png/)

If that's not bad enough, I'll dig out the DVD "The 5th Element". Brilliant example for how to make it really, really bad.

[2Bdecided]

And I still disagree.Not with me I hope. The paragraph you disagreed with wasn't talking about what I do. I've already said what I do - it's close to "blur the crap out of it" ;)

The approach (not mine!) that I was talking about is something I've only seen applied to HD. You can't assume SD is going to be deinterlaced, so people always filter here AFAICT. It looks really shocking otherwise. Last time I saw that was 1980s computer graphics.

Cheers,
David.

[2Bdecided]

Bear with me and do the following :
Download mobcal (ftp://ftp.ldv.e-technik.tu-muenchen.de/pub/test_sequences/720p/720p50_mobcal_ter.yuv). It's 660 MB, but I know it will exhibit the problem.
Create an unfiltered interlaced SD version of it, by doing : rawsource("720p50_mobcal_ter.yuv", 1280, 720, "I420").assumefps(50).lanczosresize(720,576).assumetff.separatefields.selectevery(4,0,3).weave
I was using this for tests a few years ago. There's another version that's decades old (SD only). This clip, and another one of train tracks, is a classic test case for interlacing.

It's a real challenge making them look OK on an interlaced CRT, never mind trying to deinterlace them. However, processing which makes this clip look better may make another clip look worse. You shouldn't decide what low pass filter to use based on one clip alone.

But as for myself, I would never interlace without a vertical blur. The question is only "how much"? I don't think cutting out everything above 240 or 288 line-pairs is the way to go.

I wonder what Didée's content adaptive filtering would look like? I suspect it's action would be quite visible, and hence objectionable - adding to the static/moving resolution difference on some displays (bad), and introducing a static/moving resolution difference on display which don't natively have one (even worse!).

I know people commonly say that interlacing reduces vertical resolution when there's movement. IME, on a CRT without crappy processing, static resolution = movement resolution for horizontal pans. Vertical movement can create horrible problems of course.

Cheers,
David.