Deinterlacers and Settings Response [Archive]

scharfis_brain

19th May 2004, 06:02

@neuron2: (I am not mf, but I will answer nevertheless)
when we are building/using deinterlacers, we often can only let our eyes judge, because we don't really know, how the fullframrate output has been looked before it became interlaced.

mf's method is totally correct.

take a progressive 50 or 60 fps Stream (with shutter speed of 1/50 or 1/60, thats important!)
scale it down to one of our native SDTV resolution (7xx*576 or 7xx*480)

then reducing the bandwidth by doinging an interlacing:

Output is BFF

separatefields().selectevery(4,0,3).weave()

Output is TFF

separatefields().selectevery(4,1,2).weave()

when this is done, we can apply our object to test.

small example:

avisource("HDTV720-50p.avi")
input=lanczosresize(704,576) #anamorphic PAL
test=input.separatefields().selectevery(4,1,2).weave()
output=test.dgbob(order=1)
stackhorizontal(input,output)
# or using objective quality measuring metrics here

the best (oh I really think, we should create an auto-thread-closing mechanism when this word gets detected within ones post :D ) deinterlacer will return the output to be very close to the input.

but. could you re-open that thread?
I think he just took the wrong words.
I am sure he wants to know the 'recommened' settings :)

@[MA]Debito: that is NOT deinterlacing. this is IVTC.
please read some stuff on deinterlacing and IVTC, and then come back.

kassandro

19th May 2004, 08:51

I agree with scharfis_brain: mf's method is exactly the right way to evaluate deinterlacers. However, one should not use the eyes. Rather the average difference from the non-deinterlaced frames and the output size after a quality vbr encoding. One should also not measure the difference with respect to the original progressive frames, because this would unfairly favor sharp deinterlacers, i.e. those deinterlacers, which keep one field fixed and interpolate the other depending on motion.
I sharpely disagree with rule 12: "Do not ask what is best." This is simply user harassment.

Guest

19th May 2004, 11:59

@kassandro

Was that a general comment about harassment, or were you specifically referring to my action?

19th May 2004, 22:07

First, I'd like to say it's nice to see a response even though the original thread was locked.

scharfis_brain is right: I am converting 50p to 25i and 60p to 30i. I have already done some tryouts with my 3 sources, but nothing big. Here is a sample:
http://mf.creations.nl/avs/shuttle_kerneldeint.png

The settings are defaults because I'm clueless about kerneldeint's settings (also why I asked for them).

tritical

19th May 2004, 22:10

I find some of kassandro's suggestions very interesting, but I don't see how measuring the average distance from the deinterlaced frame will give you much of anything worthwhile for comparing quality. I also think that comparing the deinterlaced frame to the original progressive frame makes since for sharp deinterlacers, but not for blending deinterlacers. Likewise comparing the compressibility of the deinterlaced video as a means of measuring quality for blending vs. sharp deinterlacers hardly seems like a good idea. Actually, taking compressibility into account at all seems like a problem to me as you could use a deinterlacer that does vertical blending on the deinterlaced frame... in which case that will cause it to be more compressible, but that doesn't mean the quality will be increased. In my opinion you really can't compare blending to interpolating deinterlacers using the same conditions as they operate too differently and have different goals. In contrast, I actually think using the eyes to compare quality is not a bad idea. Sure, it isn't objective and standardized, but who in the end is the judge of quality? Not some quality metric numbers, but people who actually watch the video with their eyes :p

You can do the equivalent of ffdshow's 5-tap lowpass deinterlacer by running a 5x5 convolution with the following matrix with a divisor of 8:

{ 0 0 -1 0 0
0 0 2 0 0
0 0 6 0 0
0 0 2 0 0
0 0 -1 0 0 }

libpostproc also has another 5 tap deinterlacer with these taps
{ -1, 4, 2, 4, -1 } which is more like linear interpolation then blending as the one above. Hopefully this is the correct deinterlacer you were talking about :p

19th May 2004, 22:31

Oh, really, tritical :rolleyes:. I'd have expected a little more originality from you :D. If you want to compare to blended interlacers, you pull out your 50p source, and do:
Overlay(last.SelectOdd(), last.SelectEven(), opacity=0.5)
There you have your blended clip to compare against :p.

avih

19th May 2004, 22:41

mf, i can't see the motion in your images... :(

i understand the top-left is deinterlaced, and the bottom-right is probably interlaced, bottom-left is the diff between what? the top-right is one of the source fields (i.e from 50/60p)?

why didn't u choose a frame with more motion in it?

sorry if i missed something.

19th May 2004, 22:45

Originally posted by avih
bottom-left is the diff between what?
Bottom-left is the difference between deinterlaced and progressive original (which is top right).

tritical

19th May 2004, 22:46

I stand corrected. :o

Though in my very meager defense I will say that in that case your aren't comparing it to the original progressive frames but to blended versions of them :D And no... I'm not that original.

kassandro

19th May 2004, 23:24

Originally posted by neuron2
Was that a general comment about harassment, or were you specifically referring to my action?
At first sight I thought your action was a joke. Certainly harassment is a too strong word for it, but ridiculous rules should be ridiculed.
I appreciate your great work for Avisynth and I have learned a lot from the very readable source code, but I cannot approve overmoderation of a forum and you did just this.

kassandro

19th May 2004, 23:52

@mf
Where did you get your 50/60 fps progressive source? To have a good test, it should not have been created from 25/30 fps interlaced video.

@tritical
I appreciate your knowledgable contributions to this subject, which I remember well from an earlier thread. Having said that, I don't agree with your two main arguments.
Firstly, if you reject compressability as a quality argument, the best deinterlacer is simply to do nothing. Of course the output looks ugly, but there is no good objective measure for it. On the other hand a deinterlacer should not cheat, that means it shouldn't change those areas of a frame, which don't contain any motion. I called this the "no motion no change" principle. Clearly the cheap vertical blender violates this principle and it doesn't give the best compression either, because purely spatial blurring is far inferior to a mixture of spatial and temporal blurring as far as compression is concerned, at least if the clip contains a minimal amount of motion.
Secondly, why should one compare with the interlaced rather than the progressive original frames? On one hand, there are two progressive frames from which one interlaced frame is made of and for some deinterlacers the results become very different depending which of the two progressive frames is selected for comparison. On the other one progressive frames contains only half of the information of the interlaced frame and a sharp deinterlacer tries to reconstruct the motion of one field while a blended deinterlacer treats both fields equally. Hence a sharp deinterlacer will perform much better than a blended deinterlacer, if the comparison is made with respect to the right progressive frame and worse if the comparison is made with respect to the wrong progressive frame.

19th May 2004, 23:58

A DEINTERLACER DEINTERLACES INTERLACED MATERIAL. PROGRESSIVE MATERIAL IS NOT INTERLACED.

Mangling progressive to produce "combed" video will not test a proper deinterlacer.

I sorry to not have something constructive to say however :o

regards
Simon :D

Guest

20th May 2004, 00:04

Originally posted by Si
A DEINTERLACER DEINTERLACES INTERLACED MATERIAL. PROGRESSIVE MATERIAL IS NOT INTERLACED.

Mangling progressive to produce "combed" video will not test a proper deinterlacer.
I'm glad I am not the only one that thinks this very strange. ;)

avih

20th May 2004, 00:41

i don't think it's silly.

imagine this sequence:

- since the framerate doesn't matter at all (only relations between frames/fields), i'm not going to touch it.

1. start with any progressive content (say film) with original vertical resolution R (not upsampled. downsampled is ok) and framerate F.

2. shift every other frame vertically by 1 pixel

3. reduce every frame vertically by a factor of 2 (bilinear/bicubic)

4. weave.

we now have: interlaced frames, R pixels high, and F/2 framerate (F fieldrate)

now, if F was 50, then the resulting clip would very much simulate (emulate?) a PAL interlaced content.

what have we got?
1. there is a F fps source progressive.
2. there's an F/2 interlaced content, each field corresponds to a different source frame, each field is half the full frame height and shifted properly.
3. we now ALSO have a reference full height progressive frames, to which we can compare the deinterlaced frames from such a test. this is something we don't have with pure interlaced content, and it's a bonus.

since we might not have 50p clip, we may start with any other (say film 24p). it doesn't matter, the relations between the frames/fields will be identical. you can check motion between fields, and you can compare to the actual original Fp frames.

scharfis_brain

20th May 2004, 00:44

Si, did you read what I stated above?

50 fps progressive video (I do not mean 25fps Film which gets phase shifted to let it *look* interlaced) can surely be reduced to interlaced video.
and this interlaced video can be (fullframerate <<- Kassandro!!!) deinterlaced and then compared to the original 50 fps progressive source. So mf is totally right.
I didn't even understand the soft vs sharp deinterlacer Stuff and kassandros no motion no change....
Building a deinterlacer means to me:
- restore as much information as possible out of the interlaced video
- this means FULL Framerate
- completely copy the CURRENT field to the output
- on no motion areas copy the Next as well as the previous field to the output, too.
- only moving areas should be interpolated using a more or less intelligent algorithm
- this doesn't include any blending etc.
- every other image enhancing (blending, nailing down static parts etc.) shall be done afterwards.
just my opinion

blending or soft deinterlacers are *maybe* useful for pleasing the eyes on half framerate (25 or 30 fps) with some motionblur, but they do NOT return the best detail possible out of the interlaced stream.

please note: interlacing is just a very simple kind of compression:

static (or pure horizontally moving) images are leaved at FULL resolution, while moving images are only get half vertical resolution.

a (fullframerate, sharp) deinterlacer trys to undo this 'compression'

tritical

20th May 2004, 00:45

I fail to see how mf's method of producing interlaced material from true 60 frames/second progressive material that was shot with a shutter speed of 1/60 is any different at all then true 60i material. It seems that by definition it would produce exactly what a camera that captures 60i would. The best thing about this method is that if true 60 frames per second progressive material like this can be obtained (the big hindrance) it would, as scharfis_brain said earlier, give us a good way to test deinterlacers using something other then our eyes. As with plain 60i material you don't have the actual true progressive frames to begin with and here you would. Of course all those 60's need to be changed to 50's for the pal folks.

tritical

20th May 2004, 02:15

@kassandro
On the first point about compressibility. Let me start off by saying that I somewhat agree, but only because a deinterlaced clip will always have better compressibility then the same non-deinterlaced clip when you encode them both as progressive. But, I still don't understand exactly how compressibility of the final clip would be meaningful for comparing the quality of two deinterlacers. If you take compressibility as the only measure of quality then the best thing to do would be to memset every frame to 0x00, but this would definitely not be good. Now, if you obey the "no motion no change" rule, which far from every deinterlacer does, a blend deinterlacer will almost always beat a sharp deinterlacer in terms of final output compressibility, but does that mean blend deinterlacers are better quality wise then sharp deinterlacers? A blend deinterlacer that does its blending by including pixels from frames other then the current one would increase compressibility over a simple 1:2:1 blender, but it also tends to produce more artifacts. If you compare only sharp deinterlacers that obey the no motion no change rule, a sharp deinterlacer that could reproduce high frequency details (in moving areas) more accurately (closer to the original progressive frame) would generally give worse compression ratios then one that settles for simple linear interpolation... again the question is does this mean the quality is better?
Firstly, if you reject compressability as a quality argument, the best deinterlacer is simply to do nothing.
To me this only holds, at best, if you cannot use any other measure of quality. If you instead use the difference from the original progressive frame (if it is available) or your eyes (though this is subjective, but I don't see why this can't be used) then this is not the case. I guess in the end I'm saying that simply because a deinterlaced frame compresses well, that fact alone doesn't tell you much of anything about the quality of the deinterlacer. That doesn't mean it cannot be used along with other measures though. I still say that you cannot meaningfully compare the compressibility of a blend deinterlaced clip to that of a sharp deinterlaced clip and obtain information about which one is better quality wise based off that information alone.

Point 2, I think I may be misunderstanding what you mean by comparing the deinterlaced frames to the non-deinterlaced frames. Obviously a sharp deinterlacer that interpolates the top field would need to be compared against a different original progressive frame then one that interpolates the bottom field. Maybe you could explain what you mean by this
Rather the average difference from the non-deinterlaced frames
a little more, and how you would infer the quality of a deinterlacer from it.

Guest

20th May 2004, 02:38

There simply is no objectively correct progressive analog of an interlaced frame!

You can apply any function F to a progressive clip and make what you call an interlaced clip. Deinterlacing the latter and comparing it to F simply measures how well the deinterlacer inverts F. On this view, the ideal deinterlacer would be the inverse of F, which is dubious because different Fs can be chosen (as we have seen above).

Again for emphasis: There simply is no objectively correct progressive analog of an interlaced frame!

avih

20th May 2004, 04:22

Originally posted by neuron2
...Again for emphasis: There simply is no objectively correct progressive analog of an interlaced frame!

well, if the original clip would have been recorded 25p instead of 25i (or perhaps with the same [split] lense and shutter speed on the same time into 2 recorders i/p), then each 25p frame would be the analogy of every other frame of the deinterlaced 25i clip.

of course, deinterlacing is interpolating completely unknown data, or creating pixels out of this air, but still, the silulation above would be the closest in theory. imho at least.

tritical

20th May 2004, 09:22

Even with the extra emphasis I will chance it and disagree :D

I would actually argue that there always, 100% of the time, is a completely unambiguous progressive analog of every interlaced frame. Whether or not you personally have it, captured it, or know what it is is completely irrelevant to its past and/or present existence. When you captured a field in an interlaced video the opposite field did exist... the part of the image you weren't capturing did not suddenly disappear or take on ambiguity in the real world, it was there and at that exact moment in time a progressive analog (a picture containing that field and the opposite field) did exist.

Likewise your observation that you can do multiple things to a progressive video to make an interlaced video is true. But I would argue that the qualities or properties of interlaced video are state functions, meaning how we got there doesn't matter. The other thing to remember is that all of these F()'s produce the same output, so even if they are different the same inverse F() can always be used. If they don't produce the same output then they aren't conforming to the properties of interlaced video, or producing the same type of interlaced video in which case a different inverse F() is needed. Another interesting fact is that with scharfis_brain's
separatefields().selectevery(4,0,3).weave() method the exact inverse of F() is not possible (assuming you no longer have access to the original progressive clip like a deinterlacer) just as it would be possible to make the exact inverse of any F() that turns progressive into interlaced not possible, which is exactly what happens when you capture interlaced video. Thus, the only way you are left with to recreate the original is by the same techniques used for deinterlacing.

The real question you are getting at is should how well a deinterlacer performs be measured by testing how well it recreates that progressive analog or instead by how well it removes combing or how pleasing the image is to a viewer. That's a good question, since obviously in all normal cases of deinterlacing the original progressive analog is not, and never will be, available.

20th May 2004, 11:57

I have used 1080i sources, deinterlaced them, and downsized them to less than half their original resolution. Believe it or not, find it scientific or not, but it is an accurate representation of progressive frames as shot by an interlaced camera. I use the abundance of data available in 1080i HDTV to make sure that the low-res version is as accurate as possible, and I can assure you the static frames are 100% static, and that there is no "bobbing" going on anywhere. I sense a lot of people looking inside narrow boxes though, and I have the idea that even this way of generating progressive video will be shot down. It will be interesting to read the arguments though. Nostradamus predicts: a lot of "absolute" statements like "There simply is no objectively correct progressive analog of an interlaced frame" ;). Put simply, there often isn't any simplicity to interlacing, so all those arguments are inherently flawed :D.

Wilbert

20th May 2004, 12:21

I agree with how you make your interlaced source (50p -> 25i).

But I fail to see how you are gonna compare the output of the deinterlacers with the 50p source. Obviously the number of frames differs by a factor of 2. Do you just pick the even (or odd) fields from the source for comparison?

scharfis_brain

20th May 2004, 12:30

@ wilbert:

50p contains 50 states of motion per second

25i (or call it better 50i) contains 50 states per sec, too!

if you deinterlace 25i with a normal deinterlacer, you'll get 25fps that is true. but a 'normal' deinterlacer will then throw away more than the half of valueable video information.

thus we need to build a bobber (FULLfrmarate) deinterlacer out of our 'normal' deinterlacer first, before doing the comparision to the original 50p input.

dgbob, kernelbob, tomsbob, adeint(alt=true) etc. are bobbers that fit the requirements of such a test.

if you find an interesting deinterlacer that has no bobbing abilities, post it here, I'll try build a bobbing functionability around it :)

Wilbert

20th May 2004, 12:36

thus we need to build a bobber (FULLfrmarate) deinterlacer out of our 'normal' deinterlacer first, before doing the comparision to the original 50p input.

dgbob, kernelbob, tomsbob, adeint(alt=true) etc. are bobbers that fit the requirements of such a test.
Ok, I get it :)

20th May 2004, 13:23

Actually, I have decided I have had enough. I do not have sufficient motivation left to continue this test. It was an interesting concept though.

kassandro

20th May 2004, 13:26

Originally posted by tritical
I would actually argue that there always, 100% of the time, is a completely unambiguous progressive analog of every interlaced frame. Whether or not you personally have it, captured it, or know what it is is completely irrelevant to its past and/or present existence. When you captured a field in an interlaced video the opposite field did exist... the part of the image you weren't capturing did not suddenly disappear or take on ambiguity in the real world, it was there and at that exact moment in time a progressive analog (a picture containing that field and the opposite field) did exist.

I agree with that point of view. Now a sharp deinterlacer keeps one field unchanged and uses the other only if there is no motion and interpolates otherwise. Thus such a deinterlacer tries to reconstruct one and only one of the two progressive frames from which an interlaced frame is made of. If you compare the output of such a deinterlacer with the right progressive frame (the one with the unchanged field) the comparison is much better than if you compare with the wrong progressive, which is not used if there is motion. On the hand a blending deinterlacer must treat both fields equally and a comparison with just one of the progressive frames is just unfair, because such a deinterlacer simply doesn't want to reconstruct one of the two progressive frames. Therefore fair comparison is only possible if you compare with the interlaced frame, which contains an equal amount of information from both original progressive frames.

If you take compressibility as the only measure of quality then the best thing to do would be to memset every frame to 0x00, but this would definitely not be good.

Of course, I never claimed that. There are two antipodal quality measures for a deinterlacer. Firstly the deinterlacer should preserve as much detail as possible from the input, i.e. the interlaced frame. Secondly the output should be as compressible as possible. And of course, the deinterlacer must also be sufficiently fast. All deinterlacer plugins are sufficiently but some of the deinterlacer scripts based on the mask tools and overlay have a speed below 1 fps and this simply unacceptable.

mf
I have used 1080i sources, deinterlaced them, and downsized them to less than half their original resolution. Believe it or not, find it scientific or not, but it is an accurate representation of progressive frames as shot by an interlaced camera.

I disagree! Whenever you double the frame rate with a deinterlacer, especially with a sharp deinterlacer, you get a very characteristic shimmer if you step from one frame to another. Downsizing only softens this very unpleasant effect, which is totally absent from truely progressive video. Furthermore this shimmer will mislead motion detection of some deinterlacers. I am sorry, such videos are completely unacceptable for a fair comparison. We need something genuinely progressive. It would be better to use a 25 fps progressive clip and convert it to 12.5i fps.

Guest

20th May 2004, 13:31

@tritical

I said there is no progressive analog for an interlaced frame. It was clear that I meant a progressive analog frame. What you offer is two progressive frames as the analog of the interlaced frame. Fine, I'll accept that this test may have a meaning when applied to bobbing deinterlacers (although what exactly it is testing, and how useful that is, is still debatable). But my conceptual critique applies to simple deinterlacers.

"thus we need to build a bobber (FULLfrmarate) deinterlacer out of our 'normal' deinterlacer first, before doing the comparision to the original 50p input."

This is just another way of saying the same thing. If you do that you are no longer testing the original single-rate deinterlacer.

I also maintain that the nature of the source progressive material will critically affect what gets viewed as 'best'. As an extreme case, if the input is line doubled, then non-adaptive simple interpolators will be declared best.

Arachnotron

20th May 2004, 13:34

If I may intrude on this discussion:

If I understand correctly, you take a 50 frames per second progressive source and extract an interlaced one out of it:

12345
ABCDE = 50 frames per second procressive
abcde

12345
AbCdE = 50 fields per second = 25 frames per second interlaced .

Using deinterlacing, you try to 'reconstruct' the lost info, and by comparing the recovered frame to the original you get a metric

My problem with this is that if you reconstruct a frame by blending two fields, you are in effect interpolating in time. The resulting frame from field 1 and field 2 will be interpolated at a time between 1 and 2.

Using this method would result in unfairly low metrics in high motion scenes.

IMHO you should take a 100 frames per second progressive source:

123456789
ABCDEFGHI 100 frames per sec progressive source
abcdefghi

1 3 5 7 9
A c E g i 50 fields per second = 25 frames per second interlaced .

depending on interlacing strategy, the first reconstructed frame may be a reconstructed Aa, Cc or the equal of frame Bb from a timepoint in between!

So, compare the resulting range of frames with the original frame ranges 1,3,5.... but also 2,4,6 and 3,5,7...

This gives 3 metrics. take the highest for comparison

20th May 2004, 13:40

Originally posted by kassandro
Furthermore this shimmer will mislead motion detection of some deinterlacers.
This shimmer (http://mf.creations.nl/avs/shuttle_shimmer.png) is going to mislead motion detection of interlacers to the point of getting an unfair test. :rolleyes:
(Edit: even this shimmer will disappear when you weave the video into an interlaced frame, so that totally voids your statement.)
(Edit2: This (http://mf.creations.nl/avs/shuttle_shimmer.png) is all the shimmer that's left after weaving, and I could even use a denoiser to get rid of that if it's really bothering you.)

scharfis_brain

20th May 2004, 13:42

Thus such a deinterlacer tries to reconstruct one and only one of the two progressive frames from which an interlaced frame is made of. If you compare the output of such a deinterlacer with the right progressive frame (the one with the unchanged field) the comparison is much better than if you compare with the wrong progressive, which is not used if there is motion. On the hand a blending deinterlacer must treat both fields equally and a comparison with just one of the progressive frames is just unfair, because such a deinterlacer simply doesn't want to reconstruct one of the two progressive frames.

You didn't seem to understand what we try to explain all over the time:

reinterlacing progressive content.

imageine a progressive sequence

Source frame: 1 2 3 4 5 6 7 8 9
top fields: A B C D E F G H I
bot fields: a b c d e f g h i

feeding this, as it is, would jield in the problems you described above, but we REDUCE (reinterlace) that content:

Source frame: 1 2 3 4 5 6 7 8 9
top fields: A C E G I
bot fields: b d f h

when we apply a normal sharp deinterlacer to this sequence, it will take field b and then search for movements related to field A.
on nomo areas it will copy A and b to the output.

the next frame will be besed on field d using field C for motioncheck.
the next next frame will use field f..., h... etc.

but this is not the whole thing.

a deinterlacer has to deinterlace the FULL Framerate:
this means it has to alternate between bottom and top field

Outputframe | Dominant field
1 | A
2 | b
3 | C
4 | d
5 | E

thus returning the full fluidity of the motion presented by interlaced video why trying to retain the most resolution as possible.

only such a sharp bobbing deinterlacer can be used for measurements
blending and/or halfframerate deinterlacers are not usable.

kassandro

20th May 2004, 13:56

I do not understand what you want to say with shuttle_shimmer.png.

I also fully support Arachnotron point of view.

scharfis_brain

20th May 2004, 14:06

what do we try to discuss here?

deinterlacers or the correct way of reducing progressive to interlaced ?!?

I doubt, that anyone is able to decide, whether a clip came originally from a (Fullframerate 50 or 60 fps) progressive video (reinterlaced by sepfields().selev(4,0,3).weave() ) or came directly from an interlaced cam.

what way do you think, 50p HDTV feeds are reduced to SDTV 50i ?
it would be exactly the same, expect that it is not AVISynth that has been used for processing...

kassandro

20th May 2004, 14:09

Originally posted by scharfis_brain

Source frame: 1 2 3 4 5 6 7 8 9
top fields: A C E G I
bot fields: b d f h

I didn't think of anything else.

when we apply a normal sharp deinterlacer to this sequence, it will take field b and then search for movements related to field A.
on nomo areas it will copy A and b to the output.

the next frame will be besed on field d using field C for motioncheck.
the next next frame will use field f..., h... etc.

Again this is fully compliant with my point of view.

but this is not the whole thing.

a deinterlacer has to deinterlace the FULL Framerate:
this means it has to alternate between bottom and top field

I use such full framerate deinterlacing only for short clips, where motion is particularily important and I know nobody, who seriously encodes a 90 minute video with full framerate. The reason is obvious:
very poor compression, because of the shimmer problem described above.

Arachnotron

20th May 2004, 14:10

what do we try to discuss here?

mf's method for comparing deinterlacers? :confused:

Guest

21st May 2004, 17:28

Mod note: Just to advise that this thread has been re-opened because it is interesting. Doom9 took the welcome liberty of doing some editing on it. If things get personal again, I plan to "hand off" to a different mod.

Now, where were we...?

Arachnotron

21st May 2004, 17:55

ok, to open the ball.. :D

I think the concept proposed by Mf has merit, but only of you can apply it to different types of sources, i.e. truly interlaced and progressive and any deinterlacing method should be covered.

That is, the 'reference' frame stream should have a frame available for any timepoint that may result from the reconstruction by the deinterlacing algorithm. So you must have a full frame available for any timepoint on which the interlaced video only has a field *and* for each timepoint in between to deal with the temporal interpolation you perform when using info from two fields from consecutive timepoints to create a new frame.

You don't actually need a 100 fps video for that; you can synthesize one by speeding up a 25 or 50 fps one. But each frame in the reference sequence must be complete/progressive and cannot itself be the product of deinterlacing.

[edit] :o forget that bit about applying it to progressive sources. You would not test a deinterlacer there apart from maybe to see if it leaves it alone....

MfA

22nd May 2004, 14:13

Just take a progressive stream, optionally apply some vertical blur to deflicker, and drop the even/odd lines for each frame ... hey presto, you have an interlaced stream, and a reference to compare against (if vertical blur is applied the reference should be the blurred version obviously).

The whole resizing **** mf proposes to generate a semi progressive stream is rather roundabout ... that is not how a camera does it, and since real progressive streams are available why bother?

Guest

22nd May 2004, 15:44

Originally posted by MfA
Just take a progressive stream, optionally apply some vertical blur to deflicker, and drop the even/odd lines for each frame ... hey presto, you have an interlaced stream No, you have a blurred half-height progressive stream.

Arachnotron

22nd May 2004, 18:11

Why not take a 24 fps movie as a reference source? From a DVD?

You then have 24 progressive frames per second. Speed up to 50 fps.

Now alternatively drop the top or the bottom field. The result is 50 fields per second, each field originating from a consecutive timepoint.

use these to create 25 interlaced fields per second.

Now, as I stated before, to have a reference that also covers the timepoints in between, the recepy becomes:
24 fps movie
speed up to 100 fps
decimate each second frame
alternatively drop top or bottom field
create 25 fps interlaced testvideo from fields

MfA

22nd May 2004, 19:43

Originally posted by neuron2
No, you have a blurred half-height progressive stream.

With vertical spatial aliasing, and a .5 pixel vertical shift on alternating "frames" ... sounds like an interlaced stream to me.

BTW I know appeal to authority is considered bad form, but since you give no reasoning at all for your opinion I dont see how you could object ;) This method was good enough for Alexis M. Tourapis (from PMVFAST fame) to create interlaced sequences from progressive ones when he tested his de-interlacing algorithm (http://www.geocities.com/alexismt/papers/101vcip01.pdf) ...

scharfis_brain

22nd May 2004, 19:58

MfA, your method is right, expect of the blurring.

do not blur before reinterlacing. that will reduce the max. possible crispness.

most new TV-shows have full vertical resolution of 576 (480) lines.

so, this (well known) method:

bicubicresize(704,576).separatefields().selectevery(4,0,3).weave()

will convert any progressive source into a pure interlaced stream, like a TV-cam would output.

@neuron2:
I've read your opinion,

1´) that an 50i or 60i stream never existed in a progressive form. that's not really true.

the image was completely progressive when the CCD was exposed with its light. Only the readout of that CCD 'forgot' to save every 2nd line...

2) a deinterlacer should only hide jaggy diagonals and fill moving areas with appropriate interpolated pixels.

this is fully correct for a threshold based deinterlacer.

but with my tests two weeks ago, I used manaos motioncompensation to build a fully motion compensated deinterlacer.
on not that difficult content, it was able to nearly fully restore the progressive picture, that was given to me before I reinterlaced it.
So I got much better
- image clarity
- resolution
- diagonals (near to perfect)

Now I ask again: why should mf's method to measure the quality of a deinterlacer not being usable?

MfA

22nd May 2004, 20:05

As I said, optional. Crip is nice, but flicker isnt.

scharfis_brain

22nd May 2004, 20:08

but do not blur with paramters like 1 or above.

only 0.3 less...

I often see TV shows with lot of flickering fine horizontal detail...
and it doesn't bother me that much..

Dali Lama

23rd May 2004, 03:38

Hi everyone,

After reading the first few posts, my initial reaction was NO. A progressive source is not an interlaced source. I understand that one can make a progressive sourced become interlaced, but they are just not the same in reality. Then I read opinions that agreed and I felt satisfied that I may be right.

Then, I thought about what others pointed out: CCD's are generally progressive and due to the video system we mostly use, interlacing is chosen as a destination format.

This article illustrates it well for me:

Video Systems (http://videosystems.com/ar/video_progressive_need_know/index.htm)

So, I propose we try to achieve the pair summation talked about in the article through AVISynth. That will most accurately replicate an interlacing camcorder and prevent flicker and keep resolution as close to interlacing camcorders.

But I just have to say that other artifacts are produced from interlaced sources that a deinterlacer should handle. (I will try to elaborate later, but I think all of us know what those are)

Sincerely,

Dali

23rd May 2004, 10:11

@Dali Lama

Balance :)

You must be the real one :)

regards
Simon

scharfis_brain

23rd May 2004, 10:28

dali, to simulate that kind of low pass filtering mentioned in that article, this script should be fine (just theory, not tested):

avisource("hdtv720@50p.avi")
bicubicresize(704,576) #do a crisp SDTV downscale
separatefields().selectevery(4,0,3) # now we have super crisp, maybe flickering fields
overlay(last,last.trim(1,0),opacity=0.25) # do the weighted field averaging
weave() # re weave the fields

okay, after watching some TV show very closely, you may seem right, they are vertically low pass filtered. some more others less.

but: only the video footage, on CGI they always seem to forget those lowpass filtering.

btw. the crisper the video is, the better you can test a deinterlacer, IMO.
so I would prefer the non lowpass filtered way....