Speed and compression of different denoisers

[N_F]

These are some tests I recently ran on different denoisers I figured I'd share.

Noisy clip: 4000 frames of Sex and the City (NTSC, 4:3)
Clean clip: 4000 frames of Fellowship of the Ring (PAL, 16:9 (2.35))


* = Added on first edit
** = Added on second edit
*** = Last added

Denoiser Time Size

Noisy clip
None 5:33 (100%) 64,0 (100%)
*Unfilter(-5,-5) 5:33 (100%) 56.0 (88%)
*Undot() ´ 5:35 (101%) 61.4 (96%)
temporalsoften(2,3,3,2,6) 5:47 (104%) 62,5 (98%)
Mergechroma(blur(1.3)) 5:48 (105%) 61,4 (96%)
**DNR2() 5:57 (108%) 62.0 (97%)
*TemporalCleaner() 5:57 (108%) 62.0 (97%)
temporalsoften(3,5,5,2,10) 5:59 (108%) 59,8 (93%)
**STMedianFilter(8,15,4,7) 6:04 (109%) 60.3 (94%)
temporalsoften(4,8,8,2,10) 6:04 (109%) 58,0 (91%)
*Deen() 6:08 (111%) 53.3 (83%)
fluxsmooth() 6:11 (111%) 57,4 (90%)
convolution3d("moviehq") 6:14 (112%) 62,2 (97%)
convolution3d("movielq") 6:14 (112%) 59,7 (93%)
**Peachsmoother() 6:28 (117%) 53.7 (84%)
SpaceDust() 6:46 (122%) 54,0 (84%)
****convolution3d("vhsbq") 7:05 (128%) 57.6 (90%)
**SmoothHiQ(7,20,25,230,5) 16:54 (305%) 50.3 (79%)
FaeryDust() 26:17 (474%) 55,6 (87%)
PixieDust() 26:36 (479%) 48,7 (76%)
GoldDust() 26:49 (483%) 40,4 (63%)


Clean clip
None 3:20 (100%) 26,3 (100%)
*Undot() 3:21 (101%) 25.8 (98%)
*Unfilter(-5,-5) 3:22 (101%) 23.5 (89%)
Mergechroma(blur(1.3)) 3:30 (105%) 25,9 (98%)
**DNR2() 3:31 (106%) 26.7 (102%) (!?)
temporalsoften(2,3,3,2,6) 3:34 (107%) 25,5 (97%)
temporalsoften(3,5,5,2,10) 3:42 (111%) 25,1 (95%)
**STMedianFilter(8,15,4,7) 3:43 (112%) 26.2 (100%)
*TemporalCleaner() 3:45 (113%) 25.9 (98%)
temporalsoften(4,8,8,2,10) 3:47 (114%) 24,9 (95%)
fluxsmooth() 3:50 (115%) 24,2 (92%)
*Deen() 3:56 (118%) 22.4 (85%)
convolution3d(movielq) 3:58 (119%) 25,0 (95%)
convolution3d(moviehq) 3:59 (120%) 25,6 (97%)
**Peachsmoother() 4:03 (122%) 24.3 (92%)
SpaceDust() 4:07 (124%) 22,2 (84%)
***convolution3d("vhsbq") 4:23 (132%) 25.1 (95%)
FaeryDust() 12:14 (367%) 23,9 (91%)
GoldDust() 12:45 (383%) 20,5 (78%)
PixieDust() 12:48 (384%) 22,3 (85%)
**SmoothHiQ(7,20,25,230,5) 14:10 (425%) 20.6 (78%)


If there are any conclusions to be drawn someone else will have to draw them for now. I’m having a cold at the moment and I’ve been feeling dizzy all day; my mind is not at its sharpest.

One thing to note though is Convolution3D. It seems to be a common misconception that it’s very slow, but as you can see it’s not.

All tests were run with Avisynth 2.51. Dust with the help of Warpsharp’s LoadPluginEx()

Also, if you’re missing a filter leave its name and setting here and I’ll add it

* Take note of Undot and Unfilter (both by Tom Barry IIRC). How is it possible they hardly affect encoding speed, yet in Unfilter's case (and to much lesser extent Undot) changes the picture's size greatly? It would seem there are hardly any extra calculations done or something like that :confused: Not that I'm complaining... :)

[irasnyd]

If you've got the time, two more I suggest are deen and undot.

I just use them with the defaults:
deen()
undot()

irasnyd

[manono]

Hi-

Nice test N_F. I'd like to see how TemporalCleaner() compares to the rest of them.

[frodoontop]

This test is really helpfull. If you have some time, please look at Unfilter(-5,-5). I use it a lot.

[Valky]

My conclusion is that there is no point using Fairydust anymore on noisy source, cause it takes about same time than Pixiedust().
Or then this might be caused by Warpsharp’s LoadPluginEx().

[Prettz]

Nice test, but can you tell us your system specs too, possibly to compare performance with different CPUs (i.e. athlon vs P4)?

[PerCIVaL]

how about smart smoother HQ ? I use it a lot in virtualdub. you should be able to load it into avs.

Also, I find compression important but quality more so. Smart smoother gives me very good results. So does convolution3d.

[N_F]

I'll try to add all the filters you've mentioned within a day or two.

@PerCIVaL - I haven't had any success with sshq in avisynth yet, but I'll see if I can get it to work.

@Prettz - Well my basic specs are Athlon 1300, 256 MB mem, Win XP. But I don't think it'll do you any good, there are so many other things that makes a difference

[trbarry]

If you are doing an exhaustive set of tests you might also want to include STMedianFilter(8,15,4,7). ( www.trbarry.com/Readme_STMedianFilter.txt )

- Tom

[JuanC]

How about including PeachSmoother ? :) :J

[12monkeys]

Another vote for PeachSmoother, I use it all the time :)

[majerle]

ehmmm...

how about quality ? a psnr confrontation could be usefull
you can use psnr4avi ( http://members.xoom.virgilio.it/_XOOM/majerle/psnr4avi.exe )

Thanks

Andres

[sh0dan]

PSNR doesn't say anything about quality - just as little as compression does. A PSNR test would IMO be a waste of time. ;)

[DDogg]

N_F, even if it would be a totally subjective judgement, I wonder if you might consider assigning a "quality" factor and then plot a graph in Excel so that time, compression and quality (again, I know that is voodoo) could indicate the general trending of the better combinations?

Probably a real pain in the backside for you :)

[Piper]

While we're at it, let's not forget DNR2 as Shayne kindly pointed out in: http://forum.doom9.org/showthread.php?s=&threadid=44335

I've been toying with this filter over the past few days, comparing it with Pixiedust. I'm quite impressed - the results between the two filters are very close to each other with DNR2 preserving more detail (IMHO) while running much faster.

[N_F]

@DDogg - I've been thinking about that, but thing is, I have ~30 clips, and it's damn hard seeing any difference without spending a considereble amount of time comparing them. Still, I'll think about it.


Could anyone tell me what sshiq version to use? There seems to be like 10 different versions made by 10 different people available. I've found one by Sh0dan, but it works in RGB IIRC and involves some kind of vdf inport.

[^^-+I4004+-^^]

numbers really mean less for this kinda comparisson,and for images,you would have to include at least few settings for each filter (yes,peachsmoother and grapesmoother too...hehe)
so it's a tremendous job
for example;there's a source video screenshot,spliced with screenshot after filtering (split screen),this is cropped heavily,but the frame is picked so it had details and some uniform parts too....(this image portion is retained after cropping too)
for every filter/settings there's one such jpeg (very small)....
(i think somone already did such test..with few denoisers)
but as i said too many filters,combinations,numerus settings for each...tough job

[TNM]

Originally posted by Piper
While we're at it, let's not forget DNR2 as Shayne kindly pointed out in: http://forum.doom9.org/showthread.php?s=&threadid=44335

I've been toying with this filter over the past few days, comparing it with Pixiedust. I'm quite impressed - the results between the two filters are very close to each other with DNR2 preserving more detail (IMHO) while running much faster.
Can u pls post which setting of this filter can give close result to pixiedust? :)

[FuPP]

"(i think somone already did such test..with few denoisers)"

It was me :) but pictures showed were not always very relevant (mostly due to a lack of time). Sorry...

"While we're at it, let's not forget DNR2 as Shayne kindly pointed out"

Yes, I'd like to play a little bit with that one. Does anybody have some sample scripts with that filter, to use them as a starting point (and then play with parameters)?

Regards,
FuPP

[PerCIVaL]

@N_F

you should be able to get the latest version here:
http://shelob.mordor.net/dgraft/hiq/smoothhiq.html

As for vdf import, IIRC there is no avisynth version of the filter yet. The page above has detailed instructions how to correctly import the vdf though.

Thanks for the great tests btw!

[Shayne]

Very good test thank you

Sort of keeps our visual testing in perspective.

I do think you are right with regard to trbarry filters sort of the swiss army on filters.

Peace

[sh0dan]

I made a 2.0 version of the SmoothHiQ - it hasn't been updated for a while because there are several better smoothers out there, and I'm currently drafting a new one. Find it via avisynth.org as usual.

@N_F: Great to have all the filters listed here!

[crusty]

N_F:
* Take note of Undot and Unfilter (both by Tom Barry IIRC). How is it possible they hardly affect encoding, yet in Unfilter's case (and to much lesser extent Undot) changes the picture's size greatly? It would seem there are hardly any extra calculations done or something like that Not that I'm complaining...

The effect of Unfilter is pretty easy to explain:
The high speed is basically because it has the same effect as different resize filters on the clip: Different resize filters make the clip look either softer or sharper. The settings you used make the clip look softer.
This also explains the difference in filesize: a softer looking clip compresses much better.
Also, you're using light settings.
Try Unfilter with (5,5) or (10,10). This will increase sharpness considerably and should increase filesize as well.

Why Undot is so fast: I have no idea :D

Also, you don't mention subjective quality of the clip. My experience is that Pixiedust tends to produce artifacts, at least on fast-motion source.

My favorites at this time are Undot, Unfilter, Fluxsmooth and Peachsmoother. I would like to try Deen but I haven't been able to find a version for 2.5. Anyone?

[PerCIVaL]

Originally posted by sh0dan
I made a 2.0 version of the SmoothHiQ - it hasn't been updated for a while because there are several better smoothers out there, and I'm currently drafting a new one. Find it via avisynth.org as usual.

@N_F: Great to have all the filters listed here!

there's a 2.11 version on the link I posted, is that yours or a different one?

[Dark-Cracker]

hi,

@percival
there is in edeen a function that produce aproximatively the same result than smoothHiq. this will perhaps help u waitting sh0dan finish to convert sshiq for 2.5 :) :)

@N_F:
could we have some screenshot or a quality rating to know the quality of the result ?

Ps: nice test, nice work :)

thank u :)
Bye.

[Piper]

TNM & FuPP

I've been using the sample Shayne provided:
DNR2(8,4,6,3,6,3,"dnr1")
and comparing it with
Pixiedust(limit=3)

To my eyes DNR2 using the above settings retains more detail than does Pixiedust(limit=3). I'll need to spend more time getting to know the settings before I decide whether I'll start using it full time. So far I like what I see and it may just give Convolution3D (my mainstay) a run for its money. We'll see..

In the meantime, here again is the translated readme Shayne provided. I'd be interested to hear what others come up with when experimenting with this filter.

DNR2 - Dynamic Noise Reduction 2 (YUY2/RGB32/YV12 (CS_YV12, CS_I420))
Download DNR2 v0.7 (included Source files)

VirtualDub plugin - dynamic noise reduction (transplantation edition of MMX) by Steven Don and Avery Lee

DNR2 (threshY_hi, threshY_lo, threshU_hi, threshU_lo, threshV_hi, threshV_lo and type)


ThreshY_hi Brightness of the pixel of the frame data where one ago was accumulated (Y) threshold value 1
[ Default = 8 ]

ThreshY_lo Brightness of the pixel of the frame data where one ago was accumulated (Y) threshold value 2
[ Default = threshY_hi / 2 + 1 ]

ThreshU_hi Color difference information U of the pixel of the frame data where one ago was accumulated (the Cb) threshold value 1
[ Default = threshY_hi * 3 / 4 (YUY2/YV12): ThreshY_hi (RGB) ]

ThreshU_lo Color difference information U of the pixel of the frame data where one ago was accumulated (the Cb) threshold value 2
[ Default = threshU_hi / 2 + 1 ]

ThreshV_hi Color difference information V of the pixel of the frame data where one ago was accumulated (the Cr) threshold value 1
[ Default = threshY_hi * 3 / 4 (YUY2/YV12): ThreshY_hi (RGB) ]

ThreshV_lo Color difference information V of the pixel of the frame data where one ago was accumulated (the Cr) threshold value 2
[ Default = threshV_hi / 2 + 1 ]

Type " DNR2 " (or "") [ default ] OR " DNR1 "

In the CPU which supports MMX MMX is used.

Recommendation value 7 of threshold_hi - 12

Furthermore, in case of the RGB32, it corresponds to the respective Y:U:V = R:G:B.

Processing summary
Each point of the present frame and the point of the same position of the DNR processing end frame of one ago are compared,
It increases levels. Whether or not the difference within threshold with processing differs.

Case1: Type= " " OR " dnr2 " (default)
Presently the pixel = current of the frame, it makes the pixel = previous of the frame of one ago when
If |current - previous|
If |current - previous| > threshold_lo

Then new = (2 * current + previous) / 3 //current values to approach
Else new = (current + 3 * previous) / 4 //previous values to approach

Else new = current

Case2: Type= " dnr1 "
Presently the pixel = current of the frame, it makes the pixel = previous of the frame of one ago when
If |current - previous|
If |current - previous| > threshold_lo

Then new = (2 * current + previous) / 3 //current values to approach
Else new = previous
Else new = current

As for the DNR1 of the type and the difference of the DNR2, the DNR2 is high picture quality, but it does not become help of MPEG compression,
It becomes help of the high pressure reduction in regard to the point, the DNR1 MPEG compression.

Sample
DNR2(8,4,6,3,6,3,"dnr1")

[N_F]

Originally posted by sh0dan
I made a 2.0 version of the SmoothHiQ - it hasn't been updated for a while because there are several better smoothers out there, and I'm currently drafting a new one.

Glad to hear that. Saves me the trouble of learning the settings of another advanced (as opposed to for instance fluxsmooth which only has 2 parameters) filter at this time.

[N_F]

The original intent of this test was actually 95% aimed at the speed of the filters, I just added the size as an extra bonus.

I don't have time to do any extensive visual tests as I'm graduating from what you'd call high school (I think... 16-18 yrs ?) in ~5 weeks and have a lot of work to do before that. Tell you what, as soon as I'm back in school to a faster connection I'll cut a few seconds from each clip and make them available. Don't know how much good it'll do as a few seconds is rather limited, but it's the best I can do at the time.

I'm glad you found my tests useful/interesting.

[trbarry]

Why Undot is so fast: I have no idea

Partly cause it's written in assembler but mostly because it doesn't do anything except squash stray dots, single pixels that might stand out. It's just a subset of the STMedianFilter() code.

- Tom

[High Speed Dubb]

From the numbers in N_F's test, it looks like something other than the speed of the smoother (disk speed, maybe?) is the real limiting factor for the faster smoothers. It just doesn't make sense that Unfilter or Undot would be instantaneous.

You might want to add in an extra computationally intensive step. That could keep the processor busy enough that smoothing will directly affect the speed.

[trbarry]

I guess I'm assuming in this case we have a mildly noisy clip and we would rather have a softer clip that compresses well. I tested a series of my own filters that I thought might do this, using a 3 minute sequence from the SDTV version of Return of the Jedi, 704x368, 2.35:1, not resized (but should be).

I used the following set of filters, doing the test with fixed quants both with and without all 5 filters.


UnDot() # Cheap, but only marginal help here
STMedianFilter(8,20,4,8) # Remove noise and grain
UnFilter(-40,-40) # Remove sharp edges
FillMargins(0,4,0,6) # Blot any border garbage
DctFilter(1,1,1,.8,.4,0,0,0) # Remove high frequency components


The strong UnFilter() was needed because I'm also using a strong DctFilter() and don't want edge noise, though I'm not sure it had to be that strong. The FillMargins() was needed because I had some garbage at the top and bottom and wanted to keep a multiple of 16. I haven't tested it but FillMargins() is another filter that should run very fast since it only touches the changed bytes and doesn't copy the buffer.

Because I didn't know how the first test was done I tested both with and without the filter pack at both fixed quant=2 and fixed quant=4, with Avisynth 2.5 and Xvid, at Xvid defaults.

But be warned the results are indeed very soft, so this is maybe an extreme case. But it looks like the Q=4 ended up being about 318 kbps. That's maybe not bad for a 704x368 clip, soft but no obvious macro blocks. Though it was mostly not a very high motion sequence.

You can see the space saving benefits of filtering, and DctFilter specifically, tend to diminish as quants go up and quality and size go down anyway.


Denoiser Time Size

Fixed Quant=2
None 2:29 (100%) 24954 (100%)
All 5 Filters 3:30 (141%) 15916 ( 64%)

Fixed Quant=4
None 2:28 (100%) 9042 (100%)
All 5 Filters 3:26 (139%) 6974 ( 77%)



- Tom

[N_F]

Added 4 new filters.

DNR2 and STMedianFilter doesn't seem work well (or they do, depending on how you look at it) on very clean sources.

If you only look at the numbers (haven't even looked at the actual clip yet) Peachsmoother seems very nice.

SSHiQ doesn't have any default values and I don't have the time to find optimals, so I just looked through the readme and tried following the guidelines. If they seem way wrong, add a "better" settings here and I'll add it.

Both Peachsmoother and SSHiQ were run with the help of Warpsharp's LoadPluginEx() as they are 2.0x filters.

If I've forgotten any filter or used a strange setting, let me know.

[High Speed Dubb]

N_F,

What kind of processor and memory do you have? The time results will probably depend a fair amount on that.

The Peach results are a little surprising -- I'd have expected larger file sizes, but faster run times (relative to the other filters in the list).

Since these clips are from movies, did they start out in the YV12 format? It could be that the YV12->YUY2->YV12 conversion took up a significant amount of the processing time.

In terms of size, the Peach takes a significant amount of time to get an estimate of the noise. If either of the clips had a lot of motion, it's likely that the smoother wasn't able to get a decent estimate during the clip, and was smoothing too much. (Its starting values are chosen for over the air reception, not for a DVD.) That could explain why it's giving small file sizes.

[JuanC]

Originally posted by High Speed Dubb
The Peach results are a little surprising -- I'd have expected larger file sizes, but faster run times (relative to the other filters in the list). I agree. I always use Peach for my TV captures, and as far as I remember, it's been considerably faster than c3d or Flux. I haven't looked at compressibility thou, but the image quality is great!. What I always do is selecting a couple of still/"slow" scenes I let it show me its estimates for NoiseLevel and BaseLine so when I finnally encode I mannually set them to avoid "oversmoothing" (and maybe making it faster?).

@HSD: It would be great to have an "autoloadable" version (compiled for AVS 2.5X?) whithout the need for LoadPluginEX(). Thanks, It's a hell of a filter!!;)

[N_F]

Athlon 1300, 256 MB RAM, Win XP.

Yeah, they were originally in YV12. 4 or 5 of the filters (yours are one of them) in the list have a YV12 --> YUY2 --> YV12 conversion, and on top of that LoadPluginEx(), which I don't know how fast/slow it is.

Most part of the noisy clip is an intro, with many fast scene changes and varieting noise. Perhaps that would explain it?

[^^-+I4004+-^^]

i'm running peach (and grape)in pure YUY2 environment,and
when i disable it i see no speed-up in processing speed....
that's how fast it is.....(and i believe it's some sort of DScaler port,so it should be fast...)

didn't tried tom's filters,but when i see how peach "learns" what is noise and what's not(after few frames),it brings a smile to my face every time..hehe

/ivo

PS. i might do DNR2 vs. peach/grape visual test on some captures,if there's some confusion...
i believe i tested DNR2 long time ago and it was not so good...back in VDub days.....

[N_F]

Originally posted by ^^-+I4004+-^^
i'm running peach (and grape)in pure YUY2 environment,and
when i disable it i see no speed-up in processing speed....
that's how fast it is.....(and i believe it's some sort of DScaler port,so it should be fast...)

didn't tried tom's filters,but when i see how peach "learns" what is noise and what's not(after few frames),it brings a smile to my face every time..hehe

/ivo

PS. i might do DNR2 vs. peach/grape visual test on some captures,if there's some confusion...
i believe i tested DNR2 long time ago and it was not so good...back in VDub days.....

When I read this Peach seems very interesting. I very much liked deen, but perhaps I should try Peach more thoroughly

[N_F]

Originally posted by N_F
Tell you what, as soon as I'm back in school to a faster connection I'll cut a few seconds from each clip and make them available. Don't know how much good it'll do as a few seconds is rather limited, but it's the best I can do at the time.

I've changed my mind a bit on this. As there are many clips I would say are quite uninteresting (for whatever reason, doens't mean I think it's bad), I'll cut a longer part from the ~6 most interesting clips. If you're interested in this, say so. If not, don't say anything :) No point in me spending energy on cutting and uploading it if noone wants it.

[sh0dan]

Originally posted by PerCIVaL
there's a 2.11 version on the link I posted, is that yours or a different one?

That one (which I also made) is for Virtual Dub and only works in RGB mode.

[WarpEnterprises]

About the speed measurements:
you get the real filter speed quite well if you add something like
Crop(0,0,8,8)
at the end of the script. Then there is at least no time spent on transferring data to e.g. VirtualDub.

[High Speed Dubb]

Most part of the noisy clip is an intro, with many fast scene changes and varieting noise. Perhaps that would explain it?

Yeah, that could well be the reason for the small files — It probably smoothed those clips too much. (Like any filter which reduces noise, Peach Smoother should also reduce compressed file size somewhat. But that wasn’t a design goal, so I’d be surprised to see it work as well for compression as filters which were meant to reduce file sizes.)

Of course the Peach doesn’t really run instantaneously. From benchmarking with the DScaler version, my estimate is that (with spatial smoothing turned on) it uses about 400 MHz per 60 640x240 fields.

The fastest way to run it is using JuanC’s method — Figure out the baseline and noise level for your video source, then provide those as parameters. That only works if your video source has a constant amount of noise — But that seems to be true for most content.

[N_F]

Originally posted by WarpEnterprises
About the speed measurements:
you get the real filter speed quite well if you add something like
Crop(0,0,8,8)
at the end of the script. Then there is at least no time spent on transferring data to e.g. VirtualDub.

I don't understand this. I used a normal script where I loaded the source, cropped, resized and added the filters. Why would I want to add another crop?

... on second thought, won't Crop(0,0,8,8) crop the picture to a very small 8x8 clip from the upper right corner? Was that the point?

... on third thought (getting tired? :)), I just realised that the filter will be applied to the whole picture while a very small part of the picture will be sent to virtualdub, eliminating that time. That's the point! :)

[WarpEnterprises]

1 - 2 - 3 - you got it :) (btw first I wrote "clip" instead of "script" which was a little sloppy)

Please tell me the differences you see because I was seeing enourmous amounts of time spent on the transfer to VD.

And maybe you need to add a AssumeFPS(100) or such at the end if you system gets up to realtime playback (VD don't previews faster than the clip-rate !)

[Shayne]

Originally posted by trbarry
"If you are doing an exhaustive set of tests you might also want to include STMedianFilter(8,15,4,7)."Are these still your recommended start point i thought i read somewhere these are a bit aggressive and STMedianFilter(8,10,4,7) was recommended.

PS have you jumped a pond lately?

[N_F]

Originally posted by WarpEnterprises
Please tell me the differences you see because I was seeing enourmous amounts of time spent on the transfer to VD.
Is there really any point to this? I mean for me as a regular user I only find the numbers useful in comparesion to others under realistic circumstances.

Wouldn't your suggestion only be of possible interest to the developers themselves, not the 99,9% of the rest of the community?

You can never get rid of the data transfer to VirtualDub (or another program), or can you?

[trbarry]

Are these still your recommended start point i thought i read somewhere these are a bit aggressive and STMedianFilter(8,10,4,7) was recommended.

The second parameter is very forgiving. It probably wouldn't do much damage even at 100, at least in the YV12 version. A previous release also did a small amount of averaging based upon this parm but now it's a pure median filter.

PS have you jumped a pond lately?

Huh? :confused:

- Tom

[WarpEnterprises]

The transfer rate to VD or other apps is constant and not dependent of the filter chain.
So of course you can't get rid of it, but if you want to compare the speed of a (single) filter you must try to minimize all other influences.
The total time needed for one frame is something like:

disc_access + mpegsource + YOUR_FILTER + export_to_VD + display_in_VD

Now if the other numbers are much higher than the time for the FILTER you can't measure it reliably.
E.g. disc access could be a big factor if you would use an uncompressed RGB source, export could be a big one if there is some slow colorspace conversion involved.

So it's well applicable to the general user.

[High Speed Dubb]

Yeah, WarpEnterprises’ suggestion sounds like a good idea to me. A measurement of the total encoding time is only useful to someone with the same configuration (processor speed, memory speed, and disk speed) and running the same script.

With a crop command at the end, you’ll be able to measure the processing time for the filter (mostly) independent of your disk speed and the script. (It’ll still depend on the processor and memory speed, but you can’t get around that.) That will make it easier for people with different computers and different scripts to use your benchmarks, and to compare those values with their own.

It’ll also avoid the misleading time results toward the top of the table. Your question in another thread tells me you’ve been confused by this, yourself —
1) Would you say it's a good idea using undot() in every script one uses (as it doesn't affect speed)?

Any filter which processes all of a frame will have a measureable affect on speed. (Just accessing that much memory takes a significant amount of time — I’d estimate about 120 MCycles for 60 640x240 fields on an Athlon 1.2 GHz machine with SDR memory.) The reason it isn’t showing up in the test is that some other step which is being run in parallel — I’d guess the time to write the result to the disk — Is taking longer than that. The difference will show up once you add in some more video processing steps.

PS: I just remembered — Filter execution time is also going to depend on its order in the script, because of the way memory cache works. So even WarpEnterprises’ test method will have somewhat inconsistent results.

[N_F]

Ok, I think I understand what you guys are saying now. Basically, I should try to remove as many variables as possible, correct?

Isn't it possible many of the filters are optimized in some way for a reasonable resolution? Isn't it possible I'll get strange results from some filters with just a 8x8 picture?


I will try your suggestion on a few appropiate filters. If I get identical numbers (percentage wise, as the speed will be much faster) I'll leave it as it is. If I get different numbers I'll try to update the list.

Does that sound ok?

[High Speed Dubb]

Isn't it possible I'll get strange results from some filters with just a 8x8 picture?

The compression results will be messed up, but the speed measurement should be fine. I think that’s why WarpEnterprises suggested that the Crop run at the end of the script.

Does that sound ok?
;) Yes, certainly. The original tests were okay, too. You did notice something very interesting, there — That if your processing steps are faster than the output steps, then they are effectively free.

I mostly just wanted to squish the idea that any filter (which processes whole frames) can run instantaneously.