nice thanks! will give it a read! -jo
On Mon, May 15, 2017 at 6:55 AM, Ingo Liebhardt <ingo.liebha...@ziggo.nl> wrote: > Hi Jo, > > I made a high level description of the algorithm. > You can download it at > https://www.dropbox.com/s/wshrkfhylnikpei/FDC%20high%20level%20desc.pdf?dl=0 > > Together with the code, it shows quite well how the algorithm works. > > I already made some comments on a few performance considerations myself. > I’ll work on these in the coming weeks… > In the end, I’m quite optimistic now that this can be made to run reasonably > quickly. > > Cheers, > Ingo > > > > Am 08.05.2017 um 22:58 schrieb johannes hanika <hana...@gmail.com>: > > heya, > > doesn't sound too bad for something that hasn't been optimised at all > yet. did you describe what you do on a high level somewhere on your > blog? or is the best documentation reading the code? maybe it would be > good to do one pass over the high level algorithm to find out whether > there may be a better/faster way to achieve the same result before > diving into low level code optimisation. > > cheers, > jo > > > On Tue, May 9, 2017 at 8:12 AM, Ingo Liebhardt <ingo.liebha...@ziggo.nl> > wrote: > > Hi Jo, > > OK, here we go, some measurements. > And I must admit that they are not too encouraging. > see below... > > Am 07.05.2017 um 21:57 schrieb Ingo Liebhardt <ingo.liebha...@ziggo.nl>: > > The 30 sec are export time on a full res image. > For darkroom mode, it's slow but usable. It's not that abysmal. :-D > I'll give you the remaining measurements tomorrow. > I do think that there's hope... actually, up to now I was really focusing on > the algorithm itself and on demosaicking quality. Code is still dirty and I > think there's potential. > I'd use FFT for convolutions. As said, some more info to come tomorrow. > Cheers, > Ingo > > > Am 07.05.2017 um 20:48 schrieb johannes hanika <hana...@gmail.com>: > > hi, > > On Mon, May 8, 2017 at 6:33 AM, Ingo Liebhardt <ingo.liebha...@ziggo.nl> > wrote: > Hi & thx :-) > > Well my machine I use for this is super-weak: intel core m3, 4.5W TDP. Very > energy efficient :-( Takes around 30 sec with this machine. > It uses openmp. > > > okay :) that's export time on a full res image or for darkroom mode? > how does it change if you switch on the equalizer module, to give me a > sense how slow your machine is? > > Equalizer module alone on this machine takes 14 secs, increasing the overall > export time to 51 secs, full res image. > > > It has basically 3 building blocks: > 1. Markesteijn 1 pass for obtaining luma and directionality. > 2. Some 11x11 correlation filtering, where the filter has complex numbers as > filter values. > 3. Median filtering of chroma. > > Now, 1 is already pretty optimized. > 3 is already quite OK. > I see quite some potential for 2. Some initial experiments I did show that > using FFTW3 for the filtering could very well be worth it. > > > okay. how much percent is step 2? i mean, how fast would it go if you > set the time to 0 (just skip the code for a test..)? > > Building block 2 still has two parts: first the correlation filters (could > be switched to convolution) and then some trigonometric functions (basically > e^(PI*x), which I guess boils down to trigonometric functions). > Taking out the correlation filters reduces the time from 36 secs to 27 secs. > Nearly 10 secs off, which is not too bad, but not enough unfortunately. > If I take out building block 2 entirely, time reduces to 17 secs, so another > 10 secs off. > > > Are you using FFTW in any part of darktable? > > > nope, we don't use it. so far every time someone wanted to use fourier > space it turned out to be better to do it another way. what exactly > are you using it for? convolutions? filtering in fourier space? could > you use a wavelet domain for this, too? from past experience however, > if you really need fourier, fftw usually rocks. > > I would use the FFT to replace the correlation (or convolution for that > matter) filters. > I’m not sure whether wavelets can be used in this context. > > > As to OpenCL, yes there I see real potential, because the median filtering > works quite well in OpenCL. > > > so there may be hope :) > > I’m refusing to give up hope too quickly, but at the moment the thing looks > a bit overwhelming… > > > cheers, > jo > > > Cheers, > Ingo > > > > > Cheers, > Ingo > > > Am 07.05.2017 um 20:03 schrieb johannes hanika <hana...@gmail.com>: > > heya, > > nice results! especially the high iso one shows quite a bit more > pleasant noise behaviour in the gray center patch. > > how bad is the performance? do you think it could be improved? does it > use SIMD/openmp yet and how promising would an opencl code path be? > > cheers, > jo > > On Mon, May 8, 2017 at 4:53 AM, Ingo Liebhardt <ingo.liebha...@ziggo.nl> > wrote: > Hi all, > > Coming back to this old topic, I have the next iteration of my alternative > approach to X-Trans demosaicking ready. > > For those of you who’d like to try, the GitHub fork is at > https://github.com/ILiebhardt/darktable > > There’s a menu item in the demosaicking module saying ‚Frequency Domain > Chroma‘. > > If you take the original image of bug #10333, you’ll see that the moire > isn’t completely removed, but improved so much that a little bit of > bilateral filter is enough to remove it completely. > > I also did a straightforward treatment of the test images of the X-T1 images > downloaded from dpreview in raw: just base curve + demosaic + export to jpeg > 95%. No further noise processing. > ISO 200 with my approach: > https://www.dropbox.com/s/x74i19mitd33grq/DSCF6827_FDC_ISO200.jpg?dl=0 > ISO 200 with Markesteijn 3 pass: > https://www.dropbox.com/s/0n2f3pw37r8itgq/DSCF6827_MS3pass_ISO200.jpg?dl=0 > ISO 3200 with my approach: > https://www.dropbox.com/s/qpw4rcj0lrzgnb4/DSCF6839_FDC_ISO3200.jpg?dl=0 > ISO 3200 with Markesteijn 3 pass: > https://www.dropbox.com/s/gynk21ttl73cpyr/DSCF6839_MS3pass_ISO3200.jpg?dl=0 > > Many thanks to J. Liles for quite some testing and feedback, and also to > François Guerraz for the hint to use quick select for calculating medians. > > For the geeks, some of my design choices explained in my last blog post: > http://xtransdemosaicking.blogspot.nl > > Quality wise, I am now so far as to consider contributing this to darktable > if it should be wanted, but speed wise, I am not yet happy at all (but I > heave some ideas that I still want to try in this respect..). > > Thanks for informing me what you think. > > Cheers, > Ingo > > > > Am 04.03.2017 um 03:34 schrieb J. Liles <malnour...@gmail.com>: > > > On Fri, Feb 24, 2017 at 10:52 AM, Ingo Liebhardt <ingo.liebha...@ziggo.nl> > wrote: > > > Hi all, > > For those who want to give it a try, I made some further improvements to > the below-mentioned fork with the experimental approach to X-Trans > demosaicking. > In particular to the issue of colour bleeding found by J Liles, this > should be much less now. > There was also still some hue shift, which I think should be gone now. > I finally managed to obtain the filters training them from multiple > reference images of the McMaster (previously IMAX) reference image set. > > As a general remark, this approach doesn’t magically solve all the issues, > some further processing, e.g. bilateral filtering, might still be needed for > difficult image contents. However, especially for images with high frequency > in luma and for high ISO images, the starting point should be a quite bit > better than the other approaches. You’ll see that e.g. oftentimes less > bilateral filtering is needed to make the same image usable. > > For those of you who want to get an impression how subtle changes in the > filters change the image, I included 4 alternative filter sets that can be > used in lieu of the present filtercoeff.h (filtercoeff_11_4.h, broadest, > filtercoeff_var_3.h, narrowest, and filtercoeff_11_3.h, filtercoeff_var_4.h > in between). > > Thankful for further feedback. > > Cheers, > Ingo > > > Ingo, > > I just had a chance to take a look at your latest version. I no longer see > the color bleeding. Low ISO images appear virtually unchanged from > Markesteijn. High ISO images look considerably better. I think you're right > about it being a better starting point. Moire in the redmine example doesn't > appear much affected, though. > > > ___________________________________________________________________________ > darktable developer mailing list to unsubscribe send a mail to > darktable-dev+unsubscr...@lists.darktable.org > > > > ___________________________________________________________________________ > darktable developer mailing list to unsubscribe send a mail to > darktable-dev+unsubscr...@lists.darktable.org > > > ___________________________________________________________________________ > darktable developer mailing list > to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org > > > ___________________________________________________________________________ > darktable developer mailing list > to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org > > > ___________________________________________________________________________ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
