View Full Version : Deinterlacers and Settings Response
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.
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.
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
23rd May 2004, 19:34
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.
"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
23rd May 2004, 20:44
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.
"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
23rd May 2004, 20:58
MfA: best explantation, I've read so far!
that is exactly, what I've tried to say all the time....
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.
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 ...
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.)
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
24th May 2004, 01:55
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
24th May 2004, 07:53
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
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')
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
24th May 2004, 12:35
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.
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
24th May 2004, 14:11
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.
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.
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
24th May 2004, 20:09
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
24th May 2004, 20:14
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.
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
24th May 2004, 20:29
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?
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.
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
24th May 2004, 20:49
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
24th May 2004, 21:47
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
24th May 2004, 21:58
Please ping me when it is available for testing. Thank you.
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
24th May 2004, 22:14
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.
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
25th May 2004, 03:14
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
25th May 2004, 13:14
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)
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
31st May 2004, 19:34
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.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.