Peach Smoother

[High Speed Dubb]

Here is “Peach Smoother.” It is dedicated to an especially yummy peach I had a few weeks back.

http://students.washington.edu/ldubb/computer/PeachSmoother.zip

This is meant as a pure “does it crash” build. This is my first AVISynth plug-in, so I’d like to make sure that I haven’t done anything truly screwy.

Being a stability test, I haven’t enabled any options or included any documentation. To run it, the command is
PeachSmoother()

Basically, the Peach works by looking for good pixels and gathering orange smoke from them. When it has gathered enough orange smoke, it sprinkles that onto the bad pixels, making them better. When the Peach is seeing lots of good pixels, it gets so happy that a small green dot appears in the upper left corner of the image.

Um... Well, I’ll write real documentation once I’m sure it isn’t just crashing people’s computers.

PS: The link has been edited to point to the most recent version. (I noticed that version 0.9a was getting more new downloads than 0.9h)

PPS: Note that this requires SSE instructions (from a Pentium 3, Athlon, Celeron beginning with the Tualatins (~1.2 GHz), or anything more recent).

[sh0dan]

LOL - who needs more documentation than that? :rolleyes: :sly:

It works great, and seems to be a very good temporal smoother, much better than the built in.

The first frame is very often trashed, with strange artifacts, but that's the only problem I've seen. (Try opening in VDubAVS and refresh (F5) at at frame).

This combination does wonders for my noisy DV sourcePeachSmoother()
Convolution3d (preset="movieLQ")
lanczosresize(448,336)

[trbarry]

I don't see any green dots or orange smoke but it does not crash my machine. ;)

I can't really tell what it does.

- Tom

[ajp]

Didn't crash my computer either and the results look very promising on the short clip I tested. Will come in real handy for my DV caps from TV, keep up the good work!

When can we expect a version with parameters? :)

EDIT: I can see some "smearing" or ghosting, not sure how to explain it. Very nice for a testversion though... ;)

[vlad59]

I got no crash too!

But I got a strange effect on a dark blue background which has been transformed in some parts in pure black.

I can send png images if you like !

[High Speed Dubb]

Yay! No crash is a good sign, I think. Thank you for testing it.

My apologies to people with pre-SSE computers. I forgot to post that SSE instructions (from a P3, P4, Athlon, or recent Celerons) are necessary in order to run it. It does check for processor capabilities, so this shouldn’t have caused any crashes. But that would have saved some unnecessary downloads.

The Peach is mostly a temporal smoother, though it falls back on spatial smoothing in moving areas if the signal is very noisy. It’s a port of the “adaptive noise” filter from DScaler, though it has a few extra changes (mainly the spatial smoothing).

I’ll mostly leave the picture quality issues for later, once I’ve got parameter entry and the docs together. The main trick with this filter is patience. It blurs too much until the green dot shows up. You know, not enough orange smoke. ;)

Sh0dan,
I’m not sure about the first frame corruption. That sounds a lot like an uninitialized buffer — but double checking for that looks like everything is initialized properly. By design the first frame should be left through unaltered. Also, I haven’t been able to get a corrupted first frame on my computer. Could you rephrase your description of how to see it? There’s a typo in your explanation which makes it confusing.

[trbarry]

Lindsey -

I've recently taken to using DScaler's Gradual Noise filter on some of my Tivo channels. What is the difference between the Gradual Noise filter and (more Peachy?) Temporal Noise filter?

- Tom

[High Speed Dubb]

Temporal noise averages (75% previous field, 25% this field) so long as the difference is below a threshold. It also has some rounding glitches.

Gradual noise averages between the previous field and the current field using a weighting determined by the local sum of differences — The closer the pixels are, the more weight is placed on the old value at that pixel. It fixes the rounding glitches. (But there’s a small bug in the fdshow version which reintroduced some rounding problems.)

The Peach/adaptive noise works similarly to gradual noise, but uses a more effective scheme to detect motion, making use of temporal and spatial correlation in the motion. It also figures out the appropriate weighting scheme by estimating the noise (aka orange smoke) in the picture.

That’s why I was able to get away with posting a parameterless version — the same setting is designed to work regardless of the noise. But it does make sense to tweak depending on the amount of detail in the picture — The posted version has reasonable parameters for animation, since that seems to be popular in this group.

The FLT_GradualNoise.c and FLT_AdaptiveNoise.txt files have a fair amount of detail about the algorithms. They’re at
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/deinterlace/DScaler/Plugins/

Parameter input seems to be working. Now I just need to write up some documentation...

[neuron2]

>Now I just need to write up some documentation...

Documenting is my favorite part of a project. It is so much easier than coding, testing, debugging.

Don't you agree? :p

[High Speed Dubb]

Well, there are definitely some programs for which the documentation is more complicated than the code.

This isn’t one of those. :) I’ve now got some docs.

The new version, with accessible parameters and a few tweaks, is available from
http://students.washington.edu/ldubb/computer/PeachSmoother_v0_9c.zip

Next up is changing it to properly handle interlaced material.

PS: Edited to put up the new version, which properly checks its parameters.
PPS: Look further down in the thread for a more recent version.

[soulfx]

@High Speed Dubb: Wow, this is really awesome work. You've been able to put a single filter together for what I was trying to accomplish with three seperate filters, nice work :)

I came across a little bug, but not that big of deal. PeachSmoother seems to take any ol' last frame to compare with the current frame. Like when I jump around from a position farther ahead it remembers that frame and tries to adjust it to the frame I land on farther back. It still works for strait through encodes though.

Thanks for an awesome filter. You have my 100% support for this filter. All I do all day every day is TV captures and the biggest problem I have is noise. I'm glad to add this filter to my arsenal for ultimate noise beatdown ^_^

Peace,
SoulFX

[High Speed Dubb]

Glad it’s working well. :)

Yeah, I haven’t yet put in a check for contiguous frames. I should probably figure out about the first frame problem before doing that.

[High Speed Dubb]

Here’s a minor update which allows higher spatial smoothing values. PS:... and now turns off when jumping between frames. (It would be better to turn off just the temporal part of the algorithm, but that would be harder to write.)

http://students.washington.edu/ldubb/computer/PeachSmoother_v0_9e.zip

[High Speed Dubb]

Here’s a more significant update. This version deals properly with interlaced video, averaging only between matching fields.

http://students.washington.edu/ldubb/computer/PeachSmoother_v0_9f.zip

Also, I rescaled the spatial smoothing parameter so that it is really measured in percent of the temporal smoothing. To convert your current value to the new scale, multiply it by 1.23 (yes, really ;) ).

That leaves just a couple small tweaks before I call it version 1.

To Tom, vlad59, and sh0dan (and anyone else, of course) — Now that the filter is a little further along, I’m interested in the picture quality issues. Have the updates fixed the first frame corruption or the black on blue problem?

[vlad59]

@High Speed Dubb

The black on blue problem was solved with the 0.9e release. Gonna recheck with the 0.9f to be sure.

Your suggested settings for cartoon seems to strong for my test I've lowered a little the NoiseReduction parameter to get rid of ghosting.

Very good work.

[JohnMK]

I'm very impressed with my UW comrade. :D

[iago]

@High Speed Dubb

First of all, before I report a few issues I observe in my test encodes (normal movie / average quality DVD / XviD fixed quants 2 and 3 / MPEG2Dec3.dll / Avisynth 2.06), I would like to congragulate and thank you for this very successful filter, which in terms of compressibility gain, quality and speed is really amazing. BTW, I used default values in the test encodes -> PeachSmoother()

Just a possible problem: it seems to cause some sort of instability and shaking with still parts of the picture, both when applying it after resize or before. This is very obvious when I compare the results with and without PeachSmoother. I dunno if others experienced such a problem too, but I just wanted to report it here. (Version 0.9f)

best regards,
iago

[High Speed Dubb]

vlad59,

Interesting — I would have guessed that 0.9b had the fix for it. (That’s where I corrected to allow for Y(black) = 16.) Well, I’m glad it’s taken care of.

iago,

Would those parts of the picture be at the edges of objects or of compression blocks? Do you see any (less obvious) shimmering in the unprocessed source at the same locations?


Yay, Dawgs? ;)

[High Speed Dubb]

Oops — I forgot to comment on some of that.

Vlad59,

Those values were from a flat colored, high contrast cartoon (Justice League). Shaded animation would probably have problems with those settings. I’ll put an explanation of that in the example scripts.


I tried compressing a few quick clips (with HuffYUV), and noticed something sort of surprising. A noise reduction value of 150 allowed only a little more compression than a value of 20. So for saving disk space, it may be that only very light noise reduction is necessary. (But I do think the output looks nicer when noise reduction is in the low 50s.)

[High Speed Dubb]

It’s me again. :)

Many thanks to everybody for the feedback! This makes it much easier to figure out bugs, quirks, tweaks, and defaults. And it’s great to hear that the filter is working well.

Here is version 0.9g . This one enables spatial (but not temporal) smoothing when jumping between frames, and adds a couple speed-ups. You can now get it to run faster by turning off spatial smoothing.

http://students.washington.edu/ldubb/computer/PeachSmoother_v0_9g.zip

This is likely to be the last 0.9 release. Now is a good time to suggest changes to the parameter names, since I won’t want to change them after a 1.0 version.

[iago]

Would those parts of the picture be at the edges of objects or of compression blocks? Do you see any (less obvious) shimmering in the unprocessed source at the same locations? @High Speed Dub

Those shimmering/trembling ;) parts of the picture are both edges and full compression blocks. I can't see any shaking/instability in the source and in the encode without PeachSmoother.

Also, are the defaults of the new Version 0.9g same as the Version 0.9f?

regards,
iago

[High Speed Dubb]

Nuts — That could mean Peach Smoother won’t work well on XviD compressed video.

My suspicion is that the filter is picking up on very low level shimmering in the source, and is interpreting it as motion. That’s the price of having a sensitive motion detector. There’s a similar problem with broadcast video and color crosstalk, but that at least is fixable.

Do you have any way of putting a short (~10 second) clip online for a little while? I can’t be sure of the problem (or possible solutions) without taking a close look at the video.

PS: Yes, the defaults should be the same. But I did rewrite the parameter reading for 0.9g — Did you notice any odd changes?

[iago]

@High Speed Dub

If you give me an e-mail address, I can send a short clip (~10 sec. / ~3mb) displaying the problem.

iago

edit: regarding v0.9g defaults -> no I haven't noticed any problematic changes, I just wondered if the defaults are the same ;).

[High Speed Dubb]

I’ve replied to iago with a private message. (Though people can also find my email address on my web page, or use the URL in the filter help.)

[iago]

High Speed Dubb

I just wanted to confirm if you want the XviD (without PeachSmoother) encoded clip or a part of the source (vob, etc.)?

iago

edit: I'm sending the XviD (without PeachSmoother) encoded clip (~5 mb)

[High Speed Dubb]

Go with what you had immediately before processing with Peach Smoother — That would be the XviD, I think.

[iago]

@High Speed Dubb

After 2 or 3 unsuccessful tries of e-mailing, I give up ;). Each time my server cuts the transfer either half way or delivers an error message. And since no one else except me seems to have or be able to reproduce this problem, then just forget it! ;)

best regards,
iago

[High Speed Dubb]

iago,

Thank you for making the attempt. The filter has only been around for a few days, so other people may well see similar problems. If someone does see an edge/block noise problem, I’d very much like to take a look at it. (But do send an email or private message in advance — I don’t want my inbox hit with multiple huge messages.)

[Rrrough]

Hi Lindsey,

here you can see an example for the problem attached as screenshots.
clip was compressed with XVID - mostly default options.

my script was :
MARC's MPEG2DEC - no pp
CROP()
LANCZOS RESIZE
PEACHSMOOTHER() - no options used

peachsmoother v0.9c was used.

hope this is of any help.

cheers

attachments
pic 1 - with PeachSmoother
pic 2 - without PeachSmoother

[High Speed Dubb]

Rrrough,

Could you send me a video clip of that? A still will show the problem, but not the cause.

[Rrrough]

sure, how many frames would you need ? it's a high motion clip with 1500 frames resulting in an email-unfriendly 20 megs...:rolleyes:

cheers

[High Speed Dubb]

Yeah, that’s the problem with a feedback-based filter like this — It takes a pretty long clip to figure out what’s happening.

That it’s a high motion clip already makes me slightly suspicious — 25 seconds of high motion stuff may not be enough for the filter to get a good read on the noise level. But that would tend to cause blurring, not shimmering.

20 MB will probably get rejected by the server here. Do you have a place where you could upload it? Barring that, could you mail me a choice 8 MB from a 10 second clip?

[High Speed Dubb]

Here is another 0.9 release. I thought of an easy-to-add feature, and didn’t want to wait until the v1.0 release time.

http://students.washington.edu/ldubb/computer/PeachSmoother_v0_9h.zip

This version allows three new options. “Estimates” shows the filter’s current estimate of the amount of noise (measured in expected absolute difference per pixel) along with the lowest amount of noise seen in the picture. The other new options (NoiseLevel and Baseline) allow you to specify the noise level instead of estimating it. So you can use the Estimates display to figure out the amount of noise, then use that amount to choose the NoiseLevel and Baseline for the next run.

[soulfx]

Could the initial noise estimates be set lower or to zero when first starting the video stream? Either that or disable temporal smoothing until a stable noise estimate is reached?

When first starting up videos with high amounts of motion I got a really bad temporal smear for the first couple of frames until the auto estimation kicks in and lowers the values and/or it figures out that it shouldn't be using temporal filtering.

As far as shimering and stuff goes maybe this could be prevented by implimenting a noise filter for the motion detection. I haven't noticed any type of shimering, but I don't use XviD for sources, just MPEG2 interlaced.

[magnanimous]

Looks like a great filter but has anyone got it to work within DVD2SVCD, when it gets to video encoding (cinemacraft) it says the resolution isn't supported, hope sombody can help.

[High Speed Dubb]

soulfx,

The difficulty isn’t that the filter starts with a high noise estimate. The problem is that it starts with no confidence in its initial estimate.

That’s on purpose, of course, since its initial estimate is just an arbitrary amount. The bad news is that the Peach will accept any signal — even a poor signal which is from motion rather than noise — until a better signal shows up. PS: Unfortunately, it isn’t possible to know what is a good or a bad signal in advance, since that is measured relative to the other signals which have been seen. (That’s a trick which allows the filter to make use of weak signals from video with bad interference.)

There are a few of ways out of the problem. You can use the new Estimates option to read a good NoiseLevel and Baseline value, and then run the filter supplying those values. If there is some uninteresting material before the start of the video, you can include a little of it, and cut it out later. The Peach will be able to use the extra video to get a noise estimate. Or you can start the processing in the middle of the video in a stationary part, and process the moving part afterward, once a good noise estimate has been found.

PS: It already uses a noise filter for motion detection. I would argue that temporal noise filtering and motion detection are essentially the same problem.

magnanimous,
I’m not familiar with DVD2SVCD, so I’ll have to leave that question to someone else. But this filter doesn’t change the output resolution, so I’m not sure where the problem might have come from.

It does require that the source video have a (pixel) width which is evenly divisible by 4 — It is written to work with odd widths, but I haven’t tested that yet, so it’s currently disabled.

[Rrrough]

@lindsey:

you have (hopefully:confused: ) mail

hmmm, I think something went wrong with the picture attachments, so I will try once more with the peachy one...

[indy69]

I have just tried the filter in dvd2svcd. When i used the filter with no options set (peachsmoother()) it worked ok. When I tried with some options set it came up with a resolution error. I think my syntax was wrong. Is there anymore information on what syntax to use.
Thanks

[High Speed Dubb]

The syntax is described in the filter docs, and there are a few examples in the accompanying script file. Could you copy your script into a post, and give the exact text of the error?

[High Speed Dubb]

Rrrough,

That clip has constant fast motion. That means the filter didn’t have a chance to estimate the noise, and is blurring too much. Take a look at my response to soulfx for some hints on how to avoid that problem.

[Rrrough]

well, blurring is ok, but where's this blocking/trembling coming from ?

cheers

[High Speed Dubb]

Hmm... I didn’t notice any blocking or trembling in the clip you sent me. Where should I look for it?

(The obvious artifacts in the picture you posted there are from blurring — they’re left over from the previous frame.)

[Rrrough]

next to lara's nose and mouth, looks like a block here. maybe it's my monitor. didn't notice that it's from previous frame, sorry then. gonna play a little with the settings.

cheers

[High Speed Dubb]

Yep, it’s left over from the beige curtains.

[indy69]

Using the filter with dvd2svcd i can get these 2 parameters to work.

[AVISYNTH_BicubicResize with PeachSmoother filter]
0=Loadplugin(!PeachSmoother.dll)
1=PeachSmoother(^NoiseReduction,^Stability,)
2=BicubicResize(^TargetWidth,^TargetHeight,^b_value,^c_value)
3=AddBorders(0,^BorderTop,0,^BorderBottom)
!PeachSmoother.dll=D:\Dvd2svcd\peachsmoother.dll
^NoiseReduction=50
^Stability=25
^b_value=0.33
^c_value=0.33

I was just wondering how to get the spatial values to work.
When I add ^spatial to the script with any value I get a resolution error which normally means there is something wrong with the syntax.

[High Speed Dubb]

I haven’t used dvd2svcd, so take this with a grain of salt. But I do have a hunch about the problem.

It looks like you’re specifying the parameters by position in the command, rather than by name. There are probably two ways to solve the problem.

You can specify the parameters by name rather than by position. I strongly recommend that — It’s better to use named parameters for all but the simplest commands. (That way your script doesn’t depend on the hard to remember parameter ordering.) So the command would be (I think)

1=PeachSmoother(NoiseReduction = 50, Stability = 25, Spatial = 80)

Alternatively, you can use the correct order for the options. The option order is:
NoiseReduction, Stability, DoSmoothing, Smoothing, Dot, Estimates (which I plan to rename to Readout), NoiseLevel, Baseline, Debug

Anyone who is familiar with dvd2svcd is welcome to correct me on my syntax.

[jarthel]

Very fast temporal/spatial smoother!!! more than twice as fast as convolution3d and 2.5x as fast as SSHiQ. Will know the results in an hour.

Is there any chance you can add SSE2? I can test it for you if need be. :)

thank you.

jayel

ps. I deal mainly with anime. :)

[High Speed Dubb]

Ha! In DScaler, the Peach’s twin (adaptive noise) is the slowpoke. And the AVISynth version is even slower. I’ll eventually move DScaler’s gradual noise over to AVISynth — That one is genuinely fast.

Peach smoother is only barely a spatial smoother. The next release (which is looking extremely nice) will be making the spatial smoothing even more specific to moving areas.

[jarthel]

Bad results is what I get after trying peachsmoother. moving scenes have trembling (dunno the right term). Also it's bigger than just using temporalsmoother(5).

But it is in its infancy stage so there is room for improvement. :)

jayel

[High Speed Dubb]

Remember that you can’t run it just on a moving scene — in order to work, it first needs to see a still scene in order to estimate the noise. After that, it can handle moving material just fine.

[jarthel]

It's an anime so there must be some still scenes in it. any other idea?

thanks

jayel

[High Speed Dubb]

Could you help with a few diagnostics?

There’s an easy way to tell if the clip has enough still material to estimate the noise. Just use the Dot option. If the dot doesn’t show up in still scenes, then the sequence has too much motion to figure out the noise.

Could you say what you mean by trembling? Do you mean that there appears to be noise behind moving objects? That edges of objects or macroblock boundaries don’t have as stable a color as their centers? That there is blurring within objects, or behind moving objects? Or that the whole scene appears to shake?

Also, was your clip compressed before you processed it? Recorded on a VCR? Is it fairly dark?

[soulfx]

One thing I really like about this filter is it's ability to pick up on motion and edges in motion and not temporal filter them. One big problem I had in the past was whenever a scene went into motion the temporal filters I was using caused the edges to disapear and/or have really strange temporal smoothing effects.

This extra ability to pick up on motion and edges better has helped out a ton, but it also causes it not to filter the edges, thus causing them to "shimmer". The one way I found that cuts down on the this is to keep NoiseLevel and Baseline values higher as auto Estimation seems to estimate too low of values for my taste.

High Speed Dubb,
Would it be possible to add a feature that shows what the filter is detecting as motion?

[High Speed Dubb]

Just to be clear — Are you seeing the shimmer on the edge of moving objects, or on the edge of stationary objects? Those are two different problems.

If it’s the former, then you’re seeing what I call the “noise shadow” — the area in which the filter avoids averaging because of recent or nearby motion. Good news is that this will be much subtler with the next release.

If it’s the latter, then it’s color crosstalk, and what you really need is a comb filter.

Yes, it would be possible to output the motion estimate. What kind of format would be useful for it? Internally it’s an array of Probability(motion), where probability is measured in 0x10000 fixed point.

[soulfx]

The shimmer appears mostly with movement. I don't really mind the shimmer as you mentioned it avoids averageing it because of recent or nearby motion, which in terms of noise reduction is good, because if it did it probably would wipe that edge out.

If the motion estimate could be figured as a percentage of motion in the current frame and output that way it could help determine which frames it's detecting as having high amounts of motion and which frames its seeing as low motion. Really anything, even the probablity number could be output, as something more then nothing would be a big help.

Maybe the motion detection could also be output as an overlay over the image. Have it display black wherever it detects motion. That might be a bit more involved then just outputting a number though.

[jarthel]

My problem is the same with solfx. The trembling/shimmering is on the edge like outline of the characters. And it only happens on movements. I'll try your suggestion of "dot=true".

Also my source are dvd vobs.

jayel

[High Speed Dubb]

Thanks to jarthel and soulfx for narrowing down the problem. I agree — that’s the most distracting aspect of the filter. But as soulfx noticed, it’s there for a reason.

Since version 1.0 is aimed specifically at this problem, I’ve put together a release. It may or may not help with MPEG2 material — Hopefully MPEG2 encoding doesn’t introduce any artificial motion.

http://students.washington.edu/ldubb/computer/PeachSmoother_v1_0a.zip

Version 1.0a reduces the appearance of noise on the edge of moving objects. It’s done through a couple tricks which let me cut down on the noise without blurring the edges. One trick is that the spatial smoothing is much more specific to moving areas than before, and can now safely be used at higher levels without messing up stationary parts of the picture.

The other is the result of some analysis of how the expected change at a pixel is altered by past averaging at that location. Areas which had been moving but now appear to be still are expected to have a larger variance than areas which have been still for a while.

Also, the formula for calculating the probability of motion got a small tweak to more closely resemble the calculated optimum.

The name of the estimates option has been changed to readout. That’s because I kept forgetting the old name.

Because of the algorithmic changes, you’ll find that you can drop your v0.9 Noise Reduction setting by about 10 points. Also, the noise readout got a small recalibration, which means that your NoiseLevel and Baseline estimates should be multiplied by 0.9192 before use with v1.0a

[jarthel]

will test later. How about SSE2? :)

thank you Lindsay. :)

jayel

[manono]

You don't need SSE2 optimizations. Your computer's too fast already.:)

[jarthel]

SSE2 optimizations if implemented by Lindsay is free. so why not? :)

jayel

[High Speed Dubb]

No, SSE2 isn’t on the slate. It would be complicated. And it would probably lead to artifacts unless each 8 pixel block were broken up into two 4 pixel blocks, which would toss away any speed gain.

My time is free for you, but has a cost. I’m a poor low level optimiser, but good with algorithms. You’ll get more useful stuff from me if I don’t waste my time with tweaking assembler instructions.

Besides, if you want speed, you’re much better off with the Grape.

[jarthel]

I didn't realize that SSE2 optimizations is lot of work. So I apologize for my comments. :)
-----------

Regarding the latest version, it seems to work very nicely. No more "trembling". Just a question regarding "dot=true". Are the dots random red/blue dots across the screen? Cause that's what I'm seeing.

I also tried the avs script with Xvid and it looks good too. I was using the latest stable build by Umaniacs (dated oct-2002).

Here's a filesize comparison between 3 encodes:

using Divx5 temporalsmoother(5) - around 250mb
using Divx5 PeachSmoother (NoiseReduction=50,Stability=25,Spatial=100,dot=true) - 290mb
using Xvid PeachSmoother(NoiseReduction=50,Stability=25,Spatial=100,dot=true) - 318mb

Once again thank you.

Jayel

ps. what is Grape?

[soulfx]

Grapes are yummy ^_^.

The green dot is a little 1-2 pixal dot (it took me a while to actually see it as I was looking way up in the upper left hand corner). It's about 3-4% away from the top left corners. It only shows up when there is little to no movement in the picture and is just their for debug purposes.

[High Speed Dubb]

jarthel,

Apology accepted — Yes, depending on the algorithm, SSE2 can be a fairly difficult change. And don’t even think about YV12 for this — It would probably be faster to just convert back and forth.

It’s also good to hear that the trembling is reduced — that was the main goal of the recent changes. (That and reduced spatial smoothing.) Now let’s see whether soulfx (or other people) find that edges are now blurred... I don’t think they will be, but it’s always worth checking.

Like soulfx said, Dot should just give a single tiny green dot toward the upper left of the picture. Red/blue dots sound like some kind of noise or artifact. Either that, or you turned on the debug=true option.

About the file sizes — Yeah, this wasn’t really designed for file size reduction. It’s just aimed for picture quality. Stuff like keeping low level noise is bound to increase the compressed size.

It looks like you’ve already found the Grape. ;)


soulfx,

About your earlier suggestion — I’m not sure what you mean by ‘percentage of motion.’ But a picture of Probability(motion) should still be reasonably informative (Y = Probability(moving)*256). Alternatively, I could enable a debugging setting which I’ve been using for algorithm evaluation. That flashes all pixels with Probability(motion) > threshold pink once per second.

I’ll fix up the docs on the Dot option so people won’t have to hunt for it so much.

[soulfx]

To tell you the truth I wasn't quite sure what I was trying to say about the percentage of motion either. The picture of the probability of motion sounds like a great idea and would help me and others see what the filter is actually seeing as motion.

I haven't seen any bad effects so far with edges under motion. I've got some tests to run tonight and I'll see if anything comes up.

It's sort of funny. You kept forgetting the old name of Readout (Estimates) and now I keep forgetting the new name for it.

[^^-+I4004+-^^]

didn't tested thoroughly but first tests look fine!
also some AWESOME(!) documentation you got there (Peach)

nice work!

[High Speed Dubb]

And now on to version 1.0b. This one is a minor update. It adds a new diagnostic called ShowMotion, which shows the internal motion estimate mixed in with the picture. Black is (inferred) stationary area, while white is in motion.

Also, Stability settings of less than 0 are now allowed. And I fixed a few documentation mistakes — I forgot to change the listed defaults in the help file to reflect the changes in 1.0a.

http://students.washington.edu/ldubb/computer/PeachSmoother_v1_0b.zip


It's sort of funny. You kept forgetting the old name of Readout (Estimates) and now I keep forgetting the new name for it.

Naturally. :( Well, I’ve enabled “estimates” as an undocumented synonym for readout in version 1.0b.

PS: And thanks for the compliment on the documentation. I tend to make the help file a pretty high priority, since these interfaceless filters can otherwise be pretty hard to understand.

[soulfx]

The new ShowMotion option works great. It really helps get an idea what settings to use for NoiseReduction. It also helps me figure out what frames to look at when judging spatial and temporal filtering settings.

I tried the Readout (Estimates) and it doesn't show anything anymore. Neither Readout or Estimates output any values onto the video.

[High Speed Dubb]

Very strange — I just downloaded it myself and the readout is showing up okay. I’ll take a close look at the parameter parsing there to see if I got something messed up.

I guess my preference for NoiseReduction is to use the normal output rather than the motion display. Internally, the filter uses various functions of the motion probability in its calculations — For example, it’s squared before determining the amount of motion when deciding where to apply spatial smoothing.

[soulfx]

Oops, It's my fault. I just realized why I wasn't getting any values to show up. Since Peach is faster then my older noise filters I've moved it before crop and resize. So it was cropping out the Estimates. Sorry about that :/

[High Speed Dubb]

No problem — It’s remarkably easy to get these sorts of issues confused. My first publicly available code was a port of a regular expression engine, for which about half of the seeming bugs — including those I found myself — were due to misunderstanding how regular expressions were supposed to work.

[High Speed Dubb]

Here’s a trivial update. This moves the readout a little further from the edge of the screen, so it won’t be so easily lost when cropping.

http://students.washington.edu/ldubb/computer/PeachSmoother_v1_0c.zip

[soulfx]

I was wondering if high and low NoiseLevel and BaseLine limits could be implimented. Something that would allow for auto noise determination, but would keep the filter from determining noise below or above limits set by the user.

The filters auto determination of noise works great, but there are sometimes it goes too high or too low. Like when there is smoke then the filter tends to think the smoke is part of the noise (thus raising it's determination of NoiseLevel and BaseLine above it's normal values). A High Estimate Limit would be useful in situations like this.

I've been using the filter sort of successfully for removing some crosstalk, but in order for me to do this I have to manually set the NoiseLevel and BaseLine a bit higher then what it normally auto Estimates. A Low Estimate Limit would allow it to not drop below a certain estimate value, but would allow for it to increase its Estimate if it needs to.

It's just an idea for more tweak-ability and fine tuning. Don't let it take away too much time from any work on a comb filter ;)

I can't thank you enough for all your excellent work you've done with this filter.

[jarthel]

isn't asking for more parameters make it harder for average joes to use the filter? :) There must be a line between usability and complexity. :)

jayel

[High Speed Dubb]

That’s been my opinion with the DScaler filters — All those options get confusing. That’s less of a problem with AVISynth, though, since the weird stuff can all just be ignored by people who don’t want to mess with it. I’ll probably split the settings into “important” and “esoteric” in the docs so people will know which part they need to understand.

Yeah, smoke and fog are definitely bad news for the Peach. It’s sort of fun to watch it try to cancel out fog, but I won’t claim that’s a feature. User set maximum/minimum values isn’t the most elegant way to take care of things, but it’s a possibility.

Part of the problem is that the filter was designed for DScaler, where the user may be switching back and forth between channels with different noise levels. So the filter needed to be tolerant of dramatic noise level changes. That isn’t as necessary here, so I can probably improve things some just by making it less prone to believe wild fluctuations.

[FuPP]

@Lindsey

Any chance to get Peach working with avisynth 2.5a ? That one is probably the best I've seen (I mean visual quality)

Regards

FuPP

[High Speed Dubb]

It’s just waiting for me to have the time to get the 2.5 API and port it over.

At a guess, it’ll still be faster in YUY2 than YV12, even if you need to convert the formats. Has anyone compared the YUY2 and YV12 versions of TemporalCleaner for speed? That’s probably the Peach’s closest algorithmic relative, though Peach Smoother should lose even more speed with YV12.

[SansGrip]

Originally posted by High Speed Dubb
Has anyone compared the YUY2 and YV12 versions of TemporalCleaner for speed? I haven't, but whether or not Peach will lose speed depends on how "interconnected" the different components are. If it's not possible to apply the filter to each separately then you probably won't gain any speed.

Out of interest, why do you think it would be slower?

[High Speed Dubb]

It uses Y and UV changes to jointly affect both Y and UV. So it’s pretty much a worst case for a planar format — The best thing to do (for picture quality) would probably be to sort the Y and UV values into a temporary structure, process them, and sort them back into their individual components again. That would be pretty similar to converting to and from YUY2 around the filter.

The alternative would be to do a ground up rewrite of the algorithm. Bleah. :( Peach Smoother uses a private field/frame sized structure to save cumulative evidence for motion. That could be used to allow the chroma blending to depend on the luma changes (but not vice-versa, unfortunately). The result wouln’t be quite as good as for YUY2, but it might be faster.

Then again, that might not even be faster, since it would need to access the motion evidence stucture twice. It’s a big structure, so that could mean twice as much access to memory outside the L2 cache.

[natami]

@High Speed Dubb
hello, i just got ahold of your amazing smoother a few days ago (i must have been living under a rock)...it is exactly what i was looking for, and fast!, just wanted to add my 2 cents...great job :)

[neuron2]

Originally posted by High Speed Dubb
[B]The alternative would be to do a ground up rewrite of the algorithm. Bleah. :( Peach Smoother uses a private field/frame sized structure to save cumulative evidence for motion. That could be used to allow the chroma blending to depend on the luma changes (but not vice-versa, unforunately). The result wouln't be quite as good as for YUY2, but it might be faster.[b]
It's not an extensive modification to just run your inference engine on all three planes and OR (or otherwise combine) the results for your decision.

[High Speed Dubb]

That would require two passes over the data — Once to detect differences, and once to apply the result. The YUY2 version manages with one pass, so it will probably be faster.

It would be possible to simultaneously walk through the Y, U, and V planes with appropriate offsets, combine the information, and then apply that to each component. That’s the combine->process->separate method I was suggesting. My hunch is that -> YUY2 -> process in YUY2 -> YV12 would often be faster, since combining and separating would mean that three times as much data would be accessed at once. Also, it would take a lot more register shuffling.

Beside, I don’t want to maintain two very different versions of the code. That would be icky.

[SansGrip]

Originally posted by High Speed Dubb
It uses Y and UV changes to jointly affect both Y and UV. So it’s pretty much a worst case for a planar format Yep. You'll at least have to maintain a bunch of parallel pointers and that's a pain in the neck.

The best thing to do (for picture quality) would probably be to sort the Y and UV values into a temporary structure, process them, and sort them back into their individual components again. That would be pretty similar to converting to and from YUY2 around the filter. Well, except that the converstion filters are already MMX optimized :).

The alternative would be to do a ground up rewrite of the algorithm. Bleah. :( Ouch. Definitely one to try to avoid.

[FuPP]

hem, so what is your decision, doctor ? ;)

[terwin]

Will there be a compile for Avisynth 2.5 in the next time? It’s such a great filter and I can’t use it. :(
I'm also satisfied with the yuv2 version. :D

Thx terwin

[jarthel]

/me wants a avisynth2.5 version :)

[zyrill]

yes, that would be just so great! please make a 2.5 version... PLEASE!

[kilg0r3]

me2

[kaitsuburi]

*bump*

I am a Peach fan too.

-kaitsuburi

[trance]

NO AVS 2.5 version yet? I hear great things about it but can't use it since I have Avisynth 2.5...

[Aktan]

Try using LoadPluginEx plugin to use 2.0x plugins in 2.5

[kilg0r3]

could we speed processsing by feeding only luma to peach?

[zyrill]

loadpluginex doesn't work with peach... the output is completely crap...

[Wilbert]

I assume you converted to YUY2 before feeding to Peach?

[homersapien]

Originally posted by Aktan
Try using LoadPluginEx plugin to use 2.0x plugins in 2.5

LoadPluginEX causes sever problems on my systems, so here's another vote for a 2.5 version :(

[YY1020]

Is it for AviSynth 2.52??

[tempetai]

Originally posted by homersapien
LoadPluginEX causes sever problems on my systems, so here's another vote for a 2.5 version :(

Just make sure that you don't put LoadPluginEX inside avisynth's plugin directory.

[stevendm]

Peach looks very good. Does it work properly with avisynth 2.5?

Thanks

[stickboy]

See this thread:
Peach, Grape, and Guava for AVS 2.5.x (http://forum.doom9.org/showthread.php?s=&threadid=58674)