New smart sharpening filter

[Guest]

After concluding that my edge-masked smoother needed to go back to the shop for repairs, I had the sudden realization that the same basic engine would be great for masked sharpening, whereby important edges are sharpened but noise and fine detail are not amplified. And whereas an edge detection failure is very serious for a smoother, it is much less serious for a sharpener! So, here is my new smart sharpener:

http://shelob.mordor.net/dgraft/msharpen/msharpen10b1.zip

It basically implements the method described here:

http://cs.uhh.hawaii.edu/~jeschke/photography/articles/gimp/SmartSharpening/

It is highly effective on anime. For example, here are two images. The original is a direct DVD rip. It has a hazy, blurry cast. The sharpened one is overdone just a tad to emphasize my point. :)

http://shelob.mordor.net/dgraft/msharpen/hina_orig.jpg
http://shelob.mordor.net/dgraft/msharpen/hina_sharp.jpg

Feedback would be appreciated. Remember, this is a first beta and has no optimizations for speed.

[kyousuke]

interesting.

on your exemple, the background is very well.
but on the character, the sharpening seems to be to hight, on the character's edges for exemple.
i'll test your plug with less aggresive settings.

very interesting for a first version.
good luck for the next

+

[soulfx]

I like it. I been using UnFilter to sharpen up the picture a little after running it through the noise filters and had to set UnFilter low (5,5) in order to still get good compression and not re-introduce noise back into the video.

Tested out Msharpen and it works great. I can increase the sharpening more and not re-introduce noise back into the picture. I found Msharpen(strength=24) to achieve the same amount of compressibilty as UnFilter(5,5). The picture using Msharpen is more sharper and doesn't have the noise that is sharpened with UnFilter(5,5).

I haven't noticed any artifacts with it and it seems to be detecting the edges well at it's default threshold. Some tiny bit of edges are not detected, but they are so small that if the threshold was set lower it would probably start sharpening noise as well.

All that could be asked of now is more speed :)

It would be really nice to have somekind of sharpen filter built into the post-processing on the codec decorders. That way we wouldn't have to worry about sharpening and losing compressability in encoding. Just a thought anyways, but that deserves another thread if it doesn't allready exists.

Peace,
SoulFX

[-h]

It would be really nice to have somekind of sharpen filter built into the post-processing on the codec decorders. That way we wouldn't have to worry about sharpening and losing compressability in encoding. Just a thought anyways, but that deserves another thread if it doesn't allready exists.

ffdshow has this functionality. No idea how well it works.

-h

[Guest]

@kyousuke

Thanks for the feedback. You wrote:on your exemple, the background is very well. but on the character, the sharpening seems to be too high, on the character's edges for example.Maybe you missed the part where I said: "The sharpened one is overdone just a tad to emphasize my point." :)

YUY2 support as well as speed improvement is coming.

Who needs WarpSharp? :)

@soulfx

Thank you for the comments and I am happy that you find it useful. Good point about postprocessing!

@all

My last week or two has been very frustrating, with near failures coming from several new filter attempts. My masked temporal and spatial smoother filters are in the intensive care unit and it looks like the patients may not survive. :( I made an attempt at writing a *robust* duplicate detector that is insensitive to frame size, frame overall luminance, and noise, and which doesn't require a threshold. Believe me, that is a holy grail! It's funny though, because our brains can do the job quite easily, and I don't know how. Anyway, given the head-against-wall banging I've been doing recently, it felt good to make something that may actually be useful.

[trbarry]

Donald -

Cheer up. Nothing ever works on the first try, and most things NEVER work completly correct. I throw away more stuff than I ever release, and sometimes wish I'd pitched even more.

And sometimes it is only when I am finally just totally pi$$ed at some problem that I finally get some inspiration.

- Tom

[vidiot]

Originally posted by neuron2

...I made an attempt at writing a *robust* duplicate detector that is insensitive to frame size, frame overall luminance, and noise, and which doesn't require a threshold. Believe me, that is a holy grail! It's funny though, because our brains can do the job quite easily, and I don't know how. Anyway, given the head-against-wall banging I've been doing recently, it felt good to make something that may actually be useful.

So you´re making a new approach to the copysame filter from Marc FD?
Why the hell is it a difficult task to adopt the natural way of thinking (comparing)!(not really a question) - I would like to introduce the old idea of "fuzzy-logic". Just because even our brain and our eyes won´t work real good at these speeds - but good enough.

I hope you´ll have success with it!

;)

Harald

[Didée]

Originally posted by neuron2
[...]

Who needs WarpSharp? :)

[...] [/B]


Me.

---------

But first I have to test this new plaything, of course ...

[ErMaC]

The filter's definately a great concept. I just emailed Donald with some torture test clips from the Region 2 eva discs which have several different kinds of non-digital-related artifacts (all of them have to do with mastering issues and the DVDs themselves are almost a constant 9MBit/sec) that I can't seem to eliminate with the new sharpening filter.

Included is a screenshot of one of the trouble spots - it's like dotcrawl noise that I've seen in Laserdiscs before. The image is unsmoothed or sharpened, however sharpening it doesn't get rid of the problem from what I can tell.

[Blight]

This looks great for animation, the thing about warpsharp is that it worked really nicely for live footage as well.

I also would like to prompt support for ffdshow type post-processing for this filter. A lot of us have 320x240 type animation already encoded and doing real-time bicubic resize to 640x480 and applying such a filter should look amazing on animation.

[Guest]

@trbarry

Thanks for encouraging words. Of course, your perspective on this is imbued with wisdom.

@vidiot

>So you´re making a new approach to the copysame filter from Marc FD?

No. A good robust duplicate detector has all sorts of applications. But specifically, I want it for Decimate().

>Why the hell is it a difficult task to adopt the natural way of
>thinking (comparing)!(not really a question)

Nobody yet understands how our brains do the work that they do!

>I would like to introduce the old idea of "fuzzy-logic".

That's an idea. I'll look into it.

@Didee

I have a problem with the *concept* of WarpSharp. It is just too destructive of video content for my taste. I can show you simple clips where even with low strengths the distortion of features is really bad. But as they say, one man's meat...

@ErMaC

>Included is a screenshot of one of the trouble spots - it's like
>dotcrawl noise that I've seen in Laserdiscs before. The image is
>unsmoothed or sharpened, however sharpening it doesn't get rid of
>the problem from what I can tell.

There's no reason to suppose a sharpening filter will remove artifacts! I'll be happy to look at your clips with a view to helping you, but this filter is not designed for such tasks.

@Blight

This filter works fine on live footage as well.

[Acaila]

Very interesting filter neuron2.

One thing that had me confused a bit is the way the threshold threshold works. Lower it and you'll increase the sharpening effect, increase it and you'll get less sharpening. Most filter's thresholds work the other way around...
I couldn't detect much effect of the strength setting, the threshold setting had a far greater effect in comparison.

I couldn't detect any noise amplification, which is great (and as it should be I know :))

Even for normal movies this filter seems to work great, I applied it to my Matrix rip for the better (threshold=5, strength=50). For a first test it worked marvelous. I don't have any anime to test it on, so..

Great job, keep up the good work!

Ps. It does seem to increase the EE effect though, but I guess that's unavoidable?

[Guest]

@Acaila

No, no, no. You're all confused. :)

The threshold sets the amount of picture that is considered edges. Set mask to true and then play with threshold. You want to have just the important edges shown and not grain or noise. Then turn off mask and the strength will determine how much sharpening is applied to the areas that showed as white in the mask=true view. Strength 255 is a fairly strong sharpen, so if you just played around with values close to 50, you may have thought it didn't have much effect. The sharpening is continuously variable from strength 0 to 255.

You appear to get more sharpening as you lower the threshold because more areas of the picture get included in the sharpening. But don't set it too low or you'll amplify noise again.

You don't need a really low threshold because the eye is going to be drawn to the important edges; those are the ones you want to sharpen. This is why the masking idea works better for sharpening than smoothing. For smoothing an edge detection failure destroys picture content; for sharpening, it leaves it alone. :)

Please, what is the EE effect?

[MaTTeR]

Originally posted by Acaila

One thing that had me confused a bit is the way the threshold threshold works. Lower it and you'll increase the sharpening effect, increase it and you'll get less sharpening. Most filter's thresholds work the other way around...


Correct me if I'm wrong somebody but I think Unsharp Masking in Photoshop and Gimp work exactly as the filter does here. Perhaps it's just the nature of UM but you will notice the same effect when using Photoshop.

Judging by the before/after screenshots that Acaila sent me this filter looks very impressive to say the least. I hardly noticed any added noise to the processed shot:)

[Guest]

No, it's much better than unsharp masking, because it affects only the edges. Go to the web site I linked and you'll see comparisons. Unsharp masking is really nothing special. It's just an old photographer's term for a sharpening convolution kernel. The key for this filter is that it applies the kernel only to the edge areas.

[Acaila]

No, no, no. You're all confused. :)That's ok, happens all the time :)
I think Koepi can attest to that ;)

You get more sharpening as you lower the threshold because more areas of the picture get included in the sharpening.So lower threshold => increased effect, higher threshold => decreased effect as I said. But most filters work lower theshold => decreased effect, higher threshold => increased effect. I did play around with the mask/threshold settings and they supported this (lower theshold => more white).
So I don't really understand which part I'm confused about..

EE = Edge Enhancement
Sharpening done during the DVD creation process, creates halos around contrasting lines when done too strongly.
Almost all DVD's have it (that I have seen), but usually it's hardly noticable. Until you apply a sharpening filter which obviously strengthens this effect. I don't think there's any avoiding this though, as how else are we supposed to sharpen something?

Maybe only sharpening in luma or chroma gives a better output? Just an (crazy ;)) idea.

[Guest]

@Acaila

OK, you're not confused. :) The threshold parameter is for the edge detector. Think of it that way. The lower the threshold, the more edges you see.

When I perfect my masked smoother (rough beta already available), you'll be able to remove the EE's prior to the sharpening stage.

I already plan for Y only when I add the YUV support.

[zettai]

@neuron2

Do you think it could be worthwhile combining the sharpen and smoother into one filter using the same mask or do you envisage a situation where you might want a different edge threshold for the sharpen and for the blur?

I guess it would only matter for simplicity and possibly speed, not sure - just thinking out loud.

[Guest]

@zettai

Yes, it is a fairly obvious final step to combine the two filters. But it is premature for that right now (until the independent functions are robust and valuable on their own). I think it is already clear that the masking will have to be different for the two. It would be a big mistake to prematurely do this without understanding and perfecting to the extent possible each function in isolation. It is the smoothing that needs more work at this stage. I view combining them as an optimization, and not as any kind of wonderful clever new concept. :)

[Zarxrax]

Wow, this is easily the best sharpening filter for anime thats out there! There's one hitch though, perhaps you could help me understand a little better. Sharpening filters always make the video less compressible. On a small test I just did with this filter (default settings, 100% quality in xvid), the sharpened version came out 60% larger. Now that is a HUGE compressibility hit! What I'm thinking, is if one were to use this filter, then it would obviously make the movie less compressible, causing a larger average quantizer. Now by having larger quantizers, that would just smooth the pitcture back out a lot wouldnt it? So in the end, wouldn't you end up with something that was no sharper (possibly even blurrier) than the original, and significantly lower quality than if you would have just encoded without the sharpening?

[Guest]

60% sounds high. I will do some experiments.

[Bulletproof]

That is a known debate, some people prefer to encode using Bilnear filters when using MPEG-4 codecs. The files will not be as sharp, but compression will be better. It is known that MPEG-4 codecs do not like sharp edges, however this does not in any way make sharpening filters useless. XviD has options to use an MPEG quantizer which is sharper than H263 and you should be able to retain the sharp details. There is also the future obviously and there is a ton of possibilities and improvements that can be made in the video encoding world, which makes it so exciting.

[Guest]

My tests showed a 49% increase. I guess Bulletproof is right (for present technology). Do you want sharp or do you want small? It is your choice. :)

[Guest]

How silly of me. MSharpen just *is* a filter for doing (narrow) EE. :) What I was referring to was the ability to remove mosquito noise prior to applying MSharpen.

But it occurred to me (as things are wont to do from time to time) that if you did unsharpening (contrast reduction, not blurring) just in the edge areas (!), you would attenuate exisiting EE. You'd have to dilate the edge map I imagine. Soon to appear then: my AntiEE filter!

I can use MSharpen to make torture test clips for AntiEE. ;)

[Guest]

It also occurred to me that I can replace the standard sharpen kernel with the same kernel used in Xsharpen (or some other rank order kernel), thereby avoiding the EE that some find objectionable. I will experiment with it.

[Defiler]

This is cool. I was compressing the new He-Man movie (animated) the other day, and I thought to myself "What I really need here is the opposite of MSmooth."
Even if it hurts compressibility, and it will, there are times when you have plenty of bits. Example: One hour cartoon, 464x464 resolution, one 700MB CD.
Time for some testing, I think.

[Bulletproof]

I've been actually looking for a filter that darkens the lines to the animation. This would be a sort of sharpening filter which wouldn't cause the codec to use extra bits, in fact, it would probably save some (very minor). The only problem is that current thresholds cannot accurately detect the lines. I do have the coring filter but this causes problems with shadows that are not pure black. In fact all video is missing pure black, its all mixed shades of black which is causing the problem. Often times I get speckled black dots when using the coring filter cause it cannot clamp to all the proper shades. Though maybe if you use a denoiser on the mask?

[stickboy]

Have you tried flaXen's Cartoon Filter (http://shelob.mordor.net/dgraft/flaxen/flaxen.html) for VirtualDub?

[ErMaC]

Jeez neuron, how many filter are you gonna get out of this edge detection algorithm of yours?

Make an edge-constrained coring filter like the person above might be able to use? :D

Maybe an edge-constrained blurring type algorithm to help remove aliasing from deinterlaced-via-interpolated frames?

Or even weirder, and edge-constrained warp sharping filter?

[Belgabor]

Hm, mentioning the algorhythm, instead of completely relying on threshold, perhaps some kind of "filter" to exclude noise could be added to the edge detect algorhythm.

Just a funny idea of mine.

Cheers
Belgabor

[Guest]

MSharpen version 1.0 beta 2 is now available:

http://shelob.mordor.net/dgraft/msharpen/msharpen10b2.zip

This version is improved as follows:

* Supports YUY2 and RGB space -- no conversions required.
* Significantly faster, especially in YUY2 space.
* Sharpens only the Y channel in YUY2 space.
* Default parameters can be defined by the user.
* High/low quality edge detection to allow quality/speed tradeoff.
* Improved and updated documentation.

Feedback will be appreciated.

Future versions will add:

* Additional sharpening algorithms, e.g., rank order.
* Low-level optimizations for speed.
* Release of source code under GPL.

Thank you for your feedback and support.

[Guest]

I had a bad copy of Beta 2 up there for about 15 minutes. If you downloaded it then and think it acts as if the default threshold is 150, you're right! Download it again, please.

Thankfully, I have a policy of always downloading the uploaded filter and testing it as if I am a user. :)

[Guest]

@Belgabor

The edge detection already has some noise reduction. It could be better but we have a competing user requirement: SPEED!

[Guest]

@ErMaC

Now this is why I love this forum so much. You guys emit an unceasing stream of interesting ideas! Thanks. I'll queue those up behind my AntiEE filter.

[Bulletproof]

It's too bad you can't use the Sharpening filter and the filter to blur out jaggies from deinterlacing at the same time, or can you? ;)

Warpsharp might benefit from this as well if it could tell which frames are jagged, cause weird artifacts happen if you use a moderate strength warpsharp on jagged edged frames.

[stickboy]

Originally posted by ErMaC
Jeez neuron, how many filter are you gonna get out of this edge detection algorithm of yours?How about adding general masking operations to avisynth, and then you can create an edge mask and apply whatever filters you want with it.

[Guest]

Sounds good but many things *require* the functions to be integrated.

Anyway, there is the Layer filter, but I've never been able to make it work and it is not general enough.

[OUTPinged_]

@DG: Msharpen is a really great step forward from warpsharp.

Here is an idea for a blur filter of similar kind.

There is a problem with crappy dvds that some edges are overdone already (too sharp comparing to other). Sharpening the rest of the image is an option, but there are cases when the lines are just too sharp and current "smart blur" filters like UnFilter are blurring the smooth edges too (though to a lesser extent than a "dumb" blur filter).

What is needed there is a filter that will find those "too sharp" edges and blur them a bit so we get unified amount of peak sharpness in the encode (edge can be more blurry than the thresh, but not more sharp).



And AntiEE filter will be an absolute killer stuff :-) Enormous amount of old animes will be possible to rip with sharp lines and get rid of that "i smell a vhs source in your encode" approach.

[PrinceAli0]

Ok this may sound silly but I'm just beginning to understand this whole encoding process of DVD (specifically anime) to DivX, XviD, ect. I reviewed your pictures and this sharpening filter looks great. From what I understand it is to be used with the program Avisynth, is there plans to port this to VirtualDub or is there a plugin that I can add to my .avs file that I load up into VirtualDub for encoding that will make use of this excellent sharpening filter. Have I gone completely off track here or do I make some sense, please let me know.

Thanks

PrinceAli0

[Didée]

@PrinceAli0

[Having a big grin on my face]
One of the most-often-arising-question is: "I desperately need the Vdub filter XYZ, could anyone port it to AviSynth, please?"
The other way round is a really rare case.

Big tip: Learn AviSynth!
You may not see the all the advantages by now - but once you got it, you´ll wonder how you could have ever done without it.

[Didée]

Originally posted by OUTPinged_
@DG: Msharpen is a really great step forward from warpsharp.

[First: Donald, I really appreciate your msharpen filter, and all the others, too. Always great work.]

But I want to state - once more - that WarpSharp should NOT be compared with ANY pixel sharpening filters. These are two totally different techniques. Anyone wants to compare "Resize" with "Loop"? Which one is better?

All pixel sharpeners enhance the delta of a pixel to its environment.
WarpSharp modifies the environment.

All pixel sharpeners make the content less compressable.
WarpSharp increases compressability!

Take some over-blurry content.
What can a pixel sharpener do with it? Nothing!
WarpSharp can, to a certain amount.
(If a one-pixel boundary gets so blurred that it extends over more than three pixels, pixel sharpeners won´t bite at all - except for unsharp masking, but that´s another story.)

On the other hand:
- WarpSharp does a bad job with very fine detail
- too strong settings yield to very strange results
- [much more ...]

I´m really looking forward to what might be squeezed out of msharpen, it will be a really great filter. It is yet now, indeed.

But, for sure, it is not the successor to WarpSharp.

Thanks for reading (and thinking about ;) )

Didée

[manono]

Hi-

My first reaction to the Prince's post was the same as yours Didee (sorry-my keyboard doesn't know how to make the accent over the "e"). But then I read it again, and it looks to me like PrinceAli0 is already frameserving with an .avs.

So, Prince, it's the same process as using TextSub in the other post of yours. You load the plugin and add the Msharpen line to your .avs. The neuron2 filters always come with very good documentation, so if you read it, I think you can figure it out. Good Luck.

[OUTPinged_]

didee:

It is a successor to warpsharp ripper-wise(I know it uses different kind of algorithm). it does similar sharpening and it doesnt make straight lines curvy. If group rippers will finally stop using ws+sshiq with high thresholds... :-)

Can warpsharp be enchanced to keep lines straight? :-(

[Belgabor]

Originally posted by neuron2
@Belgabor

The edge detection already has some noise reduction. It could be better but we have a competing user requirement: SPEED!

Well, if we're talking users here, if it isnt too big a hassle, why don't let the user decide? (lets say mode=0 - no added edge noise removal, mode=1 - additional edge noise detection, mode=2 - [new idea] trying to discern between 'pointy' noise and 'liney' edges [which is prolly very very hard to code & slow])

A point would be you could treat a difficult scene with a lower mode (speedwise) and the rest of the movie with mode=0 so the total speed impact would be bearable.

Cheers
Belgabor

[PrinceAli0]

manono,

I think I'll just give all credit to my encoding to you my friend. You have helped me sooooooo much. I'd hug ya if you were here :) I figured it'd be another line in my .avs file as I read in the doom9 guides that it is the instruction file for frame serving or something in that manner, plus what you told me in my other posts and the instructions I read from the guide included in neuron2's work tiped me to that. But i figured I'd check first before I did anything stupid in my learning process.


To better understand this from my perspective, what Didee is saying is that avisynth is another frame server like virtual dub, right ? I'm gonna read the comparison on the two but I think its by the maker of avisynth (might be wrong here), is there something less biased by a 3rd party like Doom9(if that comparision is biased at all, I haven't looked at it yet)

Thanks

PrinceAli0

[MoonWalker]

Hi neuron2,

After knowing that Msmooth10b2 is in your garage for repairs :) I decided to test Msharpen10b2..There wasn't something I didn't like..There was a thin line on the edges..I thought maybe it was the strength..Firstly I set it to 100(default) and then raising and lowering to see what was happening..Raising was main this more strong, lower made less strong but still noticable..I attach an image with strength 20..

My avs :

SetMemoryMax(40)
LoadPlugin("D:\DivX\GORDIA~1\mpeg2dec.dll")
LoadPlugin("J:\Matrix\1cd-xvid\640\New Folder\MSharpen.dll")
mpeg2source("J:\Matrix\matrix.d2v")
MSharpen(threshold=7,strength=20)
Crop(0,78,720,420)
BicubicResize(640,272,0,0.5)

MoonWalker

[Bulletproof]

I'm not sure, but I think that's what the filter is supposed to do. It's raising the contrast on edges and not raising the contrast on noise.

[High Speed Dubb]

Originally posted by neuron2
But it occurred to me (as things are wont to do from time to time) that if you did unsharpening (contrast reduction, not blurring) just in the edge areas (!), you would attenuate exisiting EE.

@Neuron,
How does unsharpening differ from blurring?

[soulfx]

Yeppers. Thats a normal operation of a sharpen filter. DVD's might not be the best source to test out for sharpening as they are allready probably sharpened anyways.

To really figure out how good this filter works get yourself something that just seems like your looking at it through cateracts and give it a shot (either an orig. source or just run a source through some filters to soften it up a little).

Peace,
SoulFX

[kyousuke]

@donald
thx for the YUY2 mode :)
i always work in this mode when a filter can do it

about this :
* Sharpens only the Y channel in YUY2 space.
could you give me some informations ? Could we sharp X channel in future or not ? etc... thanks :)


@moonwalker
donald said : Although designed specifically for anime, it may be useful elsewhere.
it's right but don't really exact for now on non-anime videos.
perhaps it's a sharpening bug on the edge's chroma with the background, don't know really...
tests this : MSharpen(threshold=7,strength=20,mask=true)

i think you should wait new sharpening algorithms.

++

[int 21h]

(1) The 'over-sharpening' effect that Moonwalker is showing is from too low of a threshold. I've also found that the default value of 10 is also way to low for regular action movies. Through a series of tests with mask=true, I've found that a nearly optimal value for regular action movies is around 25. (i.e. threshold=25)

(2) Currently there is a bug causing a corrupted line to appear, approximately 2 pixels wide on the very last line of the image. I tried feeding MSharpen mod2,mod4,mod8,and mod16, all displayed the same bug. Removing MSharpen no longer showed the corrupted line.

(3) Please consider changing the parameters to use the 'default' avisynth behavior of Function(variablevalue,variablevalue,variablevalue) instead of Function(variable=value,variable=value) ;)

(4) I've been looking for a good EE filter (that doesnt amplify the already present EE in DVDs) to use for SVCD encodings in higher bitrate situations, this is well on its way to becoming that filter once the corrupted line thing gets fixed.

Great work.

[Guest]

Lots to respond to. And I'm loaded up with red wine, so this should be entertaining. Also, I hope to have some energy to ramble on a bit at the end, if you will be so kind as to indulge me.

@PrinceAli0

Yes, I do plan to port this filter to VirtualDub. But you should still learn avisynth and embrace it, because there are important things it can do that just CAN'T BE DONE in VirtualDub, such as arbitrary frame decimation.

@didee

Sure, warpsharp is a different algorithm that works by in effect moving pixels. I won't doubt that it has an application domain, but for me personally, it is vanishingly small. If it solves problems for you, however, then who can challenge that? I do suggest that MSharpen perhaps preempts some applications that might previously have fallen to warpsharp. But it is for every user to decide.

@belgabor

Yes, your point is perfectly valid. But given my limited time I have to prioritise my work for potential gain. I am not convinced that additional noise filtering here brings a large enough gain to stop me from working on my new generation duplicate detection, for example. But keep the ideas coming. PLEASE!

@PrinceAli0

You gave all your credit to manono. I too will acknowledge a significant debt to him. Wise but open to new ideas. Critical but sensitive to one's sensitivities. Thorough but capable of the quick study. And it is not just in the realm of image processing that my debt to him lies!

@Moonwalker

Those haloes are too strong for a strength setting of 20, implying they were already present to a great degree prior to processing. I therefore agree with Bulletproof's, and especially soulfx's, diagnoses.

@High-Speed Dubb

>How does unsharpening differ from blurring?

Oh, isn't it obvious? :) Blurring implies absorbing information from adjacent pixels and mixing it with the center pixel's information. But we can change contrast without doing that. For example, suppose we adopt the rule: divide each pixel by 2. That reduces contrast without absorbing neighboring information. We'd probably want to add some offset to bring the average luminance level back up, of course. And that is not the best way, or the way I would actually adopt, but it is a simple rule that shows that you can systematically change the contrast without blurring.

Now is unsharpening the same as reducing contrast? In a case where we can't sample with a higher frequency, that is all that is left to adjust, and indeed that is the most important aspect of what people subjectively perceive as sharp (given a sampling rate); the degree of contrast. You can't resample your 720x480 frame to give more detail, but you can change the contrast such that the observer says "Ooh, that is sharper."

@kyousuke

Perhaps you have confused Y with the Y dimension spatially and thus concluded that I don't sharpen in the X dimension? But Y refers to the Y channel of the color space, i.e., luminance. So in the YUY2 version, only the luminance is sharpened, not the chroma information. The sharpening is performed in both the X and Y spatial dimensions. In fact, it is arguably better to sharpen only the luminance (Y) channel, but I won't insult your intelligence by explaining why. :)

Tell me, what is this postulated bug you speak of that you think necessitates a new version. Your allusion is tantalizing but regretfully devoid of sufficient detail to allow me to address the issue. Thank you.

@all

Now, if I might be permitted to ramble just a little. But first, my glass needs refilling. I will also enter my imprecise language mode.

So, don't y'all just hate thresholds? I mean, they're so Aristotelian. This quantity must be DECLARED as A or not-A, and I am going to enforce it immediately, right here and now, with this line I have etched in stone. If you are bigger, hey, I'm sorry! I'm sure you have great reasons and excuses, but YOU ARE IN CATEGORY A. Suck it up, live with it, get a life.

Sure it's *convenient* for us; we can apply our little Boolean laws of logic, our mathematics, our excluded middles. But is that always the right thing to do? Will it always give us the best solutions to our problems? I submit not. I submit that we can "crispify" our representations too early, such that important usable information is discarded *too early* in the analysis and problem solving process.

Is this beginning to sound reminiscent of fuzzy set theory? Yes. I seldom undergo significant paradigm shifts in my basic thinking but my recent exposure to this area (triggered by a post here, and I plan to look it up so as to credit the person who nudged me that way) has amounted to one. It's not something that can be quickly explained, but in future posts I want to try to give examples of how we can apply our boolean thinking too early, to the detriment of the solution of our problem. This is leading to better ways to do field matching, and better ways to do duplicate detection, much more robust ways, ways that do not require the pre-specification of delicate and unreliable thresholds.

Stay tuned, there are exciting things floating around.

[Guest]

@int 21h

You posted while I was rambling. :)

1) Oh, yeah. Why didn't I think of that?

2) Ooh, a bug. I hate bugs. I'll get right on it. Please forgive me for this unspeakably horrific manifestation of carelessness. It really is totally unlike me. Really.

3) Here's a secret. Don't TELL! You can already do that. Try this:

Msharpen(false,15,100)

I'd just have to put the most-used options at the front and publish the correct order:

MSharpen(match,threshold,strength,debug)

I will do that and mention it in my renowned documentation. :)

4) This filter has a kernel size of 3. That is probably why it doesn't appear to affect existing wider EE, as long as the detected edges are kept under control. For sharpening, you don't need or want wide kernels and I am a little baffled why they seem so large on DVD EE. Could it be that it is added with analog methods???

[Guest]

@int 21h

OK, here's the deal. When you use a 3x3 kernel, you can't apply it to the edge pixels of the image. So these are passed through. Now for technical reasons (that means I can't remember why), I pass through 2 lines at the bottom directly from the source image. You'll see, the lines only appear "corrupted" at a sharpened area. Also, you'll see it around the rest of the frame if you look for it.

First, confirm this is what you see. Then we can decide what to do about it. If it is something more serious (which I doubt), please tell me.

I can certainly reduce it to one line. I can also try to do a non-centered 2x3 kernel but that is very yucky code-wise. What do you think?

[Guest]

@MoonWalker

Look at the tie, and especially its reflection in the table. The effect is on the left only!!! MSharpen is not asymmetric in any regard that would account for this. Ergo, it must be in the source material. Please post the same frame UNPROCESSED by MSharpen.

[int 21h]

I didn't mean to offend you with my bug report :confused: Sometimes I just post somewhat tersely.

I've posted an example pic here: http://phreak404.virtualave.net/ee.jpg

As far as the variablevalue vs variable=value thing goes, I did try just putting the values in first out of habit.. but got the exception from Avisynth of 'bad' parameter values, so I was somewhat confused. Thanks for straightening that out though.

I'm doing a test encode with the filter enabled now, to workaround the forementioned bug, I just cropped 2 pixels up after Msharpen. (Tried putting Msharpen before any crop at all, however, as you can imagine, the edge of the letterboxing is detected and that makes a sort of undesirable effect)

As far as the digital vs analogue EE thing goes, I'm not as particular about it as most people. For instance, I find the EE in Lord of the Rings DVD quite satisfying. Of course, I'm still living in the stoneage with my 36" analogue television with its pitiful 3-line combfilter and component video via DVDPlayer. ;)

That Aristotle, sharpening, smoothening, boolean stuff really tripped me out.

Thanks again for the work.

[High Speed Dubb]

@Neuron,

So the idea is to deemphasize the edges in the picture? That sounds worth a try, but I’m somewhat worried that the output will look odd.

Originally posted by neuron2
Is this beginning to sound reminiscent of fuzzy set theory? Yes...I've got a couple glasses of (hard) cider to compete with your wine, so I feel qualified to emphatically disagree with this (while simultaneously emphatically agreeing with your main points). ;)

In my opinion, fuzzy logic is just an approximate version of probability theory. So I’ll suggest that fuzzy logic is not the right example from which to build. It’s more productive to use a probability model, and to switch to an approximate method only at the last stage of implementation.

But yes, hard thresholds are bound to cause artifacts. Whenever you change from a region less than a threshold to a region above it, you get an edge effect. I've had a lot of luck with noise filters by weighting the “it’s noise” and “it’s motion” colors proportional to their fit with the data. This can be justified by assuming that perceived color error is ~(real color - displayed color)^2.
[edited to remove some irrelevant stuff]

(Feeling a bit fuzzy, myself, though. ;) )

[Guest]

@int 21h

Oh, I didn't take offense at your bug report. I was just mortally embarrassed.

Hey! You said the last two lines were affected. But your frame is letter boxed, so it isn't the last two lines; it is interior frame lines, isn't it? We have to be precise about this stuff. Or did you add the letterboxing after applying MSharpen?

Now sure, a sharpener is going to get irritated at such boundaries, and that is why my VirtualDub Unsharp Mask filter has configurable ignore zones just so you can exclude the black bars. This filter needs that too.

But the bottom edge is worse than the top one. So, please send me a one frame HUFYUV of the original unprocessed source, as well as the script you apply. I will fix this very quickly. And thank you for pointing it out.

When you tried the variable thing, did you try the order I gave, i.e., is it not working?

That's a pretty primitive system you have there. :)

Your trip has only just begun.

[Guest]

@High-Speed Dubb

Look, you're not allowed to disagree with me. Haven't you learned that yet? I don't care how much cider you've drunk. But I do love cider. Especially that rough scrumpy stuff they serve up in Western England.

But seriously...

>So the idea is to deemphasize the edges in the picture?
>That sounds worth a try, but I’m somewhat worried that the
>output will look odd.

No, the idea is to deemphasize the contrast only in the zones outside and bordering the edges. We wouldn't do it to the edges themselves. How? Here's a possible approach. Use a Laplacian such as 8 surrounded by -1's as your edge detection kernel, instead of the 1st order Roberts-like kernels I use now. This gives you fairly thin, well-localized edges. Then save that. Now dilate a copy of it and subtract the original. This isolates the areas *outside* the edges. Then do contrast reduction in those areas. Will it work well? Is it practical? Don't know yet.

I don't think fuzzy set theory can be reduced to probability but now you'll ask me to prove it. Let me ponder a counter example and return later with my argument.

>proportional to their fit with the data

With what data? Give example please.

Another aspect is to always use relative differences. For example, people talk about SAD, but it is an absolute, not relative measure. So, for example, if you have a pixel t and a pixel r, and you want a measure of their "difference", better than abs(t-r) is:

D = abs(t-r)/(t+r)

Think about how this automatically normalizes in darker areas! It is too late to take this extra information into account if we start by doing SAD.

[High Speed Dubb]

It’s even English cider (though I don’t know what region, and I can’t describe it as scrumpy :) ) — The local Trader Joe’s had a sale on Blackthorn.

...

That does sound like a nice idea for edge de-enhancement. The amount of dilation may need to be user selectable (and separately for vertical and horizontal), though — I gave up on some attempts at a de-ringing filter after noticing that the amount of ringing varies considerably from source to source.

...

By “proportional to a fit with the data,” I meant the probability of the data for a particular hypothesis (motion or noise).

For example, if noise is ~Normal(sigma = 3) and motion is approximated to follow a Brownian model ~Normal(sigma = 10), then if the change in a pixel value is 2, then:

P(change = 2 | change due to noise) = (1/(sqrt(2*pi)*3))*exp(-(2^2)/(2*3^2)) ~= 0.10648
P(change = 2 | change due to motion) = (1/(sqrt(2*pi)*10))*exp(-(2^2)/(2*10^2)) ~= 0.03910

So you weight 39 parts toward the motion value (i.e., keep the new pixel value), and 106 parts toward the noise value (i.e., keep the old pixel value).

or for a change of 20, you get
P(change = 20 | change due to noise) ~= 2.9703 * 10^-11
P(change = 20 | change due to motion) ~= 0.0053990

So here you’re pretty much sure it’s motion, and you just go with the new value.

(I skipped some important stuff, like that the moving pixels have noise, too, and that round off error needs to be dealt with explicitly. And I probably messed up some of the arithmetic. ;) )

Of course, this is one of many possible models. And a different model will generally give different likelihoods.

...

About relative differences — For noise, you don’t want to normalize for brightness. At least with my NTSC reception, noise is normally distributed with the same variance regardless of the brightness. The only exception comes with very low brightness values, where there’s an edge effect, and the noise follows a truncated normal with a spike at 0.

[Guest]

@High-Speed Dubb

As long as it has bubbles...

Nice idea to take the noise model into account. I'll have to experiment with that. But I don't see how you can model the motion.

Are you saying never to use relative measures, or only not in the presence of lots of noise? I have clips that manifestly get better duplicate detection when I use relative measures. Especially one dark, smoky one that manono gave me. By better I mean with a generic threshold that works for bright and dark scenes. You can't tweak a threshold at every scene change. :)

It seems to me that without relative measures your thresholds become too sensitive.

[High Speed Dubb]

Yep, and it’s definitely tasty. My international snack is now into the Camembert. :)

Small change motion can look pretty close to Brownian. Big change motion doesn’t look even vaguely Brownian, but that isn’t so important — Any model will distinguish large scale motion from noise. It’s the subtle stuff which is hard to detect.

More importantly — My next step here was to play around with the resulting curve in a graphing program, and see how sensitive it was to sigma_noise and simga_motion. The result was... the amount of motion isn’t really that important, so long as it’s at least as much as the noise. So for the real implementation, I just used a formula which approximated the result, and skipped most of the calculation.

About detecting duplicates... I can think of two reasons why normalizing for brightness would help. One is that the source material has been processed, for example by compression. In that case, the noise distribution could have been changed quite a bit. The other possibility is that it has a lot of very dark areas. If that's the case, you can get a much more efficient normalization function using a truncated normal distribution.

[Guest]

>If that's the case, you can get a much more efficient normalization
>function using a truncated normal distribution.

What would all this mean in practice? What would your duplicate detector look like in pseudocode? (I am not a probability theorist; just a simple pragmatist). Thank you.

[High Speed Dubb]

The quick and easy way to test this is to toss any pixels which are dim ( Y <= 32 ) out of the analysis, and to normalize appropriately. (i.e., divide by the number of pixels which weren&rsquo;t thrown out.) That isn&rsquo;t completely safe, though, because it&rsquo;s possible the entire screen could be dim.

The more robust way to do it is to include the dim pixels...
If (Y value > some threshold)
Add the |difference| to C = cumulative difference
Increment X = number of pixels observed
else if (current or last Y value == 0)
Toss it [this is inefficient, but the math gets difficult]
else
Add the |difference| to C
X += normalization constant, from a lookup table
Making the lookup table for constants would go something like:
Normalization[Y_old, Y_new] = P[Y_old not thrown out | real color, noise variance] * P[Y_new not thrown out | real color, noise variance]
The easiest way to get the P[]s is to read them from a pregenerated textbook normal distribution table.

The fudge here is that you don&rsquo;t know the real color. But you can come up with a decent approximation, like the old pixel value, or some weighted function of the old and new.

P.S. At the end, you&rsquo;d use C/X as your similarity statistic.

[Blight]

I'd like to put this to a vote, who's with me for asking neuron2 to look into ffdshow for real-time post-processing using his great filters!

We really need these in a real-time env.

[sh0dan]

AviSynth can in many cases be used in real-time environment, when using YUY2 colorspace - and with the new Compressed audio support this is very much possible.
We have talked about implementing YU12 as a native colorspace in AviSynth for the next generation, so Avisynth can be used for even faster postprocessing on these sources.

[ErMaC]

Donald - I know you've probably got a lot of filter ideas on your plate, but I was talking to Tim Park last night (author of the SSiQ plugin) and I had the brainstorm of using your Edge-Constraining algorithm paired with his Chroma Smoothing algorithm.

Basically, the reason the chroma smoother exists is to eliminate the "moire" or "rainbow" effects that show up on hard black edges in the picture. By smoothing the chroma this helps eliminate that. However the filter is extremely slow because it does it on the entire picture.

Since what we want to fix is the edges anyway - why not simply chroma smooth only the areas constrained by the filter?

This filter, if it worked, I would _pay_ for. Dear lord, my knees get weak just thinking about it because it means I could finally encode my friend's Mamotte Shugogetten LDs without those horrid moire effects.

[int 21h]

Originally posted by neuron2
@int 21h

Oh, I didn't take offense at your bug report. I was just mortally embarrassed.


Ah well shit happens.


Hey! You said the last two lines were affected. But your frame is letter boxed, so it isn't the last two lines; it is interior frame lines, isn't it? We have to be precise about this stuff. Or did you add the letterboxing after applying MSharpen?


It is the last two lines, in my script, I Crop, Msharpen, Resize, Letterbox. :)


Now sure, a sharpener is going to get irritated at such boundaries, and that is why my VirtualDub Unsharp Mask filter has configurable ignore zones just so you can exclude the black bars. This filter needs that too.


By cropping, then putting in Msharpen before AddBorders, you don't have to worry about this.


But the bottom edge is worse than the top one. So, please send me a one frame HUFYUV of the original unprocessed source, as well as the script you apply. I will fix this very quickly. And thank you for pointing it out.


http://phreak404.virtualave.net/trouble.rar

Contains a 1 frame AVI compressed with HUFFYUV and the Avisynth script I was(am) using.


When you tried the variable thing, did you try the order I gave, i.e., is it not working?

That's a pretty primitive system you have there. :)

Your trip has only just begun.

I'll try the variable thing out more precisely tonight. :D

[Guest]

@Blight

I have already provided the source code to (one of?) the developer of ffdshow, Milan Cutka.

@ErMac

Just yesterday I received in the mail a filter like that from a gentleman name Kurosu. I've not looked at it yet. I have the policy of not jumping into areas others have staked out without their blessing. So let's see if Kurosu can get this filter into a usable state. I will report on the progress, or have him begin posting here.

@int 21h

Thanks for the clip. Fix forthcoming.

@High Speed Dubb

Thank you for taking the time to share your ideas with us. I will have to do some testing before commenting.

[int 21h]

Since I'm stuck at work, I'll post some other interesting findings. :p

(1) Make sure you resize after Msharpen, and not before. If you resize before Msharpen (trying to save some speed and whatnot), your edges will be very jagged (because its trying to apply MSharpen).

(2) Make sure you add borders after MSharpen. As previously noted in this thread, if you don't crop out all of the black, the edges of the letterboxing will be very very visible.

Make sure you realize the implications of using this filter on material before you go applying it to everything. (i.e. you need to have a good chunk of bits available)

[Guest]

@High-Speed Dubb

Everything was going good until I hit this:

Making the lookup table for constants would go something like:
Normalization[Y_old, Y_new] = P[Y_old not thrown out | real color, noise variance] * P[Y_new not thrown out | real color, noise variance]
The easiest way to get the P[]s is to read them from a pregenerated textbook normal distribution table.

The fudge here is that you don’t know the real color. But you can come up with a decent approximation, like the old pixel value, or some weighted function of the old and new.I don't understand the notation as I am not a probability theorist, as I pointed out earlier. Can you put it into English that I can understand, please? Thank you for your patience.

[Guest]

@int 21h

I found and fixed the problem. I'll post the new version later today.

At one point I used the destination pitch instead of the source pitch. :)

[Guest]

Here it is:

[Guest]

@ErMaC

Post a few of the bad frames from Mamotte thingie.

[ErMaC]

Er, sadly I'm currently in Japan and the LDs + LD Player are in the US. Zettai was telling me that he has an even worse sample so I may ask him to post it.

[zettai]

@neuron2

Well, I can't vouch for how much worse these are than ErMaC's LD but they are pretty evil.

These are from episode 6 of Gunbuster and have serious rainbow effects. They are made even worse in this episode as the ep is supposed to be black and white. When I did my own fansub of this I used your colorise filter to restore that particular greyness :)

Anyway, here's 3 unfortunately colourful png frames:

http://linda.mine.nu/~ermac/moirebuster.rar

[High Speed Dubb]

@Neuron,

Oops &mdash; &ldquo;P[]&rdquo; means the probability of whatever is in the brackets. Also, I came up with a better way to deal with truncation after looking at a book which talks about truncated means. (Norman L Johnson, Samuel Kotz, N Balakrishnan; Continuous Univariate Distributions volume 1 &mdash; It&rsquo;s a very good book for lots of details on how to calculate stuff for common distributions.)

I&rsquo;m not a probabilist, myself. I&rsquo;m not even a statistician. I just use statistics as a part of working in population biology.

So in English (this is going to be hard, since there&rsquo;s no way to get around talking about quantiles of the normal distribution)...

I&rsquo;m assuming here that Y values (after noise) greater than 0 will be correctly reported by the card, and that Y vaules less than 0 will be reported as 0. Beware that I have a picture which suggests that this isn&rsquo;t right. (It&rsquo;s toward the bottom of the post.)

If Y_new is above ~32, then it&rsquo;s a safe bet that the variation due to noise at that point is the same as at any other moderately bright point. So for each such point, you count 1.

If Y_new or Y_old equal 0, then it isn&rsquo;t certain what Y value they really represent. It&rsquo;s possible that the real input value of Y_old or Y_new value is something like -2. That can be dealt with mathematically, but it&rsquo;s a pain (you have to infer the probability of different possible Y_true_value). So I just excluded those points from consideration.

If Y_new and Y_old are close to but not equal to 0, then there will be some expectation for how much they will differ due to noise, but that expected difference will be less than you would see in brighter areas of the picture. That&rsquo;s because of the last paragraph &mdash; Had either of the pixel values been 0, then we would have tossed this point. Since we&rsquo;re looking only at those points where both pixels exceed 0, we need to correct by the ratio of (expected change at a bright pixel)/(expected change at this pixel, given that we didn&rsquo;t throw it out).

The exact term for what we&rsquo;re looking for &mdash; the expected absolute difference from the mean &mdash; is the &ldquo;mean deviation.&rdquo; Based on a table of the truncated normal relative to the full normal (table 13.10 in Univariate Distributions), the relative value of the mean devation is as follows:


Amount of truncation Relative mean deviation
0.10 0.861
0.20 0.777
0.30 0.712
0.40 0.656
0.50 0.605
0.60 0.556
0.70 0.509
0.80 0.460
0.90 0.400

(I&rsquo;m taking some artistic license with the table &mdash; These are really the fourth column*the fifth column/sqrt(2/pi).)
[P.S.: Edited to fix a factor of two goof.]


So instead of adding 1 to the total number of pixels, you add the number from the second column in the table above.

But what is the &ldquo;amount of truncation?&rdquo; Let&rsquo;s say you looked at the output pixel value again and again. Then the amount of truncation would be the proportion of time that the pixel value equals 0. In other words, what is the expectation that we will be unable to see that pixel value?

Problem is, we can&rsquo;t see that directly. Instead, it can be inferred from a) the values Y_new and Y_old, combined with b) the noise variance. With Y_mean = (Y_new + Y_old)/2, and noise variance sigma_noise^2, you can find the value in a standard normal table in a statistics textbook. (Calculating these probabilities takes numerical integration, so it&rsquo;s faster and easier to use a precalculated table.)

Here&rsquo;s a standard normal table on the web:
http://www.math2.org/math/stat/distributions/z-dist.htm

Here&rsquo;s how to use the table:
- Pay attention only to the &ldquo;.00&rdquo; column.
- The number on the left (&ldquo;z&rdquo; ) is the difference between Y_mean and the Y value below which we&rsquo;ll exclude from the analysis (Y_exclusion_threshold ~= 0.5, since we&rsquo;re approximating a discrete distribution with a continuous one). BUT: This table is assuming that sigma_noise = 1. So to use it for sigma_noise != 1, you fist need to divide (Y_mean - Y_rejection) by sigma_noise before looking it up from the left column.

That leaves one last question: What is sigma_noise? You can avoid that question, though, by taking it as a user parameter. It is possible to estimate it from the data, but that&rsquo;s moderately difficult.

Problems with this approach:
- It tosses more data than necessary, by getting rid of any point where Y_old or Y_new is 0.
- This depends somewhat on the meaning of &ldquo;black.&rdquo; If you&rsquo;re using NTSC-style black Y = 16, then the issue becomes easier to deal with.
- The assumption that input Y values <= 0 are received as 0 is not necessarily true! Take a look at this picture:
http://students.washington.edu/ldubb/computer/ColorBarBrightnessHistogram.jpg

This shows the histogram of Y frequencies in a color bar picture. It&rsquo;s a log scale. That means the parabolas are really normal distributions. They seem to have the same shape throughout the picture, which is where I get my idea that the amount of noise doesn&rsquo;t depend on brightness.

But if you look at the far left, you&rsquo;ll see an important exception. Not only is the far left point very high (which is to be expected), but the Y=1 point is also very high. So it may be that you&rsquo;ll need to drop a point if Y <= 1 (or even Y <= 2), rather than == 0.

[droolian01]

Hi there neuron2 and all.
I've got a few (probably very obvious!) observations to report on msharpen.
Some background - i capture live (non-anime) tv to 384x576 huffuv and used the first b1 version (rgb only) and got a truely excelent result (aim - xvid indistinguishable from live tv) on a buffy capture.

Telecide(blend=false)
crop(4,4,360,568)
Convolution3d (0, 8, 8, 8, 8, 3, 0)
UnFilter(40,40)
ConvertToRGB()
msharpen(threshold=8,strength=150,mask=false)
converttoyuy2()
BicubicResize(512,384,0,0.6)
levels(5,1,255,0,255)

Checked here a couple of days later and to my delight found that you had produced a yuy2 version (damn quick!!). So i updated the .dll to version b3 and amended tha .avs (removed the converttoyuy() etc...) and started on my next buffy encode and noticed that the results were almost 'posterised'. Subsequent tinkering has shown that vrsions b2 and b3 react similarly. To get acceptable results with v. b3 i had to use
msharpen(threshold=8,strength=30)
n.b. -this effect was seen in both rgb and yuy2 modes.

I also noticed that i could use higher 'strength' in rgb mode before seeing any odd effects than in yuy2 mode.

As stated earlier, these observations are probably obvious, and my scripts are probably silly (suggestions welcome!) but that first xvid encode with version b1 really astounded me - super sharp with no noise (but a little slow!) Did something get broken or was it actually mended between versions?
Anyway thanks for all the hard work and giving me more excuses not to do my chores!!!

Scott

[Guest]

@droolian01

I noticed it too but thought it was my imagination. :)

I'll look into this and find out what is happening, and then fix it if possible.

EDIT: Preliminary indications are that the effect is a result of sharpening only the Y channel in YUY2 space. Investigation continues...

EDIT2: No! There's a bug. We need a new version. Thanks for pointing this out.

[Guest]

Here is the fixed version.

Betas 2 and 3 were just totally messed up. Ditch them and get this one.

@droolian01

Is this OK now? Thank you.

EDIT: Since Scott said the bad MSharpen beta caused posterization, could we conclude that it had gone postal? (That's an inside joke for Americans.) :)

[droolian01]

Hello again.
Beta4 seems to behave like b1 and i couldn't see any difference in the vdub preview window between rgb and yuy2 modes - success!

So now i'll go ahead and encode my next buffy capture, using these settings -

Telecide(blend=false)
crop(4,4,360,568)
Convolution3d (0, 6, 6, 8, 8, 3, 0)
UnFilter(40,40)
bicubicResize(512,384,0,0.6)
msharpen(threshold=10,strength=150)
levels(5,1,255,0,255)

From the preview in vdub it looks very sharp and i expect the xvid to be as good as the original live tv view. I'm still pondering the value of using msharpen after the resize, but as i have a backlog of 6 buffy's and 1 6 feet under to encode, i've got plenty of material to be getting on with!

The mask=true could be very useful in fine-tuning noise reduction parameters as i found i could see the difference quite clearly between having c3d on or commented out when threshold=2 to 4.

Thanks again for the briliant work.
Scott

p.s. as i'm english i have no idea what your edit was about! All i can say is that msharpen is now 'delivering' the goods!!!
(groan!!)

[Guest]

@High-Speed Dubb

Thank you for the excellent analysis and clarification. Of course, I'm still trying to understand the application in the non-truncated case, but I'm getting there. :)

What I get from this is an understanding of something I didn't previously understand. I use a windowed relative difference summation. In areas where the noise distribution doesn't hit 0, i.e., no truncation, the noise just cancels out automatically, because a positive noise delta in one pixel cancels a negative one in another. The larger my window, the greater the cancellation but the lower the localization of the difference. So there is a sweet spot at 32x32 I find. So far so good. But in dark areas, the noise distribution gets truncated at 0 as you have pointed out and it no longer cancels automatically.

I want to avoid modeling the noise if possible because it's another tricky parameter for the user to set. But the truncation problem makes the noise start to dominate in dark areas.

[Guest]

@Scott

Phwew. That's a relief. Thank you for the test results and once again for forcing me to see it was not my imagination.

If you want to visualize the difference between the YUY2 and RGB results, process a clip both ways and then use Subtract() to see how they differ. You'll see the very obvious difference about which channels are sharpened (Y only in YUY2).

Interesting idea about the noise visualization. Of course, the edge detection is not designed for that purpose. Your best friend for stuff like that is Subtract()! Subtract the filtered one from the original; the difference shows the filter's effect. You can threshold that if you want a black-and-white map.

Delivering the goods! He he. Good one. I will explain my joke: We have seen here several occasions where postal workers have gone beserk and perpetrated violence. So the phrase "going postal" means to go bonkers.

[vidiot]

Originally posted by neuron2
We have seen here several occasions where postal workers have gone beserk and perpetrated violence. So the phrase "going postal" means to go bonkers.

... and everyone who ever read Charles Bukowski knows why...
:D

Harald

[ErMaC]

neuron: If the filter has trouble in black areas, why not change some variable to be proportional (or inversely proportional) to the luma value? I don't understand any of the math behind it so I couldn't tell you what exactly to do but the thought occurred to me that if dark areas have the problem and bright areas don't, then scale in terms of luma.

Is that anywhere on the ball or is it totally inapplicable?

[Guest]

This stuff really should be in a separate thread, but it's started up here, so...

@ErMac

Sure, of course it's on the ball. But we already solved that issue. :)
Now we're trying to reduce the effects of noise.

We solved it by using relative differencing. Remember this from an earlier post:

D = abs(t-r)/(t+r)

The denominator is effectively a measure of the luminance. So as the luminance gets lower, the effect of the difference becomes larger. Now High Speed Dubb objected by saying that would emphasize the noise, and we were debating that.

Here is what my experiments reveal gives a VERY reliable and robust detector (and I plan to release a beta of the filter soon). If you use High Speed Dubb's idea of throwing away pixels whose luminance is too low, you get rid of most of the noise effect, because only the noise in areas near 0 luminance doesn't automatically cancel (see post above). So I use a windowed sum of relative differences metric combined with pixel tossing near zero luminance. You will be amazed at the robustness of this solution and its lack of any kind of delicate absolute threshold! This is the holy grail I have been seeking.

BTW, I tried two other things besides pixel tossing to reduce the noise effect in dim scenes: pre-blurring and using a bigger window to get better cancellation. Pre-blurring had to be big to have an appreciable effect. That is very expensive computationally and reduces overall effectiveness in all luminance levels. I don't want to make the window bigger because it means small changes can get missed. The above approach is just right. You'll see. :)

[Guest]

One more point. Since pixel tossing changes the count for a window, it has the potential to destroy your global normalization on the range 0.0-1.0. I have a trick for that as well that I will reveal at an opportune moment. :) It allows you to say things like "declare a non-duplicate when any part of the image changes by more than 3%", and the decision will not be affected by different frame sizes, light versus dark clips, or noise. It does so by embodying the way we perceive differences, which of course is relative, not absolute.

[Guest]

OK, the embarrassing bugs seem to be gone, so here is the source code for MSharpen 1.0 beta 4.

http://shelob.mordor.net/dgraft/msharpen/msharpen10b4src.zip

Enjoy and suggestions welcome.

[kyousuke]

the topic about your filter grow up faster ^^

thx for your explanations about the Y channel ^^
i haven't confused Y with the Y dimension spatially but as i'm not a programmer (and only an anime encoder ;), i didn't know and i thought that it was a possiblity to use the X channel. (there're always X/Y in my head ;)

about the new features for avs 2.05, there're really interesting. :)

++

[Belgabor]

@neuron2:
You told me to go on with ideas so here I go:
First I have to say I have absolutely NO idea how your edge detection works (and zero knowledge about the internals of image processing either), so what I blah blah here might be a) nonsense, b) how it already works or c) a bit of both.
While your at inlcuding probability in your calculations, perhaps the following could work out for my earlier proposed mode 2. (Yes, I had probability mathematics at school, and yes, I forgot it the day I finished ;))
[note: I will use the word 'edge' for true edges in contrast to noise]
Lets imagine something like a two (or even multiple) pass mode. In a first pass every pixel gets a certain probability of being a edge by your current algorhythm. In a second (or >) pass each pixel looks at its surrounding pixels and at their probabilty of being a edge. From this points there are two models I imagine:
- simple model. Probability of the pixel being an edge increases if 'more than one but not too much' surrounding pixels are edges. eg if we use a 3x3 square probability rises if 2-3 surrounding pixels are edges, stays same for 1,4 and decreases for 0 and >5.
- more complex model. Simply said, including the position of surrounding edge pixels, aka giving higher edge probability to the pixel when surrounding edges are opposite or nearly opposite than when they are not.
So finally lets ditch the 'mode' parameter and give it a 'passes' parameter ;)

In the hope of not having said total crap
Belgabor

[High Speed Dubb]

@Neuron,

Cool &mdash; glad it made some sense. :)

I don&rsquo;t know what you mean by a windowed relative difference summation. Does that mean you look at the change in a group of pixels between two frames, and add together the (absolute?) differences at each?

Adding a noise parameter isn&rsquo;t necessarily so bad. In 3:2 pulldown, it shouldn&rsquo;t be too hard to infer it. Potentially, it might let you get rid of another parameter (probably some kind of difference threshold to distinguish between noise and motion) which was implicitly playing the same role.

I also like using amount of noise as a parameter since it has an exact definition, so a user could safely enter that same amount in any filters which require it. Of course, there probably aren&rsquo;t any filters out there which use the amount of noise as a parameter, so that isn&rsquo;t really such a great benefit. ;)

One interesting thing about this truncated normal distribution (with results < 0 being replaced by 0) is that there is still one good consistent estimator of the true pixel value. The mean is really biased, but the median should be consistent (tend toward the correct value as you get more data) so long as the true value is >=0. That&rsquo;s good news for noise reduction. Unfortunately medians can be slow to calculate.

About pixel tossing &mdash;
I&rsquo;m glad it&rsquo;s working well! That&rsquo;s the solution I went with, too. It isn&rsquo;t as efficient as using lookup tables for noise near Y=0, but it&rsquo;s much easier and faster. The only place it has trouble is when the picture is almost completely black. In that case I went with the best previous estimate from when the picture was brighter.

I am very curious how you handled normalization. For my own stuff, I avoided the issue by looking for peaks in the histogram of differences. That way I was only looking at the frequency of the differences, and not the totals.

@Belgabor,

Yes, that&rsquo;s a very good idea, and a reasonable way of implementing it, too. Within and between field/frame correlation can give a _lot_ of extra information. Ideally the way to deal with this kind of stuff is with something like a &ldquo;hidden Markov field.&rdquo; Realistically, I&rsquo;ve found that using simple local estimates and &ldquo;blurring&rdquo; them can already get a lot of information. With some tricks, it can even be done reasonably well in a single pass.

[Guest]

@belgabor

As Lindsey says, such ideas have a lot of potential. For this particular filter, however, the accuracy of edge detection is already good enough. It may be very helpful for MSmooth. I will look into it. Thank you for proposing this idea.

@Lindsey

I don’t know what you mean by a windowed relative difference summation. Does that mean you look at the change in a group of pixels between two frames, and add together the (absolute?) differences at each?This should make it clear. srcp is the current frame; src0p is the previous frame. By relative I mean scaled by (t+r). This is YUY2 so black is 16. Keep that in mind when looking at the tossing constants. I toss if either value is too low or if their sum is too low.:

for (y = 0; y < height; y++)
{
for (x = 0; x < row_size; x+=2)
{
int t, r;

dstp[x] = srcp[x];
dstp[x+1] = srcp[x+1];
t = srcp[x];
r = src0p[x];
if (t > 25 && r > 25 && (t + r) > nr)
{
sum[y/BLKSIZE][x/(BLKSIZE*2)] +=
(float)(abs(t - r)) / (t + r);
}
}
srcp += src_pitch;
src0p += src_pitch;
dstp += dst_pitch;
}
highest_sum = -100.0;
for (i = 0; i < height/BLKSIZE; i++)
{
for (j = 0; j < row_size/(BLKSIZE*2); j++)
{
if (sum[i][j] > highest_sum)
{
highest_sum = sum[i][j];
}
}
}
/* Normalize onto 0-100% */
highest_sum = (highest_sum * 100) / (BLKSIZE*BLKSIZE);

Note: this code is for testing an approach. It is not meant to be pretty or fast.
I am very curious how you handled normalization.As you can see from the code, it is really simple. :) I just assume the pixels tossed were really there but contributed nothing; count them. That lets me always divide by the number of pixels in the window. That's why I don't need a counter! Seems to work and it restored the nice global normalization that I could see was ruined by not counting them.

Suggested improvements would be gratefully received.

[High Speed Dubb]

I still think dividing by (t+r) will cause artifacts, since noise isn&rsquo;t proportional to brightness. For example, if a scene has a brighness of Y=30 throughout, and the average absolute difference is 3, then the total noise is
sum_over_pixels(3/(30+30)) = Number_of_pixels*1/20
but if Y = 90 throughtout, then
sum_over_pixels(3/(90+90)) = Number_of_pixels*1/60

(Yeah, a uniform brightness screen is silly &mdash; this is just for example.)

Skipping normalization should also cause artifacts. For an extreme example, imagine a picture in which all of the pixels are below the brightness threshold. Then you would conclude that the picture has no difference at all, since the sum of |differences| would be 0. If you&rsquo;re identifying identical fields for removal, that could be very problematic.

If you naively normalize, there would be a worse problem, since it would be division by 0. But that implies what the real outcome should be. With data like that, the filter doesn&rsquo;t have enough information to conclude anything, and should take the safest action, whatever that is. The easy way would be to check the normalization denominator, and abort if it is too low.

If I understand the code right, then I think the reason why you&rsquo;re mostly able to avoid artifacts is that you look only at the highest sum block in the picture. That&rsquo;s selecting specifically for the block which is somewhat above the Y=25 threshold throughout. So long as there is a block by that description, then problems with normalization and with division by (t+r) should be avoided. Fortunately most scenes should work okay with that, since there&rsquo;s usually something fairly dim on the screen.

By the way &mdash; I like the idea of using the sum (t+r) when checking against a threshold. That should work better than what I&rsquo;ve been doing (checking against r). Mind if I use that in my noise reduction code?

And another aside &mdash; This same problem does come up when Y values are very high, too. That&rsquo;s much rarer, but it can happen in computer graphics, very bright cartoons, and (of course) poorly calibrated video input.

[Guest]

@Lindsey

First, always feel free to use any of my ideas. There's another reason for (t+r) versus just r. The result should be symmetric, that is, the result for comparing frame a to frame b should be the same as comparing b to a. But if your metric is abs(t-r)/r, that won't be guaranteed. :) (Of course, I really use (t+r)/2 to get the average but the factor of 2 is hidden in the normalization line. No need to do that in the inner loop.)

Second, as always, your argument is cogent and interesting.

I never doubted that the noise gets scaled as well. I just find that treating the differences as relative better matches our perception of differences and that the ability to specify a relative threshold is very convenient, and finally that the noise effect can be kept under control by *automatic cancellation* in the best window.

Yes, I agree that the windowing is keeping the potential pixel tossing/normalization errors at bay. That is a good thing. :)

Oh yes, good point about the truncation at the high end. I'll have to think about the implications of that.

[High Speed Dubb]

Cool &mdash; and thank you.

I definitely wouldn&rsquo;t use abs(t-r)/r. Yes, that would be somewhat worse than dividing by (t+r). My use of r was to see if it was too close to 0 or 255, to determine which pixels to ignore. Using (t+r) should let me discard fewer pixels.

My opinion for scaling is that it would be better not to do so at all &mdash; i.e., to use |t-r|, rather than |t-r|/(t+r). Scaling could fit perception somewhat better because Y' is corrected to compensate for monitor gamma before broadcast. But I don&rsquo;t think a measure of perceived difference will be as useful as a hypothesis test of &ldquo;can the change between these two fields plausibly be due just to noise?&rdquo; That&rsquo;s the key question when spotting identical fields for 3:2 pulldown.

It&rsquo;s certainly a good property of windowing that it avoids errors due to variations in local brightness &mdash; but I think you could get even more accurate results by not introducing those errors in the first place.

[Guest]

I don't doubt that an absolute differencing could be preferable when we are trying to do field matching. But for duplicate detection where the user may *want* some slop (to obtain bitrate reduction), having a relative threshold is very desirable. You've never addressed this point.

If you have an absolute threshold, you may have to tweak it based on the luminance of the clip, and that may vary between scenes. But with the relative metric, 3% always means 3%. Most of the time no setting of the threshold will be needed. Do you not see this? Or am I not seeing something you are saying?

To the user, setting a threshold of 3% is a lot more meaningful than setting it to 238750. :)

[High Speed Dubb]

That&rsquo;s fair enough. You could probably do better with a power function, instead (i.e., |t^g - r^g| ), but a ratio may be closer to perception than a simple difference.

But your windowing method is working at cross purposes to this, making the statistic more of a measure of noise than of perceived noise. That&rsquo;s because it should tend to select for blocks with similar brightnesses.

The expected result of an absolute difference [PS: This read threshold rather than difference, which didn&rsquo;t make any sense] would be independent of luminance. That isn&rsquo;t true of a ratio, for which the ratio will be higher when the luminance is low. Drop the windowing and I think this effect will be very clear.

Let me suggest a specific test. Find a still scene in which different parts have very different brightnesses. Check the sum in each window when using |t-r|/(t+r). Then check the sum in each window of |t-r| alone. I think you&rsquo;ll find that |t-r|/(t+r) is much more variable, and depends on the brightness.

The simplest way to name the parameter is probably "amount of noise" &mdash; In other words, how much difference per pixel do you expect from noise?

P.S.: It occurs to me that there&rsquo;s an easy way to observe this, too. There usually appears to be more noise in dim areas than bright areas. So the perceived amount of noise does depend on the brightness.

[vlad59]

@neuron2 & High Speed Dubb

I really like to read this kind of thread. I'm not smart enought to post and give my point of view (In fact I'm not sure I have one ;) ). But I'll follow it till the end.

Please carry on making those thought public and thanks for teaching me a lot.

[Blight]

Looks like Dubb wants a Psycho-Visual (human perception) model to determine noise and apply a value to that.

I think the whole Psycho-Visual field is very subjective on a person-by-person basis.

[Boulder]

Originally posted by Blight

I think the whole Psycho-Visual field is very subjective on a person-by-person basis.

Yes, I remember reading a DivX5 documentation where all the options were explained (this was at DivXNetworks). When it got to psychovisual enhancements, the text simply said "the area is full of possibilities and we have only just started on and will continue to explore". Nothing was explained about the different strength settings:D I guess they didn't know anything about them either..

[High Speed Dubb]

@Blight

No... I&rsquo;ve been suggesting a purely mechanical model for noise, without regard to perception.

[High Speed Dubb]

@Blight

Looking at my previous post, I can see how you&rsquo;d think that. But that post was mostly hypothetical, about how a perceptual measure should be designed.

I&rsquo;m not really convinced that&rsquo;s a good idea. Still, if the question you want to answer is &ldquo;how similar do these fields look&rdquo; then there&rsquo;s no way around dealing with perception. You just have to live with doing things very approximately.

Originally posted by Blight
I think the whole Psycho-Visual field is very subjective...

That&rsquo;s sort of by definition, isn&rsquo;t it? ;)

[Guest]

@Lindsey

One point now and then I'll think long and hard about your points, as well as make the tests you suggest. The existing code in Decimate mode=2 fails quite often because it makes the binary decision for each pixel and then adds those to compare against a threshold count of number of different pixels. This new code adds all the pixel contributions and then makes the decision on the summed result. Thus, the current code does not allow automatic cancellation of noise. The new code succeeds in most cases where the old code doesn't for that reason, regardless of the other niceties. My point is that the new code is still a great improvement, even if we can't yet agree about the value of relative versus absolute differencing. The actual results show this. Soon, something like the new code will find its way into Decimate(). But I'd like to reach closure on our discussion, because some very important issues are involved. Thank you once again for your contributions.

[Guest]

The first release version 1.0 of MSharpen is now available with source code at my web site. It fixes some minor problems in frame border handling and is further optimized for speed, with about a 10-15% speedup.

[Guest]

@Lindsey

OK, I'm coming around to your view. I had thought by doing absolute differencing I couldn't get a good normalization, but in fact I can. The highest value you can get from abs(t-r) is 255, so the summation divided by (the number of pixels in the window * 255) is normalized on 0.0-1.0. Also, I see that the noise effect is reduced with simple abs(t-r). And the more I think about it, the less important I think it is to try to model perception; the user is going to set the threshold by looking at the metrics. She won't care if it doesn't seem to follow a power law. It's not worth amplifying the noise to get it. Finally, it's an extra computational load.

So I have revised the code to get rid of the scaling. The big improvement over the existing Decimate() code comes from letting the summation do some noise canceling, windowing it to catch smaller movements, and from normalizing so that a simple percentage parameter can be used, instead of arbitrary big numbers like 285470.

Unless, you have some further thoughts, we appear to have converged and reached closure on the theoretical issues. Is it so?

[primitive]

I've been testing v1.0b4 of this filter for some time now, it seems to do a really great job in cleaning nasty raw sources. The problem I'm having with the filter right now is that I'm getting artifacting in dark scenes along the edges. I have been testing with lumi-masking enabled with Koepi's latest build. I assume that this blocking will go away if I encode without lumi-masking, but if it doesn't, what should I do to help eliminate the artifacts? Has anyone else seen artifacting in dark scenes when using this filter?

-p

[High Speed Dubb]

@Donald,

Yeah, summing over a function of the differences should be a nice improvement over a per pixel threshold. Without that, it would be very hard to distinguish motion in lightly textured areas.

I&rsquo;m glad you agree about |t-r| working well. I was running out of arguments for it. ;)

There is an argument for using a perceptual measure when removing duplicates, though not for pulldown detection. But even when removing duplicates, I think a gamma corrected difference |t^g - r^g| would be closer to perception than |t - r|/(t+r). Ratios only make sense to me if you want the measure to be unaffected by uniform changes in lighting &mdash; i.e., in a fade-out. (So there is an argument for it in 2:2 field matching.)

There is still a much less important theoretical issue to deal with &mdash; normalization due to dropping pixels with low brightness.

I think you&rsquo;ll find that you no longer appear to need to drop pixels at all. But that is deceptive &mdash; It&rsquo;s because windowing will select for a part of the screen with Y large enough to avoid truncation. If the screen gets so dim that all blocks have some truncation, then the effect will show up again. That is, the difference total will be depressed in very dark scenes.

Since that&rsquo;s somewhat rare, you could probably ignore it without too much problem. But a better solution would be to still drop dim pixels, and make a count of accepted pixels in each block. Then you&rsquo;d look only at the blocks with a reasonable number of pixels which weren&rsquo;t rejected. When determining the final total, you could normalize up to the full pixel total, putting the result on the same scale as for brighter scenes.

For myself, I think the most intuitive way of phrasing the user parameter is allowable change per pixel due to noise. The per pixel part puts the parameter in the range 0-255, and realistically 0-20. Then again, I&rsquo;ve spent too much time staring at histograms of pixel differences, so my intuition on this may not have a whole lot to do with what most people will find understandable.

Also, there&rsquo;s one prickly issue which we haven&rsquo;t talked about in this thread. If the source was processed as a composite signal, then it will probably have some color crosstalk. With NTSC, crosstalk will be positively misleading information, since it alternates each frame. :( (It should also be a problem with PAL, but not as bad.) So computer graphics (or other scenes with a lot of crosstalk) will have somewhat inflated difference scores.

[High Speed Dubb]

Yay &mdash; I just thought of a solution to the crosstalk problem for duplicate field detection.

Don&rsquo;t look at individual pixels. Instead, use vertical pairs of pixels. In other words, If r1 is a pixel, r2 the pixel below it, and following the same naming scheme for t1 and t2, then the difference would be
abs((r1+r2) - (t1+t2))

That would be run on every other scanline in the field.

In other words, it&rsquo;s a spatial comb filter. But unlike a comb filter meant for output, it doesn&rsquo;t matter nearly as much that it will be cancelling where it shouldn&rsquo;t.

Beware that this is meant just for NTSC. For the same trick to work with PAL, you&rsquo;d need to count so:
abs((r1+r3) - (t1+t3))

[dlseibel]

Fascinating stuff. I don't understand most of it, but ... fascinating.

Dale

[primitive]

@neuron2

What the hell changed between v1.0b4 and v1.0final?? I'm seeing radical increases (a factor of 10) in first-pass sizes with the final compared with the beta4.

I still have the b4 on this machine, I'll make a definitive comparison; it could all be coincidence for right now, but last night I was having first pass sizes of <300mb for 25 minutes of particularlly clean source, and now I'm getting first pass sizes of >2gb on the exact same source.

(The source vob files are only 1.5gb.)

-p

*edit*
pass1 size, v1.0final, 2549mb
pass1 size, v1.0b4, 2538mb

I am full of shit. I know I got a 300mb first pass on this material somehow, unless Koepi's statsreader was overflowing and I didn't even realize it. I'll go back and see what I'm doing and try again.

*edit 2*

I think I know what happened. When I was testing before, I was using:


Telecide(guide=1,chroma=true)
Decimate(mode=2)


Then I took a look at the ending credits; they are a combing disasterpiece. (You might use it as test material for decomb, Donald. ) The only thing I could get looking remotely good on it was TomsMoComp; sadly, this meant that I couldn't decimate anymore, as TomsMoComp looks like canned ass when decimated to 23.976fps so I changed the Decimate(mode=2) line to Decimate(mode=1). I think the blended fields torpedoed my compressability when combined with MSharpen. I'll post again with my findings; I'm trying GreedyHMA on this source right now to see how it goes. Right now I'm at 7% of first pass with a total size of 37mb according to debugview, which is much more like it.

-p

(Maybe this should have been another post so people would see it? I think the blended fields + msharpen might be important.)

*edit 3*

I might as well post my script, too; it's the first time I've ever tried anything nonlinear, and I'm just now starting to understand why avisynth is so cool.


SetMemoryMax(40)

input=MPEG2Source("D:\_dvdwf\gk21.d2v")

movie=input.Trim(0,-1) + input.Trim(0,42927)
credits=input.Trim(42928,0)

movie=movie.GreedyHMA(1,0,1,0,1,0,60,90)
movie=movie.Crop(10,0,-10,-2)
movie=movie.Convolution3d(0,4,4,8,8,3,0)
movie=movie.MSharpen(threshold=10,strength=50)

credits=credits.TomsMoComp(0,5,1)
credits=credits.Crop(10,0,-10,-2)
credits=credits.Convolution3d(0,4,4,8,8,3,0)

output=UnalignedSplice(movie,credits)

return output


I did some side-by-side testing and discovered that a Convolution3D right before the MSharpen looks really, really nice; it seems to "tighten up" the image.

[Guest]

@primitive

Nothing changed that would explain your result, and my tests show a slight reduction in file size with 1.0 (due to fixes to frame border handling). I suggest you look elsewhere for the cause of your problem.

There is also no way this filter can be the proximate cause of block artifacts. It does increase the bit rate required, however, so if you apply the filter and leave the bitrate as before, you may see increased blocking. But that is not the fault of the filter; it is the fault of the encoder.

[primitive]

Actually, ignore all that up there. I must have a bugged install of xvid, because I just noticed a pattern in the debugview output, and it's really, really strange. I've kind of seen it happen in the past, but didn't think much about it until now.

I'm taking this to a separate thread because it really has nothing to do with MSharpen anymore.

-p

[KevinHuang]

I got Msharpen.dll 1.0 few days ago, and have tested many times with dvd2svcd 1.09b3. I must say it's a great filter. Cheer for you !
A minor question here : should I put MSharpen before or after BicubicReize, and is there any difference ?

Have a nice day
Best regards:D

[FuPP]

I noticed that I get more aliasing effect puting msharpen after resize. Is it just in my mind ?

[wotef]

i tend to agree with you, msharpen before resize

nice filter and great discussion by the way, completely over my head, but there you go...

[jarthel]

if you were not using msharpen before, what's the FPS? what's the FPS after using msharpen? Using version 1 please :)

jayel

[Dark-Cracker]

hi,

i am actually working on a guide for my tools and i have make screen shot on an anime, i past this msg here because perhaps this will help you for your doc.

i have make a subtract beetween the 2 pictures (the original source and the filtered source) the substcart function show the different pixel beetween the 2 pictures, an a modification on the color show the new pixels appeared .

msharpen light : 20,50,true,false,false
msharpen medium : 15,75,true,false,false
msharpen heavy : 10,120,true,false,false

Msharpen filtered :
http://www.eclipsedvd.firstream.net/autodub/Filter_screenshot/msharpen.jpg

if u want a comparaison with a standard sharp filter u have a screen here :

unfilter (light : 15,15 Medium : 25,25 Heavy : 40,40)
http://www.eclipsedvd.firstream.net/autodub/Filter_screenshot/unfilter.jpg

this filter seems very good for anime but when i will make my screen shot on the movie sample i will post a new msg.

Bye.

[Metalazzo]

thx for this dark
i'll test msharpen medium on some anime encode to see the result :)

[Dali Lama]

Originally posted by Dark-Cracker

msharpen light : 20,50,true,false,false
msharpen medium : 15,75,true,false,false
msharpen heavy : 10,120,true,false,false


Perhaps we could develop some presets like Convolution3D's anime presets.

Also, Donald, do you plan on porting this to YV12? Nothing will be better than Convolution3D and MSharpen YV12.

:)

Dali

[Guest]

Gotta convert Decomb first. :o