y4mdenoise artifact...any ideas?

The latest y4mdenoise is producing incredible results for me, but there's one nasty artifact that I'm having trouble fixing.  I'm hoping someone might have an idea what to do about it.

The problem happens in fuzzy, dark areas -- they'll start jumping around like mad.  I see it in the backgrounds of cel animation, I see it in the dim corners of the stage in rock concerts, and I see it in scenes obscured by fog.  I've even seen it in the face of a craggy old sailor.

y4mdenoise ranks matches by size, with the idea that the biggest match is the correct one.  I'm guessing that, due to noise, some worse matches are actually managing to be slightly bigger.  So possibly I need a new metric for ranking the desirability of found matches.

One thing that fixes the problem completely is to raise the match-size-throttle until it's bigger than the image, effectively turning it off.  Then the problem goes away.  But of course, it grinds the program to a near-halt.

One idea I had was to penalize matches based on the size of the motion vector.  The idea that a full-motion match (i.e. one with a motion vector that was as big as the search radius) would be penalized versus a zero-motion match.  Something like deducting 10% off of its size for having a full-motion vector, and a sliding scale in between.  But this didn't seem to do anything in practice.

Another idea was to gamma-correct the image on input, to increase the effective resolution of darker areas, and to reverse that correction on output.  But I'm still reading the big book on digital video, and don't totally understand the consequences of this idea.  One thing that seems clear, is that 8-bit-per-component input is probably too coarse to respond well to such gamma correction, and I'd probably have to wait until we could get all the tools to pipe 16-bit-per-component raw video to each other before trying this.  Or I'd have to allow floating-point values on the command line for noise tolerances.

One really whacked idea was to allow denoising parameters to vary for different ranges of frame numbers.  This would require a GUI tool that could show the interim results of denoising, so that problem areas could be found and fixed by hand.  But this seems like a cop-out, not to mention a seriously large amount of work.

So does anyone have any good ideas?

Steven Boswell

------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge

_______________________________________________
Mjpeg-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mjpeg-developer