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. Cheers, Ingo > 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 <mailto: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
