Hey, no problem for me. It's just that on this picture, a lot of artefacts appear, so I thought I would mention it… the moiré, the green on the zipper… I don't know how Fuji does it, but the SOOC jpeg has no such problem.
Thanks anyway for trying to improve things :) On 14/02/2016 19:21, Ingo Liebhardt wrote: > Hi Marc, > > I directly tried, but, sorry to say, also my approach shows moiré in the > blue shirt. > I can’t say how it would react to colour smoothening, because my > algorithm is still raw command line only. > > Cheers, > Ingo > > >> Am 13.02.2016 um 13:41 schrieb Marc Cousin <cousinm...@gmail.com >> <mailto:cousinm...@gmail.com>>: >> >> Hi, >> >> There is an issue (http://redmine.darktable.org/issues/10333) with >> some RAWs which exhibit problems. I don't know if your demosaicing >> helps on this, but I thought it would be worth mentionning. >> >> Regards >> >> Marc >> >> >> >> On 09/02/2016 20:40, Ingo Liebhardt wrote: >>> Hi Dan, >>> >>> My present algorithm (3 pass) takes about 11 to 12 secs on my >>> machine (Intel on-processor graphics, so nothing fancy). >>> Markstein (3 pass) via dcraw takes about 35 secs on my machine. Both >>> for a 16 megapixel x-trans raw. >>> >>> However, I use openCL not only for speed reasons, but also because I >>> like the modularity that the kernels give me. I’m presently still >>> pretty much in the experimental phase, and I like that I can change >>> order and parameters of the kernels and then see how that impacts the >>> quality of the output. >>> >>> So far, my emphasis is not yet on speed, and I’m quite optimistic >>> that I can squeeze out some more speed once all the design decisions >>> are taken. >>> >>> Most importantly: >>> 1. Presently, I use guided filtering / upsampling not only for >>> constructing the green pane, but also afterwards for red and blue. >>> For red and blue, DCI would be another option once green is there. >>> This could not only improve speed, but also improve quality. >>> I’m presently working on some experiments in this direction. >>> >>> 2. My approach is iterative, starting from a provisional green. >>> Presently my provisional green is created in quite a sophisticated >>> manner. I think I might overdo this a bit - I could likely simplify >>> this part without sacrificing quality, but I don’t expect the savings >>> to be revolutionary. >>> >>> 3. As said, my approach is iterative. The above time is with three >>> passes. If I reduce to two passes, about 2 to 3 seconds can be shaved >>> off. My first impression is that after two passes further visual >>> improvements become marginal, but I want to check this a bit more >>> before prematurely concluding. >>> >>> So the 11 to 12 secs are already a bit of a worst case scenario. >>> >>> Now as to documentation: don’t be too optimistic ;-) , so far I >>> only documented a rough outline of my idea. >>> >>> Concerning a CPU variant: once all design decisions are taken, this >>> shouldn’t be that much of an effort. >>> But even before that, I’d clean up my GPU variant. As said, presently >>> it’s still quite experimental. >>> >>> Cheers, >>> Ingo >>> >>> >>>> Am 08.02.2016 um 23:52 schrieb Dan Torop >>>> <<mailto:d...@pnym.net>d...@pnym.net>: >>>> >>>> Hi Ingo, >>>> >>>> This is quite interesting work to see... A x-trans demosaic algorithm >>>> which is well described, high quality, open source, and fast is >>>> something which I'm sure many people are awaiting. Though of course >>>> having all of these qualities is a lot to ask! It's great to see >>>> continued work on this, and in particular addressing the color >>>> artifacts. >>>> >>>> How does the speed of your code when hooked into dcraw compare to 1-pass >>>> or 3-pass Markesteijn via dcraw? The dt version of Markesteijn is about >>>> 2-3x faster than dcraw's, if I recall right, but dcraw's Markesteijn >>>> could still be a good basis of comparison. >>>> >>>> How much work would it be to make a CPU variant? So far as I know, all >>>> of darktable is built to function on CPUs with the possibility of GPU >>>> speed-up in certain cases. >>>> >>>> I can't speak for the dt core developers regarding their interest & >>>> priorities, of course... >>>> >>>> Best, >>>> Dan >>>> >>>> >>>> >>>> On Mon, Feb 8, 2016, at 03:42 PM, Ingo Liebhardt wrote: >>>>> Hi all, >>>>> >>>>> Congrats to version 2.0.1. >>>>> >>>>> Would you maybe be interested in an alternative approach to the >>>>> Markesteijn x-trans demosaicing? >>>>> >>>>> I see that for Bayer patterns you have a fast one, plus two >>>>> different high-quality ones (AMaZE and VNG4). >>>>> >>>>> The only high-quality one for x-trans seems to be Markesteijn. >>>>> I personally find that Markesteijn is producing very sharp results, >>>>> but also quite some false colour artifacts. >>>>> I’ve been playing around with an alternative approach, and I’m >>>>> slowly starting to get reasonable results. (even images with lots >>>>> of green - always problematic - start looking okay(ish)). >>>>> >>>>> If you want to have a look: >>>>> https://github.com/ILiebhardt/xtrans >>>>> >>>>> And some sample comparisons to Markesteijn, plus a brief >>>>> explanation of the idea: >>>>> https://www.storehouse.co/stories/b8sj2 >>>>> >>>>> Don’t be mistaken by my version number: there’s still a lot of work >>>>> to be done, and I also still have quite some ideas for improvements… >>>>> >>>>> So at this stage I just want to carefully pre-inquire if there >>>>> could be some interest, in principle. >>>>> >>>>> Thanks a lot for letting me know. >>>>> >>>>> Cheers, >>>>> Ingo >>>>> >>>>> >>>>> >>>>> ___________________________________________________________________________ >>>> darktable developer mailing list >>>> to unsubscribe send a mail to >>>> darktable-dev+unsubscr...@lists.darktable.org >>>> <mailto: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 >> <mailto:darktable-dev+unsubscr...@lists.darktable.org> > ___________________________________________________________________________ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
