Hi Jo, If I find some time next weekend, I’ll try to make a high level description of the algorithm. The blog only represents a very-high level description. It basically just sketches out the ideas and cites some references that I used as starting points. But that alone won’t be enough I think, so I’ll see if I can do more.
This should also help me. Because sometimes, when you’re into the details you stop seeing the obvious. For example, the e^(PI*x) I mentioned below has complex numbers as x. It is basically a modulator / demodulator representing the spatial structure of the CFA. It is periodic, 6x6, following the structure of the CFA. So there’s really no need at all to calculate it each time. It can simply be pre-calculated and then implemented by using a simple 6x6 lookup table. This measure alone could already improve performance considerably... Bon, anyway, I’ll try to provide you with a high level description as soon as I find a bit of time. 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
