FluxSmooth

[SansGrip]

Here's a new spatio-temporal smoother I wrote today based on ideas that came to me developing NoMoSmooth.

The source code is available. Here's the description from the documentation (http://www.indeus.com/sansgrip/avisynth/FluxSmooth-readme.html):

One of the fundamental properties of noise is that it's random. One of the fundamental properties of motion is that it's not. This is the premise behind FluxSmooth, which examines each pixel and compares it to the corresponding pixel in the previous and last frame. Smoothing occurs if both the previous frame's value and the next frame's value are greater, or if both are less, than the value in the current frame.

I like to call this a "fluctuating" pixel, then I like to wipe that pixel from existence by averaging it with its neighbours. This is (by default) done in a spatio-temporal manner, in that for each fluctuating pixel its 8 immediate spatial neighbours as well as its 2 temporal neighbours (the abovementioned corresponding pixel from the previous and next frames) are considered for inclusion in the average. If the value of each pixel is within the specified threshold, it is included. If not, it isn't.

This filter seems to remove almost all noise from low-noise sources (such as DVD) and a lot of noise from high-noise sources (such as cable TV captures), while maintaining a good amount of detail.

The speed at which it operates depends upon the amount of noise in the clip.

As usual your mileage may vary. This filter is unrelated to flux capacitors, which enable one to travel temporally.

source: http://www.kvcd.net/sansgrip/avisynth/

latest version: http://bengal.missouri.edu/~kes25c/FluxSmooth-1.1b.zip

[jorel]

Originally posted by SansGrip
Here's (http://www.jungleweb.net/~sansgrip/avisynth/FluxSmooth-0.1.zip) a new spatio-temporal smoother I wrote today based on ideas that came to me developing NoMoSmooth.

The source code is available (http://www.jungleweb.net/~sansgrip/avisynth/FluxSmooth-0.1_src.zip). Here's the description from the documentation (http://www.jungleweb.net/~sansgrip/avisynth/FluxSmooth-readme.html):



As usual your mileage may vary. This filter is unrelated to flux capacitors, which enable one to travel temporally.

thanks!........
the download works here,but can't open the page.;)

[High Speed Dubb]

The noise detection sounds similar to a temporal median filter, though your averaging method is different. You might want to check Tom’s STMedianFilter at
http://www.trbarry.com/STMedianFilter.zip
with docs at
http://www.trbarry.com/Readme_STMedianFilter.txt

[JuanC]

Originally posted by SansGrip
... One of the fundamental properties of motion is that it's not. This is the premise behind FluxSmooth, which examines each pixel and compares it to the corresponding pixel in the previous and last ¿next? frame. ... It looks like your web page is unavailable.:(

[SansGrip]

All links working fine for me. Must have been just a temporary thing...

[SansGrip]

The noise detection sounds similar to a temporal median filter, though your averaging method is different. You might want to check Tom’s STMedianFilter

From what I can gather reading the docs and source, STMedianFilter doesn't specifically target "fluctuating" pixels but instead clips pixels to its nearest neighbours.

I think what makes FluxSmooth different (though I've not checked every smoother out there :)) is that the temporal sequence 2, 0, -1 will not get averaged, but 2, 0, 1 will.

Perhaps this has already been implemented. What we need is some central filter algorithm repository we can check before beginning coding ;).

[SansGrip]

Here's verion 0.2, incorporating a minor bugfix, some optimizations, and an Avisynth 2.5/YV12 version.

Testing appreciated :).

Edit: Removed links to old version.

[Rrrough]

hi, I'd love to test this filter as well as the new version of NoMoSmooth, but unfortunately I can't load your page... :(
troublesome provider ? can you attach it to a post ?

cheers

[jorel]

Originally posted by Rrrough
hi, I'd love to test this filter as well as the new version of NoMoSmooth, but unfortunately I can't load your page... :(
troublesome provider ? can you attach it to a post ?

cheers

....but unfortunately I can't load your page too... :(
troublesome provider ? can you attach it to a post ?
thanks!

[High Speed Dubb]

Sansgrip,

That’s how a median works, too. With 2,0, -1, the median is 0, so the middle pixel’s value isn’t changed. With 2, 0, 1, the median is 1, so the middle pixel is changed.

[SansGrip]

hi, I'd love to test this filter as well as the new version of NoMoSmooth, but unfortunately I can't load your page... :(

Very odd. The site works fine for me. Can you PM me a traceroute?

can you attach it to a post ?

I did. It's still waiting to be modded.

[SansGrip]

That’s how a median works, too.

I'm beginning to think I should pick up a Statistics 101 textbook instead of reinventing it myself :D.

Ah well. Say, what would be your response to the idea of a spatio-temporal smoother with skin detection?

[High Speed Dubb]

I wouldn’t toss the idea just because there’s a related filter out there. (Well, actually there are two related filters. Simon’s Sandwich filter at
http://forum.doom9.org/showthread.php?s=&threadid=33817
also has some similarities.)

Medians are a good way to go for noise reduction — They’re usually a little inefficient, but they can be very robust. In other words, they don’t make the best possible use of the data, but the also don’t get messed up by unexpected stuff like interference. That’s because a median will mostly ignore the tails of a distribution, and just look at its center. (There are some sporting events which get judged with medianish filters — I think diving always tosses the low and high ranking before averaging the rest.) Medians will also do a good job with edge problems (i.e., when Y = black), while means will be biased.

I haven’t tried FluxSmooth yet, but the averaging you’re using when fluctuation is detected sounds like a good idea — It’ll probably avoid most of the usual median artifacts, like problems with very fast motion.

Skin detection sounds like it’s worth a try. Are you planning to look for specific colors, and avoid smoothing those too much? Just be sure not to claim that it “discriminates based on skin color” in the docs. ;)

[SansGrip]

Medians are a good way to go for noise reduction — They’re usually a little inefficient, but they can be very robust.

I'd love to find a more efficient way of implementing the "fluctuation detection" than what I'm using right now. Basically it's:


int prev_diff = prev_luma - curr_luma,
next_diff = next_luma - curr_luma;
if((prev_diff < 0 && next_diff < 0) ||
(prev_diff > 0 && next_diff > 0))
{
// Do the smoothing
}


I've optimized everything else about as far as it'll go (algorithmically that is), and this is the one remaining "if" in the main loop. I'd like to make it as efficient as possible, since I'm not able to remove it.

That’s because a median will mostly ignore the tails of a distribution, and just look at its center.

Interesting, I've never thought about averages in terms of distributions before. The more I get into this stuff the more I want to visit one of the local universities and see about a math course...

I haven’t tried FluxSmooth yet, but the averaging you’re using when fluctuation is detected sounds like a good idea — It’ll probably avoid most of the usual median artifacts, like problems with very fast motion.

I'm ashamed to admit I've not had time to try your fruity smoothers yet either. I'll try yours if you'll try mine... :D

Skin detection sounds like it’s worth a try. Are you planning to look for specific colors, and avoid smoothing those too much?

Yes, since I find that temporal smoothing, while overall very successful, is particularly destructive to skin tones and the slight details that make it look "real". It seems sensible to me to try to reduce this effect since skin is what we spend a great deal of time looking at in movies (some movies more than others, he added predictably ;)).

Inspection of colour range is one of the approaches I'd use. A little reading on the web reveals a lot of material relating to skin detection. Most of it is above my head (a significant amount was wrt neural nets), but I did pick up that skin tones, regardless of race, fall within a fairly specific colour range. Not only that, but by checking the overall variance of a 3x3 block it's possible to get a good idea of whether we're dealing with smooth skin or some other kind of similarly coloured texture.

I'm kinda worried it would pick up things like smooth pink walls. I'm still not sure how to differentiate between the two. Any ideas?

Just be sure not to claim that it “discriminates based on skin color” in the docs. ;)

heheh yes, it would need to be worded delicately ;).

[OUTPinged_]

SansGrip, you can't do much about skin smoothing unless you will update your motion engine so it would pick pixels according to motion vectors.

All these "smart" algorithms don't help a big deal and they get real slow very fast.

NoMoSmooth is about as far as it would get with current motion engine. You may see some improvement with that algo but it wont be drastical.

I know i sound like a whiner, but maybe try to concentrate on new ME engine. This will solve more problems than just "blended faces".

..Did a quick check and it works about same as nomosmooth, but a bit slower :-(

[SansGrip]

SansGrip, you can't do much about skin smoothing unless you will update your motion engine so it would pick pixels according to motion vectors.

Well, that's not quite true. It should be possible to detect skin even without motion vectors, though how much else that is similarly coloured and textured you'd also detect is another question.

NoMoSmooth is about as far as it would get with current motion engine. You may see some improvement with that algo but it wont be drastical.

The reason I'm toying with the idea of skin detection is because I find skin to be where temporal smoothing is most noticible. If one could avoid over-smoothing skin then more aggressive settings could be used on the rest of the frame.

I know i sound like a whiner, but maybe try to concentrate on new ME engine. This will solve more problems than just "blended faces".

You don't sound like a whiner, you sound like someone giving valuable input :). I'm currently looking around for a simple explanation/C(++) implementation of one of the fast motion estimation algorithms. If I find one I'll try to code it up and see what kind of results I get.

..Did a quick check and it works about same as nomosmooth, but a bit slower :-(

Now that is surprising, since in Flux the averaging is totally table-based while in NoMo it's arithmetical. I'll have to do some benchmarks/profiling and check out what's going on.

Thanks for your continued testing, it really is appreciated :).

[slk001]

Seems to me that the LAST thing you want to do with a noise filer for television is to AVERAGE it with its SPATIAL neighbors. Let me explain. First, since TV is a serially transmitted signal, any noise "blip" is not likely to be only one pixel long, but many pixels in a horizontal line. Assume, for arguments sake, that it is 5 pixels long horizontally, and only one pixel high vertically. Then, a tiny snapshot of the viewing screen would look something like this:

55555555555
55567842555
55555555555.

In this example, the "5" is the "real" signal, while anything else is noise. If we spatially average this noise, we will still have the noise - just averaged. But since we have identified this part as noise, why don't we try to eliminate it altogether? PROBLEM: What do we replace the noise with? Well, the most LIKELY candidates are its TEMPORAL neighbors. As an example, here is the same "noise" section with its two temporal neighbors:

55555555555
55555555555
55555555555 (PREVIOUS FRAME)

55555555555
55567842555
55555555555 (CURRENT FRAME, WITH NOISE)

55555555555
55555555555
55555555555 (NEXT FRAME)

In this scenario, if we endeavour to REPLACE the noise with a suitable substitute, then a very good approximation is the value of the pixels either before, or after the noise - or, the average of these two values NOTE: The noise itself is NOT included in the average, since we have assumed it to be an INVALID value, so, in this case, we are replacing a value based on a calculation in which the original value plays no part!!

As you can see in this simplistic scenario, the noise present in the current frame would be processed out entirely.

Now, progress to the NEXT FRAME. To prevent GHOSTING, the PREVIOUS FRAME is the frame that we PROCESSED OUT THE NOISE EARLIER. As a matter of fact, the ONLY frames that will be passed through unmodified are the very first frame in a video (since it has no "previous neighbor") and the very last frame (since it has no "next neighbor").

PROBLEMS:
1) Scene changes. This can be resolve by setting a WINDOW that the PREVIOUS pixel and the NEXT pixel have to be in before the filter kicks in.
2) Rapid, one frame movements (like a sword slashing through a scene). This can be resolved by setting a WINDOW based on the SPATIAL information of pixels ABOVE and BELOW the current test pixel (if the text pixel is within the window of EITHER the pixel ABOVE or BELOW, then filter ignores the current pixel under test - ie, doesn't change).

Now here are the assumptions that I am making regarding the noise:
1) 98% of the noise "blips" will not be over or under another separate noise "blip". Or, they will not do this (SPATIALLY):

55555555555
55567842555
55555567842
55555555555.

2) The noise will never appear temporally "sync'ed". (Ie, two noise "blips" will never occur at the same spot in two adjacent frames.)

For assumption 1), a WIDTH parameter could be added, where, instead of testing spatially one line above, testing two or three lines above or below the current pixel under test. For obvious reasons, the WIDTH parameter should be limited to a maximum of two or three.

For assumption 2), the filter should ignore the noise as signal, since any algorithm devised to correct this would most likely cause ghosting.

[High Speed Dubb]

SansGrip,

By saying that medians are inefficient I just meant that they don&rsquo;t make use of all the available information. I didn&rsquo;t mean to imply anything about speed.

Beyond your idea of checking the local variance, I can&rsquo;t think of any way to prevent the occasional smooth skin-toned feature from being identified as skin. As mistakes go, though, that might not look too bad &mdash; It&rsquo;ll just mean an occasional extra amount of noise. Considering that it will be mostly in smooth areas, it might even improve the picture.

There&rsquo;s also the usual threshold problem to watch out for. The boundary between &ldquo;skin&rdquo; and &ldquo;not skin&rdquo; might show some artifacts. But if the reduction of smoothing is subtle enough, the boundaries might be hard to spot.

slk001,

It looks like you&rsquo;re assuming that noise consists of small horizontal noise patches on a noiseless background (aka &ldquo;salt and pepper&rdquo; noise). That&rsquo;s a fair description of certain kinds of interference. But it isn&rsquo;t what I&rsquo;ve seen from broadcast video. Instead, there is noise everywhere. Because everything has noise, combining a whole bunch of pixels can improve the accuracy.

But you are right that noise is horizontally correlated (i.e., &ldquo;red&rdquo; noise) in broadcast material. So far I&rsquo;ve found that this can be ignored, but it is worth keeping in mind for the noise filters.

[SansGrip]

PROBLEM: What do we replace the noise with? Well, the most LIKELY candidates are its TEMPORAL neighbors.

Assuming they aren't noise too ;). Rather than thinking of noise as a completely invalid value, I tend to think of it as simply a corrupted one. Just because the pixel was originally a 5 and is now an 8 doesn't make that pixel's value useless -- we just need to correct it, and that's the hard part. Averaging, of course, isn't perfect.

But you're right in that there's an argument to be made over whether spatial smoothing is even a good idea. That's why I allowed both temporal and spatial smoothing to be separately disabled by setting the threshold to zero.


As an example, here is the same "noise" section with its two temporal neighbors:


55555555555
55555555555
55555555555 (PREVIOUS FRAME)

55555555555
55567842555
55555555555 (CURRENT FRAME, WITH NOISE)

55555555555
55555555555
55555555555 (NEXT FRAME)


If noise really looked like this, it would be very easy to detect and remove :). Unfortunately it's usually very very hard (if not impossible) to make the distinction between noise and fine details. What we're all trying to achieve is an algorithm that is, as it were, tough on dirt yet gentle on your hands :).

Now, progress to the NEXT FRAME. To prevent GHOSTING, the PREVIOUS FRAME is the frame that we PROCESSED OUT THE NOISE EARLIER.

This is one approach, but it has the disadvantage that it tends not only to reduce more noise but also destroy more details.

2) Rapid, one frame movements (like a sword slashing through a scene).

I briefly considered this when playing with algorithms, but decided that any movement that lasts for a single frame is so quick that the amount of processing applied to it barely matters. In fact, such a fast-moving thing would be a candidate for more smoothing, not less.

2) The noise will never appear temporally "sync'ed". (Ie, two noise "blips" will never occur at the same spot in two adjacent frames.)

Unfortunately since noise is inherently random, we can't be sure of anything like that.

[SansGrip]

Beyond your idea of checking the local variance, I can&rsquo;t think of any way to prevent the occasional smooth skin-toned feature from being identified as skin. As mistakes go, though, that might not look too bad &mdash; It&rsquo;ll just mean an occasional extra amount of noise. Considering that it will be mostly in smooth areas, it might even improve the picture.

I had a brief play with it and using the chroma range I settled on, along with a very simple variance measure, there were a lot of false hits in my source material -- including things like static walls that you really want aggressive temporal smoothing on. What might work better is a chroma histogram instead of a simple range, fed with test data from a bunch of different scenes.

But you are right that noise is horizontally correlated

You mean distributed over several horizontal pixels?

[slk001]

Assuming they aren't noise too .

True, so true... in fact, this is one assumption that you have to make when you are going to try to replace the noise with what you think is "good" data.

This is one approach, but it has the disadvantage that it tends not only to reduce more noise but also destroy more details.

Well, not really. If your pixel under test value is "8", and its temporal neighbors are both "5", then the probability that this pixel is noise and not detail data is quite high (remember, my vision of this filter would be to NOT FILTER if the temporal neighbors exceeded a threshold, and detail is NOT LIKELY to be only one frame long). But this technique would also almost completely remove single frame movements (like the slashing sword). That is why I believe an additional test of the pixels SPATIAL neighbors ABOVE and BELOW (although maybe not DIRECTLY) would be needed.

Unfortunately since noise is inherently random, we can't be sure of anything like that.

Again, this is so true. Unfortunately, we have to put a limit on how much we expect our filter to do. If the source is getting too noisey, then we have to direct our filter to shut down.

Just because the pixel was originally a 5 and is now an 8 doesn't make that pixel's value useless -- we just need to correct it, and that's the hard part.

When noise corrupts a signal, it tends to not just slightly modify the value, but instead tends to send the value to one of the luminance rails (16 to 235). This is where, of course, averaging is less than perfect.

You mean distributed over several horizontal pixels?

For TV, the answer is yes. This is because TV is sent out serially and noise, when it occurs, affects a "serial string" of data. This means that determining an average with a pixel's 8 spatial neighbors is likely to contain corrupted data in 3 of them. However, if this spatial averaging is done with the top 3 and bottom 3 neighbors, only 1 is likely to be corrupted.

The type of noise that I am interested in filtering, is the random (but sometimes heavy) IMPULSE noise, like from ignition noise or lightning strikes. These are perfect candidates for my replacement "theory" of filtering as opposed to simply trying to average it out.

The filter I envision would probably fail miserably against a picture with heavy picture snow (as would most noise filters). Here, the only alternative would be the averaging techique that you propose.

I can send you a clip of the type of noise that I am talking about, if you are interested.

[SansGrip]

This is because TV is sent out serially and noise, when it occurs, affects a "serial string" of data. This means that determining an average with a pixel's 8 spatial neighbors is likely to contain corrupted data in 3 of them. However, if this spatial averaging is done with the top 3 and bottom 3 neighbors, only 1 is likely to be corrupted.

This is interesting, I hadn't considered it that way. I'm going to let it percolate through my brain and see if I can work it into some kind of algorithm :).

I can send you a clip of the type of noise that I am talking about, if you are interested.

Sure, maybe we can spot some kind of pattern that could be useful in working out a filtering technique.

[SansGrip]

Here's 0.3 which fixes a very bad bug that significantly changed the algorithm. Since fixing this I've also been able to put the defaults back up to 7, 7. I was tempted to put them higher but I decided to wait for some feedback on that first.

It includes both a 2.0/YUY2 version and a 2.5/YUY2/YV12 version.

I also made some optimizations, and for me at least it runs fairly quickly (roughly 6-7fps faster than C3D movieHQ on 720x480 material). Though bear in mind that its performance depends on the amount of noise in the clip, and is still pure C++ with no assembler.

For very noisy sources try jacking up the thresholds. You'll be surprised how far you can go with them before you see artifacts.

I'm pretty pleased with this filter as it seems to remove a great deal of the most noticible noise with very little impact on details (depending on the threshold, of course).

Feedback is, as always, very much appreciated. I'd be especially interested in hearing its effect on compression, as well as suggested defaults for various kinds of sources (clean DVD, noisy DVD, cable captures, digital captures, etc. etc.).

Let me know :).

[Boulder]

Hi SansGrip, it seems that your site is not reachable..it's been like this for two days now:confused:

[SansGrip]

Hi SansGrip, it seems that your site is not reachable..it's been like this for two days now:confused:

It seems to be a problem coming from Europe, for some reason. Would someone unable to get to my site please do a traceroute to www.jungleweb.net and PM me the result? I administer the server so I'm very interested to know why it's not working :).

[ajp]

DNS lookup failed, can't find the host...

[slk001]

The site works fine for me.

[slk001]

The site works fine for me.

[vlad59]

It works fine for me too (I'm from France)

[rocker60]

Not for me:scared:
I'm from Portugal-(Europe)

[ajp]

Works for me now...weird... DNS server problems probably... :)

[SansGrip]

heheh thanks for the feedback. Based on a traceroute from Columbia we figured out something was wrong in the firewall (the senior administrator had been a little over-zealous fighting spammers and accidentally blocked most of the world outside North America :D).

Should be accessible to everyone now, though it might take a little while for DNS caches to sort themselves out.

Thanks for the reports and my apologies for the downtime :).

[Asmodian]

It works great for me (but I am not in Europe).

[cult]

works here,europe

[High Speed Dubb]

slk001,

When noise corrupts a signal, it tends to not just slightly modify the value, but instead tends to send the value to one of the luminance rails (16 to 235). This is where, of course, averaging is less than perfect.

You’ve definitely got heavy “salt and pepper” interference. I see something similar on a couple of channels when a certain fluorescent light with a dimmer switch is turned on. My solution has been to turn off the light. ;)

If you can’t find the source of the interference, it would be better to use a filter designed for getting rid of dots rather than noise. A simple temporal/vertical median should work very well for that. You might want to try Tom’s Undot, from

http://www.trbarry.com/UnDot.zip

SansGrip,

Yep, noise (not just interference) does tend to be horizontally correlated. I don’t know how many pixels you have to go before you approach independence — By eyeball, I would guess about 10 to 15 (with NTSC broadcasts and a pixel width of 720).

With respect to slk001’s problem, I think it would make sense to design the filter for use with noise or with salt and pepper interference, but not both. The two problems are different enough that it would make more sense to use separate filters for them.

About skin identification &mdash; I take it that skipping filtering on pinkish walls doesn’t look so good. Maybe the thing to do with skin color stuff is to use only slightly less filtering on it? That would reduce blurring, and might be subtle enough not to be noticed elsewhere.

[SansGrip]

You’ve definitely got heavy “salt and pepper” interference. I see something similar on a couple of channels when a certain fluorescent light with a dimmer switch is turned on. My solution has been to turn off the light. ;)

Very efficient, but does it work with YV12? ;)

Yep, noise (not just interference) does tend to be horizontally correlated. I don’t know how many pixels you have to go before you approach independence — By eyeball, I would guess about 10 to 15 (with NTSC broadcasts and a pixel width of 720).

Interesting. You don't think it would help to take that into account in a smoother designed for captures?

About skin identification &mdash; I take it that skipping filtering on pinkish walls doesn’t look so good.

It looks pretty bad :).

Maybe the thing to do with skin color stuff is to use only slightly less filtering on it? That would reduce blurring, and might be subtle enough not to be noticed elsewhere.

That might work. I'll have to play with the code and see what I can do with it.

[High Speed Dubb]

I had a “red noise” reducer in an unreleased early version of Peach Smoother. It did help, but the same technique hasn’t worked for the more advanced versions of the filter. It’s somewhere on my list for future things to try — I think there is a way to make good use of horizontal correlation even for the current algorithm.

The general approach I’ve tried has been to use inferred noise to the left as a predictor for the current noise. In other words, if the pixel to the left has an inferred noise of 4, then you can predict before even looking at the next pixel that it will have an expected noise of 4*k. This follows from a model called a (buzzword coming...) Ornstein-Uhlenbeck process.

[SansGrip]

This follows from a model called a (buzzword coming...) Ornstein-Uhlenbeck process.

Good Lord. Something as simple as that has a name so complex? ;) I suppose the tricky part is deciding on a value for k...

[High Speed Dubb]

It&rsquo;s a continuous random walk model, with an extra term which causes the result to move toward the &ldquo;true&rdquo; value.

You can call it &ldquo;red noise&rdquo; instead, since that sounds less intimidating. But then people think it has something to do with color, which it doesn&rsquo;t.

[SansGrip]

You can call it &ldquo;red noise&rdquo; instead, since that sounds less intimidating. But then people think it has something to do with color, which it doesn&rsquo;t.

I'm still fuzzy (no pun intended ;)) on the whole coloured noise thing. It's something else to add to my to-do list. Now I'm never going to get round to learning Esperanto... :D

[High Speed Dubb]

&ldquo;Colored&rdquo; noise is just a bunch of different noise distributions (and relationships between noise at nearby times). Audio engineers apparently dipped a little too deeply into the Cool-Aid and decided to name those distributions after colors.

White is the important one, and is just another name for independent, normally distributed noise.

[vinouz]

AFAIK, white noise is named so relatively to the white spectral distribution of this signal. E.g if you do an FFT on white noise, all frequencies have the same power.
I don't know for wideo, but for sound signals, it's what it means. And I don't think it must be different on video (just 2D spatial instead of 1D tmporal - btw, as spatial signal used to be transmitted sequentially, 2D spatial means practically 1D temporal, which for example on a tv signal would give the exact same function.)

for red and coloured, is it due to certain parts of the signal spectrum being stronger than others (e.g. for red : lo freq noise).

Cheers, Vince

[High Speed Dubb]

White light doesn&rsquo;t have the same power for all frequencies, or even all visible ones. Red noise does have lower frequencies, but &ldquo;red&rdquo; is a misleading term to use to describe low frequencies, at least when talking about video. (If we need something easier to remember than Ornstein-Uhlenbeck, we can call it Mean Reversion, or just correlated noise.)

I think the colors are just a metaphor which was stretched too far.

PS I&rsquo;ll switch to private messages for further stuff on noise nomenclature.

[vinouz]

I'm ok about the metaphor being pushed too far here. As red is quite closer to red color when talking about video ;).

About white light. When you put all spectral parts of light together, didn't we learn at school it makes white ?
I Agree you can make other whites lights with unequal spectral distribution. But this is due to the sensibility of the eye being itself unlinear. The best example of one of these lights is your CRT's white (Here let's consider it's perfectly well calibrated, so as not to confuse problems). blue phosphores make a certain blue, distributed unequally around the blue freq, and so on for red and green. But as your eyes only discern some frequencies of blue, of red and of green, if the sum of blue, reb and green percepted energy is the same in these three respective sensibility frequency domains, we see it white. But it isn't.
A well known example of this fact is known by photographs, who knows that fluorescent and incandescent light render far different on photographs, because argentic coloured crystals don't have the exact same frequency domains for R, G and B sensitivity than the eye. (we see them different too, but not as much as when rendered on photographs)
So even if white is not often constantly spectral distributed, that doesn't mean a constant spectral distribution of all the frequency doesn't give white.

(Not talking .6/.3/.1 coefficients for eye response to primary colours here.)

I'm not a specialist, so tell me where I missed something if that's the case.

Vince

[OUTPinged_]

Very hard case for temporal filters are a very dark scenes.


And scenes with deep red/blue color, too (have no idea, why, though).

[High Speed Dubb]

OUTPinged_,

Yep, dark scenes have a different noise distribution, and also a different signal distribution.

Some problems with saturated chroma (deep red/blue) can come from color crosstalk, which tends to make any extreme chroma areas appear to be in motion. Other problems can come from color calibration (which I find significantly more difficult than luma calibration).

A third possibility is that the filter handling of chroma isn&rsquo;t so good. The suggested thresholds for chroma differences on this forum are sometimes very inflated &mdash; From what I&rsquo;ve seen, YUY2 chroma actually varies much less than luma does. It&rsquo;s also possible for separate handling of chroma and luma to cause problems.

[slk001]

@SansGrip

I have a three second noisey video that is ~1.15MB long. If you would like to look at it, where do I send it?

[SansGrip]

I have a three second noisey video that is ~1.15MB long. If you would like to look at it, where do I send it?

Replied in PM.

[iago]

@SansGrip

A very short feedback, but I just wanted to inform you that I still cannot lose details using FluxSmooth(15,15)! ;)

regards,
iago

[SansGrip]

A very short feedback, but I just wanted to inform you that I still cannot lose details using FluxSmooth(15,15)! ;)

Glad to hear you're experimenting :).

You probably are losing a little with thresholds that high, but because it's only selecting fluctuating pixels it won't be too noticible.

Try doing a StackVertical with FluxSmooth(15, 15) above and FluxSmooth(15, 0) below. I think you'll see that a high spatial threshold does cause some compression-friendly softening -- that's what it's there for :).