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 ;-). 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. 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. 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 (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. The noise array is based on math (exponential curve) but has likely been tweaked at index 0 because of the visual perception. 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. -- Frank ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ ufraw-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ufraw-devel
