Re: [UFRaw-Devel] Wavelet denoiser.

[Jos De L. <Jos...@te...>]

Frank van Maarseveen schreef:
> On Sat, Nov 28, 2009 at 01:41:04PM +0100, Jos De Laender wrote:
>   
>> Dear all,
>>
>> I'm reviewing - yes I want to understand - the wavelet denoising used in 
>> dcraw, reworked in ufraw, ported to gimp in some variant.
>> All seem to have the same basis going back to dcraw.
>>
>> Forgive me if it is a stupid question, but is there actually someone 
>> around that understands in detail the algorithm that is used and/or has 
>> some reference to it ?
>>     
>
> There are no stupid questions, only stupid answers. A couple of remarks
> (I'll try not to be stupid -- no guarantees ;-).
>   
Thanks Frank.
> There's no way this can be explained thoroughly on a single sheet of paper
> or its electronic equivalent -- there is just too much underneath. 
Well, I'm a bit familiar with signal processing, but at the time I got 
my engineering degree wavelets were not yet 'mainstream'.
So my - leaking away - background is Fourier analysis.
I did try and read some wavelet stuff and was desperately trying to 
match it with the code.
Got close, but not to a level I understand fully.
What would it be nice that - non trivial algorithms - in open-source 
software are documented the one or the other way ..

> For
> what I know the basis is twofold: pure math and the human visual
> perception. The math has probably been translated into the numerical
> domain and has been optimized for that. So you can't easily see why it
> became what it is by just looking at the code.
>   
Close though ... I'm pretty sure it is an 'a trous algorithm'.
Despite the 'hat_transform' name, I think it is a linear interpolation 
filter, but here's where I start feeling unsure...
> The human perception comes into play because the algorithm should
> do something which ultimately pleases the eye (or more precise: the
> human brain). For example, the implementation contains a sqrt() which
> I think is an approximation of a gamma compensation 
My understanding is that the sqrt is introduced to denoise shadows and 
highlights +/- equally.
The sqrt is for instance not part of the derived gimp plugin. It's not 
essential.
> (which again is
> an approximation) done to "linearize" the effect for the eye. So the
> algorithm is appplied after converting the samples to the appropriate
> domain. See http://www.poynton.com/notes/colour_and_gamma/ for some
> more basics.
>
>   
>> I understand it is an a trous algorithm with some linear interpolation 
>> scaling filter, but I don't grasp the latest detail of implementation 
>> (and sometimes I doubt if the signs are fully correct in the 
>> hat_transform function). Also the noise thresholding seems black magick 
>> (I mean the noise array , where is it coming from ?).
>>     
>
> I've had a look at the hat transform function: two out of three loops are
> there for handling pixels close to the edge of the image. The function
> looks ok to me from a logical/programmer point of view. 
No offence, but how can you say without knowing the underlying algorithm ?
> The noise array
> is based on math (exponential curve) but has likely been tweaked at
> index 0 because of the visual perception.
>   
The gimp plugin uses something along the lines :
double THold = 5.0 / (1<<6) * exp (-2.6*sqrt(Level+1))*0.8002/exp(-2.6);
It looks to give the same results, but doesn't make anything clearer for me.

> This is what I can tell. Please correct me if I'm wrong anywhere here.
>
>
> BTW, my plan is to use this algorithm for luma/chroma denoising in ufraw
> (after develop() but before any conversion to 8 bit). The colorspace
> conversion has been implemented (it took some time figuring out correct
> matrix constants having the right precision). The algorithm itself is not
> the challenge (it's there) but everything else is, actually.
>   
Yes, in my hobbyproject I'm also trying and using wavelet denoising on L 
and a/b of Lab.
That was the very first reason to try and understand it.


Many thanks for  your response.

Jos