Hi Jo and Dan, In the same dropbox location, I left a new version of the image called chroma cleaned. I think that it is true what Jo said that high frequency colour cannot be captured that well with the x-trans sensor, but I think a reasonable compromise can be found. I’m not giving up that quickly … :-D
Knowing that: - it are the high frequency details that cause problems - the colour artifacts are having unusually high chroma values - most colour artifacts are green and purple I made a chroma cleaning algorithm working as follows: 1. make a variance map of the image, indicating problematic areas (for the branches picture, you find the variance map in the dropbox location, visualizing how this would look like) 2. based on the variance map and a user selectable strength selectively desaturate chrominance wherein 2a. green and purple are treated more strongly, and 2b. higher chroma values are desaturated more strongly than lower ones. 3. based on the variance map and a user selectable strength selectively apply the 11x11 chroma averaging It takes only roughly half a second. Nice thing is that the strength can be made user selectable. I also included in the dropbox location conversions with capture 1 pro, and the raw algorithm inbuilt in Mac OS X. Both are considered good performers with x-trans. Interesting to see that the big guys have the same problems ;-) I also left a version processed with Jo’s ‚x-trans fringes‘ style, which works really very well on this image. Now, the ‚chroma cleaning‘ approach can still be combined with the 5 times median filtering and maybe with the equalizer. Then, I would expect still not 100% perfect, but reasonably well usable images... To Jo’s question below: I used a curve, but a very very basic one, and not very contrasty. Of course I have no full pipeline, so apart from a super basic curve no sharpening no noise reduction... Cheers, Ingo > Am 30.03.2016 um 20:33 schrieb johannes hanika <hana...@gmail.com>: > > hi ingo! > > wow, this direct comparison to out-of-camera jpg is amazing. they do a > really good job at suppressing these colour artifacts without > introducing any smoothing in the luminance channel at all. > > sure, they have some different contrast curve on it (or a curve at > all, do you apply any?). but still, the result is excellent. quite a > challenge to match this! > > your large 11x11 average comes close. sharpness could be improved by a > small amount of unsharp masking, which does wonders when pixel peeping > at this level. i can of course suppress these colour fringes (tried on > a similar shot) using the equalizer module in darktable to subdue > high-frequency colour (see attached style for the dt settings). not > sure this is the most elegant way to do it though. in the end, > however, it describes the issue with the sensor.. high frequency > colour cannot be captured with it. > > cheers, > jo > > > On Tue, Mar 29, 2016 at 7:08 AM, Ingo Liebhardt <ingo.liebha...@ziggo.nl> > wrote: >> Hi Jo and Dan, >> >> I do not want to flood the darktable mailing list too much with x-trans >> related topics, but to answer some of your questions: >> >> 1. Concerning the fine branches: I selected all example images because they >> all of them have contents that are torture tests for demosaicing. It is true >> that a full image processing pipeline will be an advantage because the >> median filtering, and even noise processing, can remove some colour >> artifacts. But not to the degree you see here, unfortunately. Even Bayer >> sensors without AA filter will have problems with such branches, but what >> you see here is also a specificity of the x-trans. Green and red/blue do not >> have the same local weight, if you just make the locality small enough. This >> is the reason why you see consistently green and purple (as in red/blue) >> artifacts in my case. In the same dropbox location given below, I added two >> improvements, one with 3x3 median filtering in the chroma domain (after >> conversion to YCbCr) and one with a 11x11 chroma averaging. You see >> improvements, but especially the latter is a heavy-handed operation. So I >> seek to make the heavy handed approach more elegant (one possibility might >> be to apply it based on the variance of luminance in a certain image area). >> I also included the in-camera conversion, from Fuji themselves so to say. >> You can see that there are very little colour artifacts, but there are quite >> some luminance problems looking a bit like over-sharpening. They are not >> really over-sharpening though, because then the bright overshoot would >> directly follow the dark image part, whereas here we have one pixel-width of >> neutral area in-between. In any case I’m working on improvements in his >> area, but you can imagine that it’s not easy if you look at the in-camera >> conversion, which chose its own compromise. >> >> 2. Concerning the toothpaste: yes, Markesteijn tends to over-sharpen a bit. >> The toothpaste has white letters on consistently red background. There is no >> darker border at the delimitation of the letters. However, this is just a >> small thing, no big deal compared to the colour artifacts in the branches, >> which both algorithms suffer from. >> >> 3. Yes, I’ve read the ChromaSoft blog entries. Unfortunately, my impression >> is that x-trans was given up there at a certain point. Let’s see at what >> point I give up ;-)) >> >> Cheers, >> Ingo >> >> >>> Am 23.03.2016 um 02:55 schrieb Dan Torop <d...@pnym.net>: >>> >>> 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 >>> >> >> ___________________________________________________________________________ >> 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 > > <x-trans fringes.dtstyle> ___________________________________________________________________________ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
