On Mon, Mar 21, 2016 at 11:06 PM, Ingo Liebhardt <ingo.liebha...@ziggo.nl> wrote: > Hi Roman, > > A while ago, I asked if there’s maybe interest in a demosaic alternative for > the Fuji x-trans sensor, next to the present alternatives VNG and > Markesteijn. > > In the dropbox link below, you can find some sample images (always a variant > with 3-pass Markesteijn and with an approach I was trying out), if you want > to have e look (demosaic algorithm identified by file name). > Especially the high-contrast edges of the buildings might be interesting to > look at. > > In any case, my approach is also still very experimental, and I don’t know > if there’s interest as such? > > If you’ve more questions, just let me know. Nono, all that i did read and understood.
I was specifically referring to the word "marketable". > > Cheers, > Ingo Roman. > Am 21.03.2016 um 20:45 schrieb Roman Lebedev <lebedev...@gmail.com>: > > On Mon, Mar 21, 2016 at 10:40 PM, 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 > > What is that thing people keep talking about? > > 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 > > Roman. > > > > 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
