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 <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
