Filter for eliminating DCT blocks

[Wilbert]

For generation of samples of a normal variable, the math folks use the Box-Muller transform:

If X1, X2 are uniformly (independent) distributed on the interval (0,1) then Z1,Z2 are normal distributed (mean zero and variance one):

Z1 = sqrt( -2*ln(X1) ) * cos(2*pi*X2)
Z2 = sqrt( -2*ln(X1) ) * sin(2*pi*X2)

see also in mathworld (http://mathworld.wolfram.com/Box-MullerTransformation.html).

So you generate samples for X1 and X2 and compute the samples for Z1, and scale it if necessary.

[yaz]

hi all !

i enjoy this thread very much. it blurbs my mind all the time (never mind :-)

q1: would it be possible to tune the extent of noise (intended to add) somehow to the average luma round the pixel a/o to the luma noise of the block/frame ?
- sometime i'd like more noise in a certain part of the picture or i'd add more to the darker ones or so.

q2: would it be possible to draw the noise somehow from the picture?
- imho, noise is a part of the picture holding relevant information. if this part were reinvented (to a certain extent), that (part of) information would be regained. or am i completely wrong ? of course, this noise wont have any 'presettable' characterisctics.
- for such purpose, i usually do a strong smoothing & then i merge back a part of the luma from the orig frame. it's very helpful, especially with tv capts & vhs sources. i was just musing about something like that.

y

ps don't stop your activity just because of my stupidity :-)

[SansGrip]

Well I finally got the documentation in order this morning and have uploaded Blockbuster v0.3a to my web site along with its source code.

Many changes in this release, including substantial downsizing of parameters and significant speed boosts. In particular note that the way detail_threshold works has been changed. Check out the docs (http://www.jungleweb.net/~sansgrip/avisynth/Blockbuster-readme.html) for more information.

Enjoy :).

Edit: Changed link to point to 0.3a.

Edit 2: Remove links to old version.

[SansGrip]

(i'm imploring to implement this option, it would be too much useful :p :D)

It wouldn't be an option, it would be a separate filter. Once I come up with a good -- and fast -- way of blending parts of two clips together seamlessly I'll write it.

Any suggestions?

[SansGrip]

For generation of samples of a normal variable, the math folks use the Box-Muller transform

This is what I'm using right now, at least the fast version of it (I think it's called the Polar method).

Thanks for showing me mathworld -- I think it'll come in very handy :).

[SansGrip]

q1: would it be possible to tune the extent of noise (intended to add) somehow to the average luma round the pixel a/o to the luma noise of the block/frame ?

Sure. It could be weighted based on luma quite easily, though there would of course be a performance hit.

q2: would it be possible to draw the noise somehow from the picture?

Check out v0.3. It's new sharpen method will do exactly that: amplify the already existing details instead of simply making new noise.

imho, noise is a part of the picture holding relevant information.

Well, technically it's not. Signal holds the information we want, and noise is the information we don't want ;). That said, I know what you mean. Noise, as far as the encoder is concerned, adds detail, and that seems to make them behave better under certain circumstances.

[Xenoproctologist]

How about checking so that pixel values don't roll over/under when (pixel+noise) < 0 || (pixel+noise) > 255, m'kay?

[SansGrip]

How about checking so that pixel values don't roll over/under when (pixel+noise) < 0 || (pixel+noise) > 255, m'kay?

Oops ;).

Edit: Removed links to old version.

[Xenoproctologist]

Originally posted by SansGrip
Oops ;).

Heh. Groovy. Now I can see if this helps get rid of the DCT Blocks From Hell in this anime encode I'm doing.

Well...after I see what removing the dot-crawl does, anyway. (Guava! Wai!)

[Kaiousama]

Hi, thanks for the release, i've had the time to do only a few tests, and for now i've had:
- The filter is painfully speedy (i've tried even to call it more times into the same script and the speed reduction is very acceptable, yatta!)
- The Blur mode is very very useful for anime: instead of a constant blur in the image it'll be possible to have a constand or scaled blur gradient simply creating a combo of blockbuster with a decreased invert threseold :) (the same concept is obviously applicable on sharpening)
- The noise adding was the weak point in my tests (*ouch*) because it hasn't removed at all the DCT blocks with standard options, i have to make more tests on it to be sure... can you explain a little more in detail how the noise is added in every block?

Bye

[SansGrip]

The filter is painfully speedy

Glad to hear the optimizations worked ;).

can you explain a little more in detail how the noise is added in every block?

Basically the random number generator produces a value based on the mean and variance you give it. The mean will generally be zero otherwise you'll introduce an overall change in brightness, but the variance depends on how much noise you want to add. When variance=1 68% of the values will be between -1 and 1, 95% between -2 and 2, and 99% between -3 and 3. Values outside this range will be generated, but very rarely. The values are simply added to the current value for luma or chroma.

So to vary the "strength" of the noise, leave the mean at zero and change the variance.

[iago]

@SansGrip and MaTTeR

Well, imho, unlike the lumoff/UnFilter combo, BlockBuster is a great noising filter to eliminate DCT blocks throughout the "whole encode", regardless of the luma range, with its "block size", "detail threshold" and "noise strength" parameters, which all can be configured to suit the needs and taste of the user.

As far as I can tell, the lumoff=-2/UnFilter combo that I've been using for a long while in my encodes is mostly effective against blocks in "dark areas", not in the other parts of the encode.

Therefore, I guess, rather than considering BlockBuster as an alternative to the lumoff/UnFilter combo, it might be much better to regard/use it as a complement to it (or vica versa of course ;)), since in my limited BlockBuster tests with XviD (using b-frames) it seems that BlockBuster is not as effective against DCT blocks in dark areas as the lumoff/UnFilter combo. However, as I said above, with its all-configurable great parameters, it might do miracles in other parts of the encode where the lumoff/UnFilter combo fails.

So why not give them together a try? I absolutely will! ;)

Btw, I agree with Matt that 4 seems to be a good value for detail threshold. And now I'm trying "block_size=4" together with "lm=0, lv=2.5, cm=0, cv=0.5". However I have no idea how it will effect compressibility, which I don't want to sacrifice completely indeed. Let's try and see! ;)

Anyway, I want to thank SansGrip one more time for his great effort and the color (noise :D) he has introduced to the encoding scene! ;)

best regards,
iago

[SansGrip]

@iago:

I've been waiting impatiently for feedback from you, the "dark block master" ;).

since in my limited BlockBuster tests with XviD (using b-frames) it seems that BlockBuster is not as effective against DCT blocks in dark areas as the lumoff/UnFilter combo.

Did you try lumoff and Blockbuster together, without UnFilter? If that helps I'll add a luma offset parameter, perhaps configurable so it only offsets luma within a certain range (so you can apply it only to areas already dark).

By the way, have you tried the other methods (sharpen and blur) yet? I'm not sure how useful they are.

However I have no idea how it will effect compressibility, which I don't want to sacrifice completely indeed. Let's try and see! ;)

Yes, let me know -- I'd be very interested to hear.

Anyway, I want to thank SansGrip one more time for his great effort and the color (noise :D) he has introduced to the encoding scene! ;)

heheh thanks. It feels strange working on one filter to add noise and one filter to take it away simultaneously though ;).

[iago]

@SansGrip

Due to many reasons, one of them being XviD and AviSynth 2.5 development going lightning fast recently ;), I haven't been able test BlockBuster extensively yet.

I have just started doing some compressibility tests and playing with the common and method-specific parameters to achieve some sort of compromise between effectiveness and compressibility. I guess, soon I'll start more specific tests as well. For the time being, I can only say that I'm very pleased to see BlockBuster work with MPEG-4 successfully and do its job against DCT blocks throughout the "whole" encode.

Also, having a (configurable) luma offset parameter with the filter can really be interesting.

Btw, there is an important thing I wonder: Can we expect an AviSynth2.5 / YV12 implementation of BlockBuster, which would really be great imho? ;)

best regards,
iago

[MaTTeR]

Originally posted by iago
Btw, there is an important thing I wonder: Can we expect an AviSynth2.5 / YV12 implementation of BlockBuster, which would really be great imho? ;)This is actually why my Blockbuster testing hasn't taken place yet. Had too many YV12 rips queued up:)

Glad to hear Iago had some success with BlockBuster. Hmmm, the luma offset affecting the "detailed_threshold" areas would be very cool indeed.

[SansGrip]

Due to many reasons, one of them being XviD and AviSynth 2.5 development going lightning fast recently ;), I haven't been able test BlockBuster extensively yet.

hehehe that's fine, I was just kidding ;).

For the time being, I can only say that I'm very pleased to see BlockBuster work with MPEG-4 successfully and do its job against DCT blocks throughout the "whole" encode.

I'm very glad to hear that it has an affect on MPEG-4 as well -- I was beginning to think it was only useful against MPEG-1...

Also, having a (configurable) luma offset parameter with the filter can really be interesting.

MaTTeR's suggestion (luma offset affecting only areas within detail_threshold) is an interesting one, though my initial thought is that the offset would need to be small in order not to be noticible (I guess -2 is small enough).

Btw, there is an important thing I wonder: Can we expect an AviSynth2.5 / YV12 implementation of BlockBuster, which would really be great imho? ;)

If Blockbuster is definitely working for you then I'll certainly implement a YV12 version. I'll need to figure out how to make 2.5 co-exist with 2.0 first though :).

[SansGrip]

By the way, there's an interesting thread (http://www.kvcd.net/forum/viewtopic.php?t=1604) on the KVCD forum with reports of people getting good results.

</shameless plug> ;)

[MaTTeR]

Wow, Blockbuster's speed is obviously much better than AddNoise now. Using BB, I hardly lost 1FPS during encodes:D

I've been running a few Quant=2 tests with Koepi's latest dev build(XviD) from today. So far I have to agree with Iago, overall the DCT blocks are being reduced. My results were a bit unexpected using Iago's initial parameters in regards to compressibility. For a 6min DVD clip at Quant=2, I'm showing the file size to increase about 11MB. Now, I might have expected this if using method="sharpen" but my results show almost the same file size if blurring or sharpening.
LoadPlugin("C:\Program Files\AviSynth2\plugins\MPEG2DEC3.dll")
mpeg2source("D:\night.d2v",lumoff=-2,iDCT=2,cpu=1,moderate_h=35,moderate_v=55)
crop(4,4,712,472)
TemporalSoften(1,5,0)
Blockbuster(method="sharpen",detail_threshold=6,lm=0,lv=2.5,cm=0,cv=0.5,cache=384)
LanczosResize(624,336)
File size= 63,498K

I then changed the method to blur and the file size came out as 63,520K. As you can see not much difference in the file size between the two. For reference, I encoded the clip without Blockbuster and the size is 56,726K.

I then viewed all the clips using TV-Out to see the visual difference. I have to admit that the clip with method="sharpen" looked best overall. Using "blur" seems to have helped a bit but as a side effect the blocks seemed to jump around a bit more so again visually I chose the "sharpen" clip. My source isn't the best for this test so I've got 3 others here that I'll try.

BTW- I didn't even try the tests without lumoff=-2, I was just assuming it could only help the situation. It would be interesting to see how the clip looked if the affected detail_threshold areas were the only part of the frame with luminance lowered though. Anyway, I'll post more comments later as my tests complete. Great work SansGrip, looks as though MPEG-1 certainly benfits from BlockBuster after reading user comments over at Kwag's.

Edit- I understand why my file size increased now. I obviously was adding noise while blurring/sharpening:D Don't mind me, I'll continue my aimless ramblings later after more thorough testing.

[MaTTeR]

Just finished up with more XviD Quant 2 tests on different DVD sources. The tests confirm my initial visual thoughts, method="sharpen" indeed gives a more overall eye pleasing encode compared to "blur" IMO.

The most impressive thing I've noticed is the file size doesn't increase on some movies but instead decreases for some reason:confused: This is a very good thing but I'm not sure why it happens. Some of my clips did increase when using "sharpen" but only very slightly, maybe less than 1%. Again, my results are for MPEG-4 only; in regards to MPEG-1/2(prefer 1) I've never really had a problem with DCT blocks. Maybe that's because the KVCD templates work so well:p

One last thing, using lumoff=-1 or even 2 definitely seems to help further reduce DCT blocks even more depending on the source material. I'm not sure how this affects the overall compressibility if any, I suspect it should help some in that regard. I have not tested adding noise with BlockBuster, perhaps Iago had some luck with it. Right now I'm happy with what "sharpen" is producing, good stuff indeed.

[SansGrip]

Blockbuster(method="sharpen",detail_threshold=6,lm=0,lv=2.5,cm=0,cv=0.5,cache=384)


When using method="sharpen" only the common parameters (detail_threshold, block_size, invert) as well as the sharpen-specific parameter (strength) are used. If you use sharpen or blur, no noise is added so you don't need the mean, variance, and cache settings.

[SansGrip]

method="sharpen" indeed gives a more overall eye pleasing encode compared to "blur" IMO.

That's what I would predict. I'm surprised that blur even works at all for DCT block removal. It might work on mosquito noise if combined with invert though :).

I have not tested adding noise with BlockBuster, perhaps Iago had some luck with it.

I think you'll find even better results from adding noise, depending on the source. There's only so much you can do with sharpen before things start to look artificial.

Glad to hear you're getting some pleasing results. I'm going to implement lumoff tonight and hopefully will have something ready by tomorrow :).

[MaTTeR]

Originally posted by SansGrip
[i]I think you'll find even better results from adding noise, depending on the source. There's only so much you can do with sharpen before things start to look artificial.

Think I'll do some some tests with doing both sharpen and adding noise. I need to call the filter twice for this right? I tried doing it on one line but no luck. heheh

I've yet to do any full 2-pass encodes yet but I'll set some up before going to sleep. I'm anxious to see an entire movie with Blockbuster. Thx for looking into the luma feature.

[SansGrip]

MaTTeR: Think I'll do some some tests with doing both sharpen and adding noise. I need to call the filter twice for this right?

Yep.

I tried doing it on one line but no luck. heheh

I was thinking of adding this functionality but couldn't come up with a way of doing it without confusion. I've been talking with the guys on the KVCD forum and a couple of them were confused by the docs with regards to which parameters go with which method, so I think making the calling syntax even more complicated might be a bad idea ;).

Thx for looking into the luma feature.

I roughed out in my head how it'll work last night while I was watching TV, so I'm going to code that now, along with better parameter-checking, while I wait for the cable guy (free installation and $1 for two months of basic cable... You'd have to be a moron to say no to that :D).

[SansGrip]

I just released 0.4 (http://www.jungleweb.net/~sansgrip/avisynth/Blockbuster-0.4.zip) (and source (http://www.jungleweb.net/~sansgrip/avisynth/Blockbuster-0.4_src.zip)) with the following changes:

* Added luma_offset and luma_threshold parameters
* Split detail_threshold into detail_min and detail_max
* Removed redundant invert mode

See the documentation (http://www.jungleweb.net/~sansgrip/avisynth/Blockbuster-readme.html) for more info.

Have fun :).

[iago]

@SansGrip

You may be sure that BlockBuster works and does a pretty good job with MPEG-4 too ;). So, parallel to the great AviSynth 2.5 development, it will really be nice to have a YV12 version of the filter. Thanks a lot for working on it!

Btw, to see its effect on blockiness (which is absolutely more visible with SBC encodes) and maybe pushed by some feeling of nostalgia as well ;), I also did a "Nandub SBC" encode using BlockBuster with some experimental/heavier settings such as (method="noise",block_size=4,detail_threshold=4(in some parts 2),lm=0,lv=3,cm=0,cv=0), which gave me a very good encode as a result, though I'm sure it decreased compressibility considerably ;).

Well, in short, I'm looking forward to the YV12 version of BlockBuster actually!

best regards,
iago

edit: wow! a new version has already arrived while I was typing! ;)

[SansGrip]

You may be sure that BlockBuster works and does a pretty good job with MPEG-4 too ;).

That's a relief :).

gave me a very good encode as a result, though I'm sure it decreased compressibility considerably ;).

heheh well like I say in the docs, sometimes it's worth it ;).

Well, in short, I'm looking forward to the YV12 version of BlockBuster actually!

I'm going to check out the YV12 threads to see if it's possible to have 2.0 and 2.5 co-existing on the same Windows install. Unfortunately my current hard drive situation means I can't do another install just for YV12 development :(.

[MaTTeR]

Originally posted by SansGrip
I'm going to check out the YV12 threads to see if it's possible to have 2.0 and 2.5 co-existing on the same Windows install. Both versions co-exist fine here for the past few weeks. I simply have VdubMod 1.4.11 with it's own AVS 2.5 dll in the same folder. Otherwise the rest of the system is still using AVS 2.06. You should have no problems at all.

[SansGrip]

Both versions co-exist fine here for the past few weeks.

Excellent news, and a clever solution.

YV12-enabling all my filters for 2.5 is now high on my TODO list, just below "Find out how the 2.5 API differs from 2.0" and "Learn what YV12 is" ;).

[iago]

@SansGrip

All I can say, based on my ongoing tests, is that this filter is a fantastic tool, with its highly configurable parameters, which can all be tweaked according to the nature of source, to get decent encodes with the least possible DCT blocks.

"luma_offset" and "luma_threshold" parameters are just great to keep the original levels of the picture untouched, with a capability of affecting only the dark parts of the encode as desired (where the default 25 or something like 20 would be reasonable values imho).

"detail_min" and "detail_max" are also amazing parameters, which can be set as to suit the needs of the user, and also more comprehensible than the previous inverty ;) ones.

And finally, you can determine the strength of the noise to be applied to luma and/or chroma planes (while I prefer to use only luma noise and set cm and cv to 0).

Absolutely great! Keep up your great work, man! I really appreciate it ;).

(And please do not delay much releasing the YV12 version of this magic tool, which might even make me change my long-time favourite combo ;))

regards,
iago


edit: soon, I'll report some test results as well.

[High Speed Dubb]

What amount (variance) of noise addition are people finding to be effective at breaking up blocks for various kinds of MPEGs?

I&rsquo;m asking for my own purposes, since this will help me come up with defaults and docs for noise filtering. But it&rsquo;ll probably be useful for Blockbuster, too.

[SansGrip]

@iago:

Wow! Thanks for the high praise -- I'm very glad this finally evolved into something useful :).

(And please do not delay much releasing the YV12 version of this magic tool, which might even make me change my long-time favourite combo ;))

Well, I just ported NoMoSmooth (see other thread) to YV12, and am waiting for feedback from 2.5 testers on whether it even works properly.

Once I know I understand how it works I'll make YV12 versions of all my filters, including (first, of course :)) Blockbuster.

[SansGrip]

What amount (variance) of noise addition are people finding to be effective at breaking up blocks for various kinds of MPEGs?

I find it varies significantly depending on the source. For MPEG-1 I've received good reports with anything from 1 to 3.

[kwag]

Originally posted by High Speed Dubb
What amount (variance) of noise addition are people finding to be effective at breaking up blocks for various kinds of MPEGs?

I&rsquo;m asking for my own purposes, since this will help me come up with defaults and docs for noise filtering. But it&rsquo;ll probably be useful for Blockbuster, too.

Hi High Speed Dubb,

Try this combination in your script:

Blockbuster(method="sharpen", detail_min=60, detail_max=99, strength=20) # Only sharpen material above 60%.
Blockbuster(method="noise", detail_min=1, detail_max=20, lv=1.5) # Only apply noise below 20% complexity.
# Mid tones (frequencies) from ~21% to ~59% will not be processed.

Be sure to use Blockbuster 0.4 for this.

-kwag

[High Speed Dubb]

Cool &mdash; Thanks for the estimates. This means I should start recommending lower Stability values for Peach Smoother, at least if the output is going to be used for MPEG-1 encoding.

At its default stability value it tends to drop the variance by about a factor of 13. With broadcast material that gets you pretty near to variance = 1.0, which is already on the low side. Cleaner sources would end up with too little noise.

You could use BlockBuster to add noise back in afterward. That would let you increase it especially in low contrast areas. On the other hand, it does sound slightly strange to do that if the problem could have been avoided just by using less aggressive smoothing.

[SansGrip]

You could use BlockBuster to add noise back in afterward. That would let you increase it especially in low contrast areas. On the other hand, it does sound slightly strange to do that if the problem could have been avoided just by using less aggressive smoothing.

I've been playing with this in-between YV12 investigations and spending a few minutes per day with my family ;).

I've found that using NoMoSmooth (which IMHO with the correct settings leaves just about as noiseless-yet-detailed a source as I've seen) followed by Blockbuster to put noise back in to insufficiently detailed areas and tame those DCT blocks produces extremely good results.

Unfortunately I've not had the chance to really give this a thorough testing. I've slotted it in fairly high on my to-do list though.

[drebel]

SansGrip,

Sorry for the delay, but i had to take an aspirin after rereading the whole thread...
A few comments for Blockbuster now:

1.It achieves its goal to reduce dct blocks.To be exact ,it almost eliminates them.It can't be considered as a complement to unfilter/lumoff combo(i've been using this method for quite sometime now and there is a BIG difference in the final result.I can confirm the sucess of the combo when the prob is not that obvious.)

2.The only method that gave good results so far was "sharpen".("blur" makes no difference and "noise" is second better in order)

3.Block_size really depends on the problem;a small size selection had better results in my encodings(especially in dark areas with high contrast

4.About "detail" level anything else but processing the WHOLE frame(detail_min=1,detail_max=100) gave artifacts:i remember a roof that was flashing(small ~white~ blocks allover the roof in a very low motion frame>There were also some white blocks around vertical-most of the time-edges.I dunno but it might have to do with the detail detection params(i tried everything in between) because the problem was solved by processing the whole frame

5.After iago's (and the rest of the community) suggestion i applied luma_offset=-2 .Great result!...except for the threshold.Everything less than 100 made SOME blocks look darker->more distinguishable to their neighbours(like tiny dots)

6.Strength is another thing worthy of mentioning.The default or less has no probs and produces clear frames.Anything above 30 gives "grid" effect and "scaling" artifacts on every edge(hope i make some sense..)

7.About compressibility i can't say much.I had to encode those movies at constant quant 2 with crystal clear final result but no predictability at all...

8.Given the final results and the minor speed penalty,i feel the need to congratulate you for all the effort.

best regards,
george

[drebel]

Ps:I still cant get acess to your site.Think i retry later...

[SansGrip]

Ps:I still cant get acess to your site.Think i retry later...

Should be fixed now. Sorry about the downtime.

(I'm in the middle of porting Blockbuster to YV12 right now, but I'll respond to your previous post later today :).)

[drebel]

Fix confirmed.Thx

[SansGrip]

Does anyone actually use chroma noise, or thinks it's at all useful? My tests show the benefits of the noise method comes from the luma noise, with chroma noise not seeming to make any difference.

It would be much simpler to port to YV12 if I got rid of chroma noise and just had all the methods working in luma. If I don't hear any calls for it to be retained in the next couple of days I'll take it out :).

[iago]

@SansGrip,

An immediate vote from me: throw it out and port to YV12 asap! ;) I'm looking forward to it!

best regards,
iago

[MaTTeR]

I agree with iago, forget about it and let's see how the YV12 port does:)

Edit- drebel has some valid points above and seems to match my observations as well though I never tried processing the entire frame. Can't wait to test the new build when it comes out though.

[SansGrip]

Ok, I think two votes is enough. I'm as impatient as anyone to get the YV12 port out ;). Working on it for 0.5, then for 0.6 we'll hopefully thrash out some ideas to address the issues raised above.

[SansGrip]

Here's 0.5 with minor changes for the Avisynth 2.0/YUY2 version but now includes an Avisynth 2.5/YUY2/YV12 version.

Changes:

* Removed chroma noising (and cm and cv parameters)
* Renamed lm and lv to mean and variance respectively
* Some small optimizations here and there

Even though not much has changed in the Avisynth 2.0/YUY2 version, I'd appreciate if everyone could upgrade in order to test this one works okay. You'll probably find it a bit faster too :).

Have fun.

Edit: Removed links to old version.

[MaTTeR]

Wow, that was really fast. Well of course I just loaded an encode in the queue and anxious to see what happens.

luma_offset & luma_threshold could be a God send if they work like I'm thinking they do. I'd much rather have the threshold areas darkened than the entire frame, this should be cool. Thx again!

[iago]

@SansGrip

Thanks a lot! I'll start playing with it immediately! ;)

@MaTTeR

What settings are you considering to try? I wanna compare it with mine! ;)

regards,
iago

[SansGrip]

2.The only method that gave good results so far was "sharpen".("blur" makes no difference and "noise" is second better in order)

I assume you're encoding with XViD. From what reports I've had I'm beginning to think that sharpen works better for MPEG-4 than noise, probably because MPEG-4 is so much better wrt DCT blocks than previous verions.

On the other hand, reports from others and my own experiences indicate that adding noise is the preferable solution for MPEG-1.

3.Block_size really depends on the problem;a small size selection had better results in my encodings(especially in dark areas with high contrast

Interesting. I've still not tried changing the block size, and I guess I really should ;). Can you be more specific about what sizes seem to work best with what source material?

4.About "detail" level anything else but processing the WHOLE frame(detail_min=1,detail_max=100) gave artifacts

This is quite possibly related to the sharpen method. The algorithm used is unsophisticated and fairly harsh, and better results would probably be achieved with an unsharp mask method. As far as light noise goes (variance=1-2) I definitely don't notice any artifacts in the encode (other than that the DCT blocks are gone ;)).

:i remember a roof that was flashing(small ~white~ blocks allover the roof in a very low motion frame>There were also some white blocks around vertical-most of the time-edges.

Sounds like the sharpening algorithm.

5.After iago's (and the rest of the community) suggestion i applied luma_offset=-2 .Great result!...except for the threshold.Everything less than 100 made SOME blocks look darker->more distinguishable to their neighbours(like tiny dots)

I wondered if that would be the case. Do you notice the same difference (and benefit) when using luma_offset=-1? As for the threshold, do you mean when you set it to 100 there are no noticible brightness changes?

6.Strength is another thing worthy of mentioning.The default or less has no probs and produces clear frames.Anything above 30 gives "grid" effect and "scaling" artifacts on every edge(hope i make some sense..)

Again, the algorithm is less than ideal. The sharpen and blur methods were really just a quick experiment, but if people are actually using them I'll take a look at improving them (maybe selecting a different matrix for sharpen) and also implementing an unsharp mask method.

8.Given the final results and the minor speed penalty,i feel the need to congratulate you for all the effort.

Thanks :). It's been a fairly long and frustrating process, but it's nice to see people actually using it for its intended purpose ;).

[SansGrip]

Wow, that was really fast.

I did say without chroma processing it would be simple :D.

Well of course I just loaded an encode in the queue and anxious to see what happens.

I'm anxious too! hehe

luma_offset & luma_threshold could be a God send if they work like I'm thinking they do.

Yet another feature I've not tried. I'm hoping that -1 doesn't result in noticible darkened blocks like drebel reported with -2. If it does I'm going to have to rack my brains to come up with a way of reducing the effect.

[SansGrip]

I'll start playing with it immediately! ;)

heheh excellent. Let me know what you think.

[iago]

hehe ;)

And know what! Just before BlockBuster I have FluxSmooth in my test scripts too, with some more aggressive settings than the defauls! ;)

iago