Deinterlacers and Settings Response

[[MA]Debito]

my suggestion:

Decomb511(or higher - incase of update)

Telecide(order=1,guide=1,blend=true,vthresh=75,gthresh=10,post=4).\
Decimate(cycle=5, threshold=2.0)

That usually does the job for me.

Or if you'd prefer, you could run it through TMPGenc and get a perfect deinterlace.

[Guest]

@mf

When you say you will convert a progressive video to interlaced, what does that mean exactly? It sounds as if your method will test only the extent to which the deinterlacer does not affect progressive content.

[scharfis_brain]

@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]

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]

@kassandro

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

[mf]

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]

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

[mf]

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]

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.

[mf]

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]

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]

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]

@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.

[Si]

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]

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]

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]

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]

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]

@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]

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]

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]

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.

[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 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]

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]

@ 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]

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 :)

[mf]

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]

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]

@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]

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

[mf]

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]

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]

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

I also fully support Arachnotron point of view.

[scharfis_brain]

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]

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]

what do we try to discuss here?

mf's method for comparing deinterlacers? :confused:

[Guest]

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]

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]

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]

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]

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]

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]

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]

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

[scharfis_brain]

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]

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

[Si]

@Dali Lama

Balance :)

You must be the real one :)

regards
Simon

[scharfis_brain]

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....

[Guest]

Originally posted by MfA
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) ... Rubbish, I explained my point of view.

The link you cited is dead. Was there perhaps a typo?

[MfA]

Standard deep linking prevention, just enter it in the address bar so you dont get a referrer and it works.

Alternatively google for "Advanced De-Interlacing techniques with the use of Zonal Based Algorithms".

A field is simply a vertically subsampled image. Dropping the even/odd lines from a frame accomplishes the same thing as interlaced recording, and those even/odd lines are obviously the ideal reconstruction for a deinterlacing algorithm applied to the resulting fields.

[avih]

Originally posted by MfA
A field is simply a vertically subsampled image.
yes, i would say so.

Dropping the even/odd lines from a frame accomplishes the same thing as interlaced recording, and those even/odd lines are obviously the ideal reconstruction for a deinterlacing algorithm applied to the resulting fields. [/B]
i don't think so. you loose half of the vertical info by dropping each other line. imo, you'll have to resize the image v/2 (bilinear/bicubic). an interlaced image is vertically continueos, just half the v-res.

[MfA]

Originally posted by avih
i don't think so. you loose half of the vertical info by dropping each other line.

Loosing information is what subsampling is all about.

The trick to interlacing is that as long as there is no or little motion the vertical info is fully reconstructed on display. You trade off aliasing when there is motion for increased temporal resolution ... personally I think it is a lousy trade off which makes format conversion so hard it should be outlawed, but still it proliferates.

[avih]

when u subsample, u indeed loose info, but by dropping each other line, u use nearest-neighbour. i think that resizing by interpolating is better in this regard, since the camera's ccd captures without missing vertical info and therefore, with less aliasing. (imagine a very fine set of horizintal lines, they would not just dissappear in interlaced field, they SHOULD be averaged by their lumas for a grayish color on each field).

imho at least.

[Guest]

I am familiar with that paper already.

He writes:

We have selected five progressive CIF (30fps) sequences, namely sequences Foreman, Table Tennis, Stefan, Akiyo, and Miss America. These sequences were converted into interlace by dropping all even fields in the odd frames, and all odd fields in the even frames. Even and odd frames were then interleaved together to create a new interlaced frame. The sequences now were converted from 30frame per second sequences to a 30 field per second format. This procedure basically allows us to compare the reconstructed deinterlaced frame with the original reference frame, and thus more accurately be able to evaluate the performance of our algorithm. The problem for me is that this process is not specified: "The sequences now were converted from 30frame per second sequences to a 30 field per second format." I don't see how that could be done in a way that yields meaningful results. And I don't consider determining the extent to which a deinterlacer damages progressive frames an objective measure of the "goodness" of the deinterlacer.

Still, Mfa, you can appeal to any authority you like and rely on them if you like. It doesn't matter to me.

[MfA]

"These sequences were converted into interlace by dropping all even fields in the odd frames, and all odd fields in the even frames."

Is the process.

[Guest]

No. That's how he makes the interlaced sequences. But you then have to compare those to the original sequences (but they are half the length of the originals). The phrase in question does not describe the decimation performed on the original progressive sequences to allow them to be compared to the interlaced sequences. If it is to just drop every other frame, then the "best" deinterlacer would be one that simply discards fields.

And *that* is the essence of my critique.

[MfA]

"That's how he makes the interlaced sequences. But you then have to compare those to the original sequences."

Only after deinterlacing, at which point even/odd lines have been resynthesized ... which are then compared to the even/odd lines which were originally dropped.

Lets look at the original progressive sequence as a sequence of fields ...

AB CD EF GH

To create the interlaced sequence we take :

A D E H

Lets assume its a 1-field to 1-frame deinterlacer, so the deinterlacer produces :

AB' C'D EF' G'H

To assess the quality of the deinterlacer we take the sum of the differences of these pairs :

(B,B') (C,C') (F,F') (G,G')

[scharfis_brain]

MfA: best explantation, I've read so far!

that is exactly, what I've tried to say all the time....

[MfA]

Originally posted by avih
i think that resizing by interpolating is better in this regard, since the camera's ccd captures without missing vertical info and therefore, with less aliasing. (imagine a very fine set of horizintal lines, they would not just dissappear in interlaced field, they SHOULD be averaged by their lumas for a grayish color on each field.

You WANT the aliasing in the field, because as long as nothing moves the even/odd fields taken together are NOT aliased. So as long as nothing moves you retain full vertical resolution ... with your method you might as well just use a progressive sequence with half the vertical resolution.

[avih]

Originally posted by MfA
You WANT the aliasing in the field, because as long as nothing moves the even/odd fields taken together are NOT aliased. So as long as nothing moves you retain full vertical resolution ... with your method you might as well just use a progressive sequence with half the vertical resolution.

it doesn't matter how u look at it, u DO have half vertical resolution on each field.

i don't have a video camera to test it, but iirc, i've never seen field shimmer on video (CGI or film conversion is another issue). which makes me understand that you won't get aliasing with normal video footage. hence, a proper interpolation should be used imo. the higher resolution u get from using both fields in a static video, is due to the 1/2 scanline shift of each field (i think). this could also be a parameter of the camera, i'mnot sure. but it should be easy to test it. print a page with horizontal black/white lines. put a video camera on a tripod, film the paper. zoom in untill the lines are mroe or less aligned with the scanlines (now that would be hard ;) ), and then watch the recording.

if indeed one field is white, and the other is black, then you're right. if they're both gray, then i'm right. although i suspect the result will be somewhere in between, and might vary with different cameras.


hmm, the test i suggested is not so fair, because it has a higher chance to proove me right, even if you were right. because if the camera is 1/2px (full res) shifted, then each scanline will capture 1/2 black 1/2 white, and it'll turn out gray, eventhough each scanline misses some info. so the camera should be moved top/bottom few mm and the whole moving sequence should be captured. also, if u zoom out too much, it's going to be gray anyway... :/

here's more or less what i had in mind:
http://img20.imageshack.us/img20/6725/bw.png

ps- this post has been edited several times. pls read it again ...

[MfA]

Full on resizing which the effective vertical resolution in half ... there is no reason to use interlaced scan anymore if you do that.

There is this thing called the Kell factor which gives you the vertical resolution without motion after you have combined even/odd lines on a display, and it is ~ 0.6-0.7 not 0.5

As I said before, you can apply some vertical blur before dropping the even/odd lines (in old fashioned cameras this is done using vertically elongated scanning spots for instance) to decrease flicker.

Neuron2 : during the googling I did to find this out I came upon this paper (http://neuron2.net/library/1996-09.pdf) on your site. They use the exact same method as I proposed above to test deinterlacing methods :p (To Avih : they dont filter before subsampling in this particular case.)

[avih]

good info MfA. thx. well, if indeed the full res static image is about 0.6-0.7 of full height, then, dropping each other line streight will not work well (as it would give 100% resolution), and, as u noted, some blurring would have to take place, and indeed, bilinear/bicubic would be less than optimal too.

cheers.

[Guest]

Originally posted by MfA
Lets assume its a 1-field to 1-frame deinterlacer... And if it isn't, i.e., it's a basic non-bobbing deinterlacer?

C'mon, Mfa, you're evading the issue. Please address my point.

I'll be happy to address the concept for bobbing deinterlacers after we resolve this issue.

[tritical]

For some reason I feel as though I'm being led into answering a question that will show my immense stupidity, but that has yet to ever stop me :D. Taking mfa's original scenario (extended a little)...

The original progressive sequence:

AB CD EF GH IJ KL MN OP

To create the interlaced (tff) sequence we take:

A D E H I L M P

Now they will get weaved together into frames like so:

AD EH IL MP

Now you start to have to make distinctions about the type of deinterlacer you are using. If you are using a bottom field interpolating (keeps to the top field untouched) sharp deinterlacer. Then it will produce:

AB' EF' IJ' MN'

To assess the quality of the deinterlacer we take the sum of the differences of these pairs:

(B,B') (F,F') (J,J') (N,N')

Now, for sharp deinterlacers, what frames (fields) you compare to have to be adjusted based on what field the deinterlacer keeps (top or bottom). For non-sharp deinterlacers (blending deinterlacers), this test is not fair (if you are testing them against sharp deinterlacers), as I said in one of my previous posts, since the blending will of course lead to differences. Thus you can't compare just any set of deinterlacers (a sharp and itff, a sharp and ibff, a blending), by running them all with this clip, and then comparing each of their outputs against the same set of original progressive frames. Though I don't think anyone was intending to do that.

Also... about the compressibility argument. After thinking about it I will agree with kassandro that compressibility can be used as a measure of quality, but only if the amount of detail retained is used as the first and foremost quality measure. Though I am now pretty sure this is what he always meant. As for the speed issue, I think you'll have a hard time convincing some people (especially on this forum) that speed matters :D

[MfA]

Originally posted by neuron2
And if it isn't, i.e., it's a basic non-bobbing deinterlacer?

Well Im not particularely fond of 2-field to 1-frame deinterlacers ... but we would go from :

A D E H

to :

AB' EF'

and compare :

(B, B') (F, F')

[MfA]

Originally posted by tritical
Now they will get weaved together into frames like so:

AD EH IL MP

I know it is considered normal to do this, but field E belongs no more together with H than it does with D ... to cut down on computations just looking at field H to create a frame containing E is a valid approach, but it is important to remember that is implementation specific and arbitrary. D and H have the same temporal distance from E, when filling up the gaps they are equally important.

This practice is one of the reasons why there is so much fuzzy thinking about interlacing in our little community IMO.

Now, for sharp deinterlacers, what frames (fields) you compare to have to be adjusted based on what field the deinterlacer keeps (top or bottom). For non-sharp deinterlacers (blending deinterlacers), this test is not fair (if you are testing them against sharp deinterlacers), as I said in one of my previous posts, since the blending will of course lead to differences. Thus you can't compare just any set of deinterlacers (a sharp and itff, a sharp and ibff, a blending), by running them all with this clip, and then comparing each of their outputs against the same set of original progressive frames. Though I don't think anyone was intending to do that.

People still use blending?

Anyway, you still get progressive frames out of a blending deinterlacer at the same time reference as the original sequence ... so you can still objectively compare them.

Wether the output of an objective measurement is perceptually relevant is different matter.

Also... about the compressibility argument. After thinking about it I will agree with kassandro that compressibility can be used as a measure of quality, but only if the amount of detail retained is used as the first and foremost quality measure.

Which is a subjective metric. So basically you agree that as an objective measure compressibility isnt very usefull.

[Guest]

Originally posted by MfA
Well Im not particularely fond of 2-field to 1-frame deinterlacers ... but we would go from :

A D E H

to :

AB' EF'

and compare :

(B, B') (F, F') Which proves my point, because A and E are absent from your comparisons. According to this metric, simply tossing fields is the best strategy.

[MfA]

A and E are the odd lines from the progressive frames AB and EF, and also of the reconstructed progressive frames AB' and EF's (which are at the same temporal position as AB and EF). The difference between A and A is obviously 0, as is the difference between E and E ... they are straight copies. Why should they be included in the comparison?

There arent a lot of deinterlacing methods which dont do straight copying of either the even or odd lines for the reconstruction of a progressive frame. Those are values you can be sure are correct, so why mess with them? In theory you could create a deinterlacer which reconstructed frames in between the temporal positions of the fields, which would have to reconstruct both the odd and even lines ... but I doubt they are very good.

[Guest]

With that view, the "best" deinterlacer is now a NOP (no operation), which brings us back to my assertion that this metric is measuring only the degree to which the deinterlacer damages progressive frames. But that is not the same as measuring the goodness of the deinterlacer, which is clearly subjective.

I've made my point as clearly as I can. I'll leave it to the readers now to decide the respective merits of the two positions. Thank you for an interesting discussion.

[MfA]

neuron2, I dont think the clarity you provided exactly represents extraordinary evidence ... yet disagreeing on something as fundamental as this with BBC research (among others) clearly represents an extraordinary claim.

If deinterlacers reconstructed a progressive frame at the same vertical resolution as a fields, then I could see your point. If deinterlacers did not do straight copies of the field to either the odd or even lines of the progressive frame it coincides with in time, then I could see your point. Neither of those are true for the vast majority of deinterlacers though.

A progressive frame coming out of a deinterlacer almost always consist of a field copied to the even or odd lines, and a reconstruction of odd or even lines ... this reconstruction determines the quality, and if we know what those odd or even lines were originally (before they were dropped to create the interlaced sequence) we can take the difference as an objective measure of that quality. It's as simple as that.

A NOP operation cant reconstruct anything, the closest thing is leaving them black which will give huge differences ... weave and interpolation will give smaller differences, good motion compensated deinterlacing will usually give even smaller differences.

[avih]

neuron2, can u pls try to define the purpose of a deinterlacer to you then?

imo, there are 2 options, which overlap to some extent.

1. produce the best subjective visual quality of the reconstructed frames (so there's nothing to measure, except for subjective viewing test).

2. produce reconstructed frames that resemble as much as possible to a theoretical progresive frame taken at the same timestamp as the reconstructed field. this we can measure if we can have both this theoretical progressive frame, and the deinterlaced reconstruction of that frame from an interlaced field. the question is how to create all those relations (specifically, progressive frame and interlaced fields with best possible relation)

imo, they overlap, since obviously (imo) the best subjective reconstruction would be this theoretical progressive frame (highest resolution and most details). therefore, even if theoretically impossible, should set the target for deinterlacers, which should get as close to it as possible.

what happens with most deinterlacers, is that they try to reconstruct as much areas as possible of this theoretical frame (static areas), and interpolate in 1/2 vres for the moving areas. MC deinterlacers try to fill this gap by interpolating location in the temporal/spatial space too, so they better achieve the target (imo) of the theoretical progressive frame.

[Guest]

OK, I'm going to spell it out one last time.

You start with your sequence of progressive frames (always the top line is the top fields in this notation):

A B C D E F G H
A B C D E F G H

You make your pseudo interlaced stream as:

A C E G
B D F H

Now we pass it through a deinterlacer, which for the sake of your argument (though it means we're no longer dealing with the general case), I assume just passes through the top fields and does something to the bottoms:

A C E G
B' D' F' H'

Now you say don't bother about comparing A, C, E, and G. Fine. You will compare:

B' to B
D' to D
F' to F
H' to H

It is obvious that the lowest difference will be when B' = B, D' = D, etc., i.e., when the deinterlacer does nothing but pass both fields through. Your "best" deinterlacer is a NOP according to this "objective" metric.

QED.

[Guest]

The definition of a deinterlacer to me is a process that transforms interlaced video such that it can be viewed on a progressive display without objectionable artifacts. I don't ever speak of the "reconstructed frames". I believe that is a misconception.

Yes, it is subjective, but that doesn't foreclose automating the measurement of some subjective criteria.

[avih]

and u don't think that

a. the best subjective visual quality would be that of the teoretical progressive frame (TPF from now on ;) )

b. deinterlacers actually reconstruct the static parts of the TPF (or more with MC deinterlacers)

?

[Guest]

Originally posted by avih
and u don't think that

a. the best subjective visual quality would be that of the theoretical progressive frame Yes, it would. But the metric as presented *does not* measure how good the deinterlacer guesses at it. I proved that above.

b. deinterlacers actually reconstruct the static parts of the TPF (or more with MC deinterlacers) No I don't agree with this at all.

Here's a question for you. Do you understand and accept my proof above? If not, why not?

[MfA]

Originally posted by neuron2
OK, I'm going to spell it out one last time.

You chose a very confusing and prone to misunderstanding format, let me differentiate between top/bottom "fields" (interpret as odd/even lines for progressive frames).

You start with your sequence of progressive frames (always the top line is the top fields in this notation):

At Bt Ct Dt Et Ft Gt Ht
Ab Bb Cb Db Eb Fb Gb Hb

You make your pseudo interlaced stream as:

At Ct Et Gt
Bb Db Fb Hb

Now we pass it through a deinterlacer, which for the sake of your argument (though it means we're no longer dealing with the general case), I assume just passes through the top fields and does something to the bottoms:

Ill change the naming for the bottom "fields" more radically here, since if it is created for the same point in time as the top it should have the same letter ... the fact that it is computed is still shown by the '

At Ct Et Gt
Ab' Cb' Eb' Gb'

Now you say don't bother about comparing A, C, E, and G. Fine. You will compare:

Ill copy my names from above in here and we get

Ab' to Bb
Cb' to Db
Eb' to Fb
Gb' to Hb

Wow, something stopped making sense right about here.

Why compare the new bottom "fields" to the bottom "fields" from the original sequence at entirely different points in time? This makes no sense.

We should compare :

Ab' to Ab
Cb' to Cb
Eb' to Eb
Gb' to Gb

or in your naming scheme

B' to A
D' to C
F' to E
H' to G

All with the implicit assumption that you take the bottom "field" A/C/E/G ... you almost seem to purposely choose a naming scheme which makes clear reasoning impossible.

[avih]

i did not argue that specific metric. i'm trying to find a common ground on which we all agree, and take it from there.

(i will read through the arguments regarding this method, but since i don't have real field/theoretical knowledge about interlaced camera, i'm affraid i won't be able to comment much, as i can only apply my logic here)

so, trying to find further (to point a) common grounds, do u think there's a practical method to synthesize the relation mentioned above? (TPF and it's derivated relevant field)? is there a way in your oppinion to further extend it to 2 sequences: 1. interlaced sequence of X fields/sec (=X/2 interlaced frames/sec) and 2. the relevant TPFs sequence in X frames/sec ?

[Guest]

I refuted the metric that was presented. Now a new one is being proposed. I regret that I have no more time for this.

In case you've forgotten, you wrote:

-----
Well Im not particularely fond of 2-field to 1-frame deinterlacers ... but we would go from :

A D E H

to :

AB' EF'

and compare :

(B, B') (F, F')
-----

Note that I have merely followed your notation, which you now accuse me of obfuscating.

Here's my proposal. Actually make one of these things! Then I'll be able to show you with your own tool that it doesn't measure what you think it does.

Please ping me when it is available for testing.

[tritical]

I know it is considered normal to do this, but field E belongs no more together with H than it does with D ... to cut down on computations just looking at field H to create a frame containing E is a valid approach, but it is important to remember that is implementation specific and arbitrary. D and H have the same temporal distance from E, when filling up the gaps they are equally important.
Of course.


You make your pseudo interlaced stream as:

A C E G
B D F H

Now we pass it through a deinterlacer, which for the sake of your argument (though it means we're no longer dealing with the general case), I assume just passes through the top fields and does something to the bottoms:

A C E G
B' D' F' H'

Now you say don't bother about comparing A, C, E, and G. Fine. You will compare:

B' to B
D' to D
F' to F
H' to H


The problem is, as mfa pointed out, that in the above scenario you give you would actually compare (your notation is rather confusing since you don't differentiate between top and bottom fields on the original progressive sequence):

B' to A (bottom field of original progressive frame A)
D' to C (bottom field of "" C)
F' to E (bottom field of "" E)
H' to G (bottom field of "" G)

which would of course not favor a NOP deinterlacer. The thing we are forgetting with this comparing fields is that we are still comparing full frames (the frames generated by the deinterlacer to the original progressive frames), but we have reduced it to fields only since if you compare the correct temporal locations (given by the top field that is passed through) the top field difference would always be zero. However in your above scenario, if you did do NOP to the input interlaced sequence and then did the comparison of:

B' to B
D' to D
F' to F
H' to H

(in which case you are taking the temporal moment from the bottom field, which has been untouched) there would be no differences in the bottom fields of course, but the top field difference would no longer be zero. As you would compare

A to B
C to D
E to F
G to H

And I thought this was always the metric we were talking about :confused:

[Guest]

Please ping me when it is available for testing. Thank you.

[MfA]

Originally posted by neuron2
Note that I have merely followed your notation, which you now accuse me of obfuscating.

I never used the same letter to refer to both the top and bottom "fields" of an original progressive frame ... what I said was :

Lets look at the original progressive sequence as a sequence of fields ...

AB CD EF GH

AB are a single frame, A the top and B the bottom "field". You used A for both. Not the same at all.

[Guest]

Since we don't seem to be even approaching any closure on this discussion, I'll simply await your proof of concept. Please ping me when it is available for testing. Thank you.

EDIT: Just for fun, I'll try to find time to code this up this weekend (if not before). Then we'll be able to resolve our differences with real data. I will use the final incarnation of your metric as I understand it.

[MfA]

I am lousy at scripting, Im hoping mf will make a nice function.

Would this work?

orig = AviSource("blah.avi")

AssumeTFF(orig)
SeperateFields(orig)
AssumeFrameBased(orig)
interlaced = SelectEvery(orig, 4, 0, 3)
AssumeFieldBased(interlaced)
AssumeTFF(interlaced)

Deinterlace(interlaced) //insert 2-field to 1-frame deinterlacer, weave first if necessary

AssumeTFF(interlaced)
SeperateFields(interlaced)
SelectOdd(interlaced)

SelectEvery(orig, 4, 1)

Compare(orig, interlaced)

[tritical]

Much like MfA's...

original = avisource("g:\OriginalProgressiveClip.avi").assumetff()
interlaced = original.separatefields().selectevery(4,0,3).weave()
deinterlaced = interlaced.chosenSharpDeinterlacer()
comparisond = deinterlaced.separatefields().selectodd()
#comparisond = deinterlaced.separatefields().selecteven() - for deinterlacers that keep bottom field
comparison = original.separatefields().selectevery(4,1)
#comparison = original.separatefields().selectevery(4,2) - for deinterlacers that keep bottom field
compareyv12(comparisond,comparison,"YUV",logfile="outputlog.txt")

[scharfis_brain]

my thoughts:

orig=avisource("Mvi_0391.avi")

interlaced=orig.separatefields().selectevery(4,0,3).weave()


bobbed=interlaced.doubleweave() # nop processing
#bobbed=interlaced.bob() # stupid bobbing
#bobbed=interlaced.dgbob()
#bobbed=interlaced.kernelbob()

stackhorizontal(orig,bobbed)
#subtract(orig,bobbed)




#for single rate deinterlacers:
#deinterlaced=interlaced.weave()
#deinterlaced=interlaced.bob().selecteven()
#deinterlaced=interlaced.kerneldeint(...)
#deinterlaced=interlaced.tomsmocomp(...)
#
#stackhorizontal(orig().selecteven,deinterlaced) #maybe orig.selectodd()

currently not tested due to CPU incapabilities (no MMX, even a simple bob() doesn't work)

[MfA]

Avih : after checking it out a little more thoroughly you were actually right ... interlaced fields are mostly created by line averaging of the progressive frame, which is equal to a bilinear resize (offset by 1 line between the fields).

I was wrong about not being able to reconstruct a higher resolution version of the image from two non-aliased fields, mea culpa.

The above mentioned method is not a good one however for benchmarking, because deinterlacers almost always reuse one field as is ... rather than reconstructing a progressive frame with half a pixel vertical offset from that field. So the best approximation for benchmarking is still a vertical blur.

[Guest]

I've had a chance to test the idea. I started with Spirited Away and used force film with DGMPEGDec to get progressive frames. Yes, I know it is anime, and the tests should be repeated with various kinds of source material. But this is what I used initially. Then I used MultiDecimate to remove duplicates because often the animator duped frames in low-motion segments. So now I had a stream of progressive frames without dups. By doing selecteven() on this I created the reference AVI for comparisons.

Next, I made the fake interlaced AVI by:

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

I applied various deinterlacers and compared the results to the reference. I'll give some results and then make some remarks.

compare reference to reference: average PSNR 106.53 (thus the max)
no deinterlacer: 29.97
discard field and Lanczos resize: 39.15
KernelDeinterlace(threshold=7) 39.97
FieldDeinterlace(dthreshold=7,blend=false): 39.29
FieldDeinterlace(dthreshold=7,blend=true): 31.92
AlparySoft [area-based search 64]: 27.25 !
TomsMoComp(1,5,0): 41.41
TomsMoComp(1,5,1): 38.43

Remarks:

1. Based purely on the above results with this one source clip, TMC with no vertical filter is the king. But this is misleading because 1) this clip has no static scenes and 2) the picture areas that are static have very little vertical detail at the spatial frequency of combing (anime has large flat areas). Some deinterlacers are specialized to not touch static areas, and their superiority in this regard will not show up with this particular source clip. So, it is very important to use a source clip that is similar to the kinds of videos you want to deinterlace. Also, TMC becomes worse than KD and FD even for this clip when the vertical filter is turned on, so it's easy to inadvertently throw away quality if you are not careful. Of course, TMC can emit some artifacts with the vertical filter off, so you have to decide which thing you prefer, better PSNR or fewer artifacts. I suspect that the advantage of TMC (without filter) for this clip derives mostly from its edge-based interpolation.

In the high-motion/low spatial frequency clips like the one used for this test, the advantage of FD and KD and the like is small compared to simple field discarding. That is not surprising, because there is no detail in the large flat areas to be lost by field discarding.

2. Just because a deinterlacer has a better PSNR, that doesn't mean it has fewer objectionable artifacts. This is something that can be assessed only subjectively by eye.

3. Blending generally reduces PSNR, but it is subjectively preferred in some cases.

4. AlparySoft is declared terrible by this metric. It is worse than just passing the combs through, as far as the metric is concerned. But of course subjectively it is better because the combs are at least removed. I suspect that the bad metric arises from a combination of poor motion compensation, non-existent post-processing for combs not due to linear motion, and the blending mode that it uses.

Conclusion:

As long as the caveats above are respected, it does appear possible to obtain objective metrics for deinterlacers. It is extremely important, however, to ensure that your reference clip for the measurements is similar in nature to the clips you are interested in deinterlacing, and to assess the artifacts subjectively.

These tests should be repeated with other source types, such as natural film (not anime). But the tests presented are sufficient to show that, contrary to my earlier thinking, the idea of objective metrics can be useful. This is especially apparent in the results for AlparySoft, which really is a terrible deinterlacer.