On Tue, Oct 20, 2009 at 12:10:18AM -0500, Udi Fuchs wrote: > First of all, if you are discussing the options here, I assume that > you don't want me to apply the patch that started this patch.
correct, don't apply what I call post-0.16. I'm assuming a 0.16 code freeze. > Still I > have a few comments: > > + threshold *= sqrt(0x10000 / 4096); > > I think this is wrong. You are assuming a 12-bit CCD. It should > probably be rgbMax instead of 4096. correct, > If we do end up scaling all > pixels, we should be able to get rid of some ugly rgbMax code in the > developer. > > + int doDenoise, doInterpolate; > > These don't really belong in the developer_data. They can be in ufraw_data. The current version of the patch doesn't have these anymore. But point taken. > > Lastly, I was having whitespaces/tabs issues. Sending the patch as an > attachment, should take care o that. Probably a MUA problem on your side but anyway, this is a habit I've become used to for linux kernel work: the idea is that it allows to directly comment on individual chunks of the patch by quoting them. To attach instead is fine with me. > > > Option 1: > > Disable the ufraw_denoise_phase and always do denoising on the unshrinked > > raw input as is done now for the interpolation path. This consolidates > > the denoise code path which is very good but at a cost: denoise adjustment > > will respond slower. > > At some point I want to get rid of create_base_image() completely and > do all the rendering in tiles. This would make the speed of the > denoising much less of an issue. Doing more image processing before shrink/interpolate requires extending the ufraw_data->Images[] with more layers I discovered. I'm working on that and from there on it is relatively easy to do more tiled operations. But there's a lot of groundwork involved. [...] > > Contrary to the original dcraw.c/dcraw.cc wavelet denoising, ufraws > > implementation is not pixel value range invariant. As a result the > > same threshold will have different effects, depending on the input > > color depth. > > This looks like a bug that I introduced. We should decide if we want > to fix it. The tricky part would be to support old ID files that will > have threshold with the old meaning. That's a concern for me too. But it should be fixable using the version of the file and the issue can be decided upon afterwards. -- Frank ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ ufraw-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ufraw-devel
