Plain deinterlacing or Bob+SelectEvery: what do you prefer and why?

[Chainmax]

huh? dunno what you mean...
motion is only affected, when there are weaving artifacts in one of both.

so try and see yourself.

I already had and SecureBob looked better (with less jagged edges) than TDeint+EEDI2 on the family tape restoration I'm doing.
I got the impression that it looked a bit smoother though, and since you said that SecureBob bobs everything that 'could' be possibly a moving area I was wondering if that could lead to smoothing or if I'm just imagining things

[scharfis_brain]

with your weird converted family VHS it is no wonder. TDeint locks one the telecined fields of this special case, so it tries to enhances resolution by weaving, where none was before.

So THAT is a source dependant special case.
It has nothing to do with our topic here (deinterlacing real interlacing -> non converted camcorder footage)

[Backwoods]

Bobber Encode Time File Size
(min:sec) (MB)
_________________________________________________

MCBob 0.3b 19:86 379

MVBob (14.09.06) 15:26 400

MVBob (April 06?) 10:11 393

SecureBob (14.09.06) 5:50 377

TDeint-EEDI2 5:58 382

TDeint 1:17 378



The results, in terms of relative encoding speed and file size, are pretty similar to those that I posted for the TFF 576i25 YV12 clip earlier in this thread.

How about quality results? Do you feel they were similar or some excelled compared to others?

[CruNcher]

We would need to conduct a objective test at least to find out under standard viewing conditions but i doub't the participants would see a big (or any difference at all) at least between SecureBob and MCBob.

[scharfis_brain]

the benefits of motion compensated deinterlacing will become much more visible on Biiiiig Screens or when doing some slow motion stuff.

Anyways Didée's mcbob is much better in calming down bobbing than any other deinterlacer I've seen.
(maybe except of doubleweave().blur(0,1) LOL )

[Terranigma]

Anyways Didée's mcbob is much better in calming down bobbing than any other deinterlacer I've seen.
(maybe except of doubleweave().blur(0,1) LOL )
Didée, would it be possible to script an even slower, better, more accurate version of mcbob (I don't mind if it takes up to 5 mins to process a frame, lol.) ?

[scharfis_brain]

what kind of inaccuracies are you referring to?

[Terranigma]

what kind of inaccuracies are you referring to?

Honestly none. I was just wonderin' if mcbob could be better :D

[scharfis_brain]

It is a deinterlacer, not an image enhancer (whatever the latter could mean ;) ).

[WorBry]

Any kind of performance data should probably also include your processor model and speed, and the instruction sets it supports. ;)

Well I did state previously that the CPU was a P4 3GHz

Having to use the wife's PC (P4 3GHz, 504MB RAM, XP SP2) right now (when she's not looking :sly: )

In full:

Pentium(R) 4 630 3.00 GHz
MMX, SSE, SSE2, SSE3, EM64T
Core Speed: 2992.6 MHz
Multiplier: x15.0
Bus Speed: 199.5 MHz
Rated FSB: 798.0 MHz

How about quality results? Do you feel they were similar or some excelled compared to others?

Surely people would want to judge for themselves - as they say ‘up-north’ “It’s better felt than telt”. That’s why I put up the reference clips.

I’ve put up a few more short 'test' clips (576i25) sampled from the reference YUV D1 sequences available at

ftp://ftp.crc.ca/crc/vqeg/TestSequences/Reference/

http://rapidshare.com/files/1580597/Test_src3_Musicians_576i25_TFF_YV12_3sec.avi

http://rapidshare.com/files/1581346/Test_src8_Scrolling_Text_576i25_TFF_YV12_3sec.avi

http://rapidshare.com/files/1581954/Test_src9_Rugby_576i25_TFF_YV12_3sec.avi

http://rapidshare.com/files/1582737/Test_src10_Toy_Train_576i25_TFF_YV12_3sec.avi

Like the motor-racing clip they are all TFF and in YV12 (FFDShow-HuffYuv)

I’ve done some comparative tests myself but will let people draw their own conclusions.

Suffice it to say, with MCBob, note the marked reduction in ‘shimmering’ (pattern on shirt of the piano player in the Musicians clip and the Sheep on the wall of the Toy Train clip) to which MVBob, SecureBob and TDeint-EEDI2 are more susceptible. Of course, these aberrations are best observed at 50p and are much less noticeable (if at all) when the outputs are cut down to 25p with SelectEven.

You might also judge the integrity of the numbers and stripes on the shirts of the Rugby Players (e.g. between frames 90 - 110 at 50p). The Scrolling Text clip is a good hunting ground for holes and edge artifacts.

Have fun.

Of course, dont forget to include AssumeTFF before the bobber :D

Edit: Didee - one other thing I might mention is that the last frame of the MCBobbed sequences always seems to mess-up i.e. much residual combing and artifacts

The question also begs the question of what is perceived as ‘quality’ in this context. In subjective terms, surely the ultimate objective is “treatment of interlaced video in a manner that achieves a convincing simulation of 50p progressive footage that is free from motion flicker, discernible residual combing, motion artifacts and structural deformations and which retains as much (original) detail and definition as possible”.

This leaves me wondering whether a valid objective measure might be to take some high quality 50p footage, interlace it and then compare the ‘bobbed’ output with the original source using relevant metrics. I do actually have some samples of broadcast quality HD (1920x1080) 50p footage in YUY2. Any recommendations on how I might ‘correctly’ convert the footage into an interlaced format that would serve as a valid source for such tests (i.e. that avoids misalignments and chroma aberrations)? I’m thinking of first down sizing the 50p footage to 1280x720 (to make it more manageable). Should I keep it in YUY2 or convert to YV12 and then at what point i.e. before or after interlacing? What would be the most appropriate metrics to measure – PSNR (average, overall), SSIM, VQM?

[Didée]

Oh, sure it can get both better and slower. Issues there are enough.
Current version catches most, but not all artefacts from motion compensation, and is not fully as calm as it could be (mo'comp error correction catches also some of the "good" parts ... check the scrolling_text (http://forum.doom9.org/showthread.php?p=895006#post895006) sample to see a complete failure in that respect). And in noisy areas, it turns the noise into a bob()-typical broad noise, where a kind-of noise reduction (by dithering through a minimum of residual combing, à la MVBob) would be possible.
And sometimes there are these big jaggies, in cases where motion compensation happened to be effectively off by one pixel vertically ... difficult to detect at all, because when differenced from a dumb-bob, the difference looks just like a "good" case ...

MCBob currently is lying in the incubator. Let's wait how it will crawl along when the breeding has finished. ;)

[scharfis_brain]

WorBry: you could upload the whole 1080p50 YUY2 file to www.rapidshare.de

if it is far too large to upload, you may use these scripts to emulate a 567p50 and a 576i50 transfer from it:

50p xxxsource("1080p50.xxx")
bicubicresize(704,576)
converttoyv12()

50ixxxsource("1080p50.xxx")
converttoyuy2()
bicubicresize(704,576)
assumetff()
separatefields().selectevery(4,0,3).weave()
convertoyv12(interlaced=true)

save with lossless YV12 HuffYUV from ffdshow or with lagarith or even with RAW YV12 and RAR file compression afterwards

unlike to my common processing, I suggest YV12 here, because it currently is the only color mode supported by Mac Bob ;)

[Terranigma]

Thanks Didée for answering my question. :)

[Didée]

An easy trick for YUY2 wouldn't be a big deal. At the end, in the STT replace mt_makediff with appropriate Overlay("difference"), and similar for the afterfollowing mt_merge. Working it would - to decide if that is *exact* too, is something for what a "scharfes brain" is needed. :D
Doing *all* of that processing stuff with double lanes for YUY2, is so far down in the priority list that I can't even see it. :p

[Blue_MiSfit]

Just a quick question... I'm assuming that this (like mvtools) doesn't work with MT... Is that correct?

Thanks
~Misfit

[Pookie]

No MT with MV :D

[vkamicht]

Just want to throw in my two cents.

I've been trying many many different deinterlace methods to work with PS2 footage, and nothing has really impressed me. My biggest problem with them is detecting static areas, I usually notice artifacts no matter what method I use (unless its some kind of blur or blend, or straight up bob with nothing else)

Mcbob however does an amazing job, and I've switched to it permanently. I have no problem encoding stuff overnight, so time is not an issue for me. Since I'm not too proficient with changing settings, I must say that default out-of-the-box this is the best script I've used.

[Terranigma]

I must say that default out-of-the-box this is the best script I've used.
Aye Aye :sly:

[WorBry]

WorBry: you could upload the whole 1080p50 YUY2 file to www.rapidshare.de

if it is far too large to upload, you may use these scripts to emulate a 567p50 and a 576i50 transfer from it:

50p xxxsource("1080p50.xxx")
bicubicresize(704,576)
converttoyv12()

50ixxxsource("1080p50.xxx")
converttoyuy2()
bicubicresize(704,576)
assumetff()
separatefields().selectevery(4,0,3).weave()
convertoyv12(interlaced=true)

save with lossless YV12 HuffYUV from ffdshow or with lagarith or even with RAW YV12 and RAR file compression afterwards

unlike to my common processing, I suggest YV12 here, because it currently is the only color mode supported by Mac Bob ;)

Actually the 1080p50 source I have in mind to use is one of the references sequences available at vqeg.its.bldrdoc.gov, specifically:

ftp://vqeg.its.bldrdoc.gov/HDTV/SVT_MultiFormat/1080p50_CgrLevels_SINC_FILTER_SVTdec05_/1_CrowdRun_1080p50_CgrLevels_SINC_FILTER_SVTdec05_/

The original frames are in SGI (16-Bit RGB). As you might imagine, at over 11.8MB per frame, the 10 sec (500 frames) sequence took some time to download. There is a command line tool for converting SGI to YUV

http://www.ldv.ei.tum.de/media/files/homes/oelbaum/forschung/mpeg/sgi2yuv.zip

Unfortunately, I have no idea how to use it, so instead I used XnView to convert the images to 16-Bit YUV (UYVY) and loaded them into AVISynth with ImageSequence (from RawSequence plugin). Unfortunately both the source YUV frames (1.93GB file) and YUY2 (HuffYuv) encode (1.49GB) are too large to upload. So I’ve prepared 704x576p50 and 704x576i25 YV12 (FFDShow) clips (first 5 secs) in the manner you described above. As luck would have it the internet connection on the network I’m using keeps cutting, but I’ll try and upload them when I can.

I’ll also post the results of the objective (metric) ‘bobber’ comparisons when I’m done, but I have some priority work assignments right now.

Actually, there is also a 1080i25 version available on the same ftp site, of which I also downloaded the first 2 secs and converted to HuffYuv (and thence YV12). However, when I tried to deinterlace with MVBob, it promptly crashed VDub. On that note, what would be a ‘correct’ method for downsizing a 1920x1080i25 YUY2 source (TFF) to 704x576i25 YV12 ?

[anton_foy]

Would it be possible to make a filter that compares the luma levels of interlace leftovers like this: Different luma combing (http://www.xtreem.nu/jonas/Comb01.png)
Just the horizontal lines and make it recognize them the way it recognises combing then brighten (or darken) every other line going from up to down making an estimate value.

This would get a much cleaner image yet undamaged(if it can work this way properly).
Just a thought that struck me because all my footage get these leftovers from any deinterlacer/bobber.

Im sure there is another way but as I said its just a thought that struck me.:p

[Terranigma]

On that note, what would be a ‘correct’ method for downsizing a 1920x1080i25 YUY2 source (TFF) to 704x576i25 YV12 ?
a resizer + addborders.

Should'nt be too hard to figure it out from there. ;)

[WorBry]

a resizer + addborders.

Should'nt be too hard to figure it out from there. ;)

No, not too hard at all :) but if it means adding borders then the interlaced clip can not serve as a valid source for comparing bobbers against the 704x576p50 clip I prepared. Actually I did manage to deinterlace the 1080i25 clip with Tdeint (without VDub crashing) and found significant misalignment with the equivalent segment of the 1080p50 clip; possibly a by-product of the interlacing method (likely hardware based) used to convert the 2160p50 'master' (also available on the ftp site) to 1080i25.

All things considered then, I'll stick with the approach of using the 704x576i25 clip that was derived from the original 1080p50 source.

Here are the links for the clips:

704x576p50:

http://rapidshare.com/files/2739537/CrowdRun_704x576p50_FFDShow-YV12_5sec.avi

704x576i25:

http://rapidshare.com/files/2736711/CrowdRun_704x576i25_FFDShow-YV12_5sec.avi

[Revgen]

@Didee

I decided to take a look at MCBob and I'm pretty impressed with the way it handled fast motion scenes. However, it can't seem to do as well as MVBob in slower motion scenes like instant replay.

Here's some pics to show what I mean:

http://img219.imageshack.us/img219/7647/mvbobinstantreplaydp7.th.jpg (http://img219.imageshack.us/my.php?image=mvbobinstantreplaydp7.jpg)
Slow Motion: MVBOB doesn't show as many artifacts around the rim or along the bottom edge of the backboard.

http://img219.imageshack.us/img219/540/mcbobinstantreplaynz6.th.jpg (http://img219.imageshack.us/my.php?image=mcbobinstantreplaynz6.jpg)
Slow Motion: MCBOB shows more artifacts on the rim and backboard

http://img219.imageshack.us/img219/5858/mvbobfastmotionwj7.th.jpg (http://img219.imageshack.us/my.php?image=mvbobfastmotionwj7.jpg)
Fast Motion: MVBOB seems to struggle in faster scenes. The court lines are bouncing all over the place.

http://img219.imageshack.us/img219/7272/mcbobfastmotionbz7.th.jpg (http://img219.imageshack.us/my.php?image=mcbobfastmotionbz7.jpg)
Fast Motion: The court lines are now more straight with MCBOB.


Hopefully whatever allows MVBOB to work well with instant replay footage can be implemented into MCBOB without affecting MCBOB's ability to handle the faster scenes as well as it does.

If not, then it's okay. I know you're pretty busy anyway.;)

BTW, if you're interested I can post the lossless clips of these 2 sequences if you want to look at it.

[Alain2]

On that note, what would be a ‘correct’ method for downsizing a 1920x1080i25 YUY2 source (TFF) to 704x576i25 YV12 ?
Sharfis_brain will correct me if this is wrong, but i think it should be:
xxxsource("1080i25.xxx")
converttoyuy2()
separatefields()
bicubicresize(352,576)
weave()
convertoyv12(interlaced=true)
You don't really need to add borders, unless you want to keep the aspect ratios correct but it's not necessary for test purposes. Anyway this script above will give you a anamorphique video, no need for borders if you decode with a 16/9 DAR

[WorBry]

Thanks Alain2. I'm not at home right now, but your script would make sense i.e. reducing the field height to 704/2 = 352.

[Didée]

@ anton_foy
Would it be possible to make a filter that compares the luma levels of interlace leftovers like this:
...
Im sure there is another way but as I said its just a thought that struck me.:p
It's another way, yes, but Vinverse() in effect does pretty much what you want. The old one (script function) is included in MCBob. For the 4 times faster plugin, read here (http://forum.doom9.org/showthread.php?p=896352#post896352). ;)


@ WorBry & Alain2 & Terranigma

No. You should NOT resize interlaced content like this. With bigger resize ratios, it will give noticeable field misalignment.
The correct way to resize interlaced content was explained by IanB >here (http://forum.doom9.org/showthread.php?p=594339#post594339)<.
Alternatively, you could resize with
InterlacedSource .AnyBob() .Resize() .SelectEvery(4,0,3) .Weave()

The pure fieldbased method is technically correct, but will sacrifice quality in static areas.
The bob method will retain more detail in static areas, given that a smart bobber is used that reckognizes static areas.


@ Revgen:
That's most probably a showcase for the general problem of the same-parity motion search + 50%-in-time interpolation method that is used. I know the problem, but it's hard to avoid. Ideally, it would require a very complicated mixed motionsearch mode from MVTools, and I don't even see how that should work.

A sample would be nice, though. Those few slomo scenes I have are rather blurry with little detail, a more sharp scene would be handy.

[Alain2]

@ WorBry & Alain2 & Terranigma

No. You should NOT resize interlaced content like this. With bigger resize ratios, it will give noticeable field misalignment.
The correct way to resize interlaced content was explained by IanB >here (http://forum.doom9.org/showthread.php?p=594339#post594339)<.

Indeed now that I think of it, the script I gave is wrong, sorry :(

[Revgen]

@ Revgen:
That's most probably a showcase for the general problem of the same-parity motion search + 50%-in-time interpolation method that is used. I know the problem, but it's hard to avoid. Ideally, it would require a very complicated mixed motionsearch mode from MVTools, and I don't even see how that should work.

A sample would be nice, though. Those few slomo scenes I have are rather blurry with little detail, a more sharp scene would be handy.

Here's the slow-motion sample. It's a 350MB YUY2 cap using the Lagarith codec.

http://www.yousendit.com/transfer.php?action=download&ufid=41DC470919B2E1F3

[Chainmax]

...


Bobber Encode Time File Size
(min:sec) (MB)
_________________________________________________

MCBob 0.3b 19:86 379

MVBob (14.09.06) 15:26 400

MVBob (April 06?) 10:11 393

SecureBob (14.09.06) 5:50 377

TDeint-EEDI2 5:58 382

TDeint 1:17 378


...

I didn't realize until now, but it really surprises me to see that SecureBob is actually slightly faster than TDeint+EEDI2.

[WorBry]

I didn't realize until now, but it really surprises me to see that SecureBob is actually slightly faster than TDeint+EEDI2.

In the two instances that I have accurately recorded respective encoding times, it would appear so....on my PC at least.

[scharfis_brain]

@Revgen:

1) your clip isn't lagarith YUY2. It is YV12 with faulty converted interlaced chroma.

2) your clip can be restoreed to progressive using a fieldmatcher a la tfm() or telecide().
It is useless to use a deinterlacer here.

It is always a good idea to determine what kind of source you REALLY have! deinterlacers like
smoothdeinterlace(), tomsmocomp(), securebob(), mvbob() and mcbob() are only made for pure (nonconverted!) interlaced footage,
where ever field has its own temporal state.

even blended standards conversions like (60i <-> 50i) cannot be handeld properly by motion compensation based deinterlacers.

So make sure to know which kind of source you want to revert to progressive and choose the appropriate deinterlacer/fieldmatcher.

[Revgen]

@Revgen:

1) your clip isn't lagarith YUY2. It is YV12 with faulty converted interlaced chroma.

2) your clip can be restoreed to progressive using a fieldmatcher a la tfm() or telecide().
It is useless to use a deinterlacer here.

It is always a good idea to determine what kind of source you REALLY have! deinterlacers like
smoothdeinterlace(), tomsmocomp(), securebob(), mvbob() and mcbob() are only made for pure (nonconverted!) interlaced footage,
where ever field has its own temporal state.

even blended standards conversions like (60i <-> 50i) cannot be handeld properly by motion compensation based deinterlacers.

So make sure to know which kind of source you want to revert to progressive and choose the appropriate deinterlacer/fieldmatcher.

1) I recorded the clip from Dscaler using Lagarith, and selected YUY2. I assumed that it worked. Dscaler itself also operates in YUY2 colorspace. I don't know why it wouldn't work correctly. I just assumed that it did.

2) I can assure you that the clip is a true 30i clip. The normal non-slowmo parts of the game are fluid and smooth when deinterlaced with MVBob or MCBob.

It's just that this is a slow-motion sample that had been slowed down by the TV Channel to dramaticize the content. Apparently, what you're saying is that MVBob and MCBob have trouble when this occurs? Okay then I understand you.

[scharfis_brain]

1) I recorded the clip from Dscaler using Lagarith, and selected YUY2. I assumed that it worked. Dscaler itself also operates in YUY2 colorspace. I don't know why it wouldn't work correctly. I just assumed that it did.Lagartith doesn't seem to support YUY2 (it only supports YV12)so it is clear that interlaced chroma becomes destroyed.

2) I can assure you that the clip is a true 30i clip. The normal non-slowmo parts of the game are fluid and smooth when deinterlaced with MVBob or MCBob.
No, it is not! it has LOTS of duplicated fields in it. So it is not true 60i.

It's just that this is a slow-motion sample that had been slowed down by the TV Channel to dramaticize the content.
There are many different ways to produce slow motion.
This one has been made by slowing down 720p60 (or 1080i60) footage by DOUBLING frames. afterwards it has been converted to 480i60. So it effectively has been telecined (like FILM) with a weird framerate ratio.

[Chainmax]

Since I am currently creating a DVD for someone, I decided to make a little test of my own. The following screenshots correspond to the source and to filterchains that only differ in the bobbing method. The idea is that you rate them in ascending order of detail. Once a few replies are given, I'll, disclose which is which.


http://img183.imageshack.us/img183/9390/1qx1.png (http://imageshack.us)

http://img299.imageshack.us/img299/8505/2wn6.png (http://imageshack.us)

http://img183.imageshack.us/img183/1893/3uf6.png (http://imageshack.us)

http://img182.imageshack.us/img182/9215/4tz1.png (http://imageshack.us)

http://img182.imageshack.us/img182/1382/5fs0.png (http://imageshack.us)

http://img299.imageshack.us/img299/453/6ar2.png (http://imageshack.us)

[Didée]

Ah, very insightful. Reminds me a little of "which of these two pictures did use RemoveGrain(1)", when both were postfiltered by a hulken denoiser.

My ranking in terms of "detail" is:

1st place: shared between 1,2,3,4,5,6
2nd to 6th place don't apply.

For me, 1,2,4,5,6 mostly differ in those random differences of almost-aliasing, caused by the postprocessing filterchain. There are a few spots where freaks might get into lengthy discussions about this-or-that pixel ... have fun, I'd consider it rather irrelevant.
In #5, upper border of lower lip smells like MCBob's "2x2" aliasing problem, but not sure.

Perhaps it's different when viewed in motion ... but from only that still, compared to #3 all others pretty much look like the same fiasko. The differences are noise. So just choose the fastest of those bobbers.

#3 is the most pleasing picture to me, btw. :D

[Chainmax]

Bear in mind that the video was reinterlaced, bobbing was used to apply filtering. Therefore, the aliasing in the picture might just be normal interlacing as that was an extremely low motion scene.

[Trixter]

Lagartith doesn't seem to support YUY2 (it only supports YV12)so it is clear that interlaced chroma becomes destroyed.

From the website (and my own experience): "Lagarith is able to operate in several colorspaces - RGB24, RGB32, RGBA, YUY2, and YV12."

[bananacreamandpeca]

If I use this in Aviysynth for a pal 25 dvd source:

SeparateFields
SelectOdd
BilinearResize(384,288)

First 2 lines makes the vertical resolution look squashed.
Then the resizing of the horizontal res. will make it a
good picture again.
But if I do this. selecting odd-lines from the vertical
with no aliasing ( i guess),
could this make round-edges in vertical resolution look strange?

I mean, you do lose information that was stored in the even lines I just threw away?
Am I correct?

[Backwoods]

#3 is the most pleasing picture to me, btw. :D

I agree, even though it is the softest. The text on the man's shirt in the background is too distorted in the other photos.

[CruNcher]

yeah i agree with Didée and Backwoods the 3rd looks the most natural the background isn't oversharped and the small dof preserved.
Backwoods but ehh what man ? :D

[Chainmax]

Ok, here's the general filterchain:

MPEG2Source("X:\wherever\myd2v.d2v",info=3)

ColorMatrix(hints=true,interlaced=true)

Bobbing

FFT3DFilter(sigma=3,plane=3,bw=32,bh=32,bt=3,ow=16,oh=16)

DeBlock_QED()

Crop(0,0,704,478,align=true)
Lanczos4Resize(656,448)

dull=last
sharp=dull.LimitedSharpenFaster(SMode=4,Strength=200)
Soothe(sharp,dull,25)

AddGrain(2,0,0)

AddBorders(32,16,32,16)

Levels(20,1,255,16,235)

ConvertToYUY2()


And the bobbing used in each picture:
Interp = SeparateFields().EEDI2(field=1)
TDeint(mode=1,order=1,type=3,full=false,MI=48,tryweave=true,slow=2,edeint=Interp)
AssumeTFF()
MCBob()
None (source)
AssumeTFF()
MVBob()
AssumeTFF()
TDeint(mode=1,order=1,type=3,full=false,MI=48,tryweave=true,slow=2)
AssumeTFF()
SecureBob()

[MLS]

of course, if you want a guarantee of no artefacts (except aliasing), then bob.selecteven is probably the way to go

Is there a way to deinterlace and completely avoid aliasing? It is far too distracting for me, and tdeint, leak, selecteven, bob.selecteven, etc all seem to suffer from it.

/MLS

[CruNcher]

let me guess Chainmax the fastest was SecureBob ;)

[wonkey_monkey]

MCBob looks fantastic - I'm curious to know, is there one particular part of the script that is slow, or is just that it has to do so many things?

It makes wish there was a distributed version... I have about 30 3GHz machines idling all day ;)

David

[Chainmax]

let me guess Chainmax the fastest was SecureBob ;)

Yup :).



...
It makes wish there was a distributed version... I have about 30 3GHz machines idling all day ;)

David

How do you say "I hate you" in english? ;)

[WorBry]

let me guess Chainmax the fastest was SecureBob ;)

Yup :)

What, faster than TDeint alone? I find that hard to believe.

[WorBry]

OK here’s my contribution to the party fun – ‘Name That Bobber’

Earlier in this thread I posted two test YV12 clips derived from the same 1080p50 source; one resized to 704x576p50 and the other resized and interlaced to 704x576i25


Here are the links for the clips:

704x576p50:

http://rapidshare.com/files/2739537/CrowdRun_704x576p50_FFDShow-YV12_5sec.avi

704x576i25:

http://rapidshare.com/files/2736711/CrowdRun_704x576i25_FFDShow-YV12_5sec.avi

For the purpose of this little subjective quiz, I deinterlaced the 576i25 clip to 50p with 5 different ‘bobbers’ and took equivalent frame shots from each output, as well as the reference 576p50 clip. The ‘bobbers’ tested (all at default settings) were:

MCBob
MVBob
SecureBob
TDeint-EEDI2
TDeint

I also ran parallel series, one with no resizing (i.e. 704x576) and the other resized (Lanczos) to 704x400. Other than this, no filters were included in the scripts (except AssumeTFF before the bobber).

I’ve put up the results in two sets of six frame shots labelled A- F:

704x576

http://rapidshare.com/files/4017406/Bobber_Subjective_Comparison_704x576.jpg

704x400

http://rapidshare.com/files/4017750/Bobber_Subjective_Comparison_704x400.jpg

So, the quiz is, in your expert opinions:

1. How do you rank the six images (A-F) in each set in terms of subjective quality?
2. What subtle differences lead you to this conclusion?
3. Which image do you think you think corresponds to which of the 5 bobbers and the reference 50p source?

Note: the labelling mix in the two sets is exactly the same; I’m not that crafty

When there are a few replies (of the non-four-letter kind) I’ll post the results, together with those of the objective (metric) quality tests that I ran at the same time.

So, with your zoom controls or magnifying glasses at the ready …..’name that bobber’....or for the dyslexics, 'maime that robber' :D

[Revgen]

^You'll only find a game like this in a D9 forum.;)

[WorBry]

Thats why I look nowhere else ;)

[scharfis_brain]

My guess for the first image (full sized PAL)

ranking (from best to worst):
definitive ( d -> b -> f ) -> uncertain ( a -> c -> e )
(uncertein, cause of different types of artifacts that are equal weighted to me)

a = securebob (no residual combing, eedi2 artifacts on the tree)
b = mcbob (no residual combing, fine detail remains preserved)
c = tdeint (residual combing from motion map, stairstepping)
d = original (no weirdnesses, full detail)
e = tdeint + eedi (eedi2 artifacts, same residual combing like in c)
f = mvbob (residual combing due to mocomp, throughpassed eedi2 artifacts)

I'll judge the downsized image later.