Hi Ingo et al, Exciting to see the continued work. I love the idea of working diagonally on x-trans, rather than replicating Bayer methods. The fringes on thin tree branches (as in example 1) have been a recurring artifact for me in Markesteijn demosaic for me. I've used color smoothing and median filtering on them, but also have had to post-process by hand (e.g. desaturate bright magentas/greens). It doesn't look like either algorithm has that great a time with such fine detail.
The Markesteijn results do look sharper. Not always for the best, e.g. the neutral background in example 4 is notably smoother in Liebhardt version. The results of Markesteijn through the default darktable pipeline look so much nicer than straight dcraw output, I assume the Liebhardt algorithm would be similarly improved. Ingo: Have you read the ChromaSoft blog entries on X-Trans demosaicing? (Starting at http://chromasoft.blogspot.com/2012/05/demosaicing-fuji-x-pro1-and-its-x-trans.html and ongoing.) I found them elucidating about the various options/trade-offs and extant algorithms. Dan On Mon, Mar 21, 2016, at 04:35 PM, johannes hanika wrote: > hi ingo, > > very interesting. do you know why the shadow tone of the font on the > toothpaste looks so different? looks like you're losing some contrast > as compared to markesteijn? or is m. oversharpening? > > sad to see how the thin branches in the trees have these colourful > fringes. i guess that would go away with colour smoothing/median > filtering? > > cheers, > jo > > On Tue, Mar 22, 2016 at 8:40 AM, Ingo Liebhardt <ingo.liebha...@ziggo.nl> > wrote: > > Hi Dan, and of course all potentially interested in x-trans demosaicing, > > > > In the meanwhile, I continued work on my algorithm and it’s now sufficiently > > stable that I can start - > > 1. documenting it, and > > 2. trying to make a branch off of marketable master, following your below > > suggestion. > > > > As you might have seen from yesterday’s mails, I’m trying to start getting > > accustomed to dark table’s code and to where to find what. > > > > If you’re interested, I prepared some sample images using the original > > Markesteijn and my approach (all tif, as they come out of dcraw, so beware > > of the large files): > > https://www.dropbox.com/sh/un1y11uimbqxjjk/AAD3L-Rs9-ztwyBIm4rnCzK-a?dl=0 > > > > A couple of further notes: > > The algorithm itself is clear and succinct, no worries. Please don’t be > > deceived by the code, which doesn’t look succinct… It is plain OpenCL host > > code without any wrapper, and that is awfully verbose. Concerning the > > kernels, some also don’t look succinct, but that’s because I tried to use > > constants rather than the far more succinct calculation rules, already > > bearing performance in mind. > > > > Actually, I managed to reach a better quality in the meanwhile by not only > > interpolating horizontally and vertically, but also diagonally. This is > > something that you can only do with x-trans, so an advantage when compared > > to Bayer. > > Unfortunately it came with a performance penalty (no surprise), but I’m > > confident that there’s room for further performance improvement later on. > > Presently I’m back to around 13 seconds :-( > > I also dropped the iterative approach, as I could not guarantee convergence. > > Some images were even deteriorating with more than one iteration, others > > were barely improving. All in all not satisfactory, so the approach is now > > non-iterative: no loop. > > > > One other comment: I think that even now, darktable’s x-trans support is > > more than just experimental. Even many commercial raw converters have quite > > some difficulties with these x-trans files… > > Some commercial products try to hide these problems by quite a degree of > > softening, but they’re still there. > > You also might want to consider that even Bayer CFAs cause quite some moiré > > and false colour artifacts if they don’t have an AA filter. > > Doing some expectation management here ;-) > > > > > > Cheers, > > Ingo > > > > > > Am 15.02.2016 um 04:47 schrieb Dan Torop <d...@pnym.net>: > > > > Hi Ingo, > > > > Interesting to hear about the speed. That sounds promising. Here my > > not-that-spectacular laptop is running darktable's Markesteijn > > 1-pass/3-pass demosaic in approx. 1.4sec./3.8sec. respectively on the > > CPU for 16 MP images. But there's no reason to worry about optimization > > this early on. The code only got that fast after it was heavily worked > > over by Ingo Weyrich from the RawTherapee project. Ulrich Pegelow's > > recent OpenCL implementation of Markesteijn is now making a significant > > difference for those with the hardware. > > > > It strikes me that there are very few people out there with the > > mathematical knowledge and focus to craft a new demosaicing algorithm > > for a novel sensor. Well worth pursuing if you're one who can do this. > > The ideal algorithm would be succinct and clear, of course, but is that > > possible? > > > > If you're interested in darktable users testing it, one approach would > > be to make a branch off of darktable master and add your work as an > > alternative demosaic algorithm? This would give people in the dt > > community an easy route to test it. Though it could also build > > expectations for what is already only "experimental" x-trans support in > > dt. > > > > As you write, despite the debatable virtues of x-trans, the cameras are > > fine enough that it has become worth the work to deal with the sensors. > > But so much knowledge and effort has gone into demosaicing Bayer sensors > > that is hard to imagine that comparably fast and good algorithms for > > x-trans anytime soon. > > > > It is striking to read the original patent application for the Bayer > > sensor (https://www.google.com/patents/US3971065) and see how it was > > envisioned to allow usable results from my very simple processing. > > X-Trans seems much more a fly-by-wire version of a sensor, requiring all > > sorts of intervention to produce decent output... > > > > Dan > > > > > > > > On Sun, Feb 14, 2016, at 01:04 PM, Ingo Liebhardt wrote: > > > > Hi Dan, > > > > To come back briefly on the profiling. > > > > After two passes there are indeed no further visible improvements in image > > quality. > > > > With two passes and some more minor tweaking I’m now at 7.6 seconds with my > > not too spectacular laptop hardware. > > > > I also tried DCI for red and blue reconstruction once the green is there, > > but it didn’t look good at all. More false colour artifacts. > > > > Cheers, > > Ingo > > > > > > Am 08.02.2016 um 23:52 schrieb Dan Torop <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 > > > > > > ___________________________________________________________________________ > > 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
