And, of course, I know I may select each algorithm and see how the result looks. I also understand that the default (RCD) is useful in almost every scenario.
The problem is my poorly-trained eyes cannot see difference between different algorithms.
I understand the problem they resolve, and I believe I understand what are the weakness and strengths of each one, thanks to the docs. But the results look all equal to me.
Do you have a criteria to select a demosacing algorithm? I never touch the demosaic module.
Do you have an example where is clearly visible that one option is better than other?
Most of the algorithms work in most cases (that’s helpful, I know), so not seeing differences isn’t that strange (they all aim to do basically the same thing…) Some images do show artifacts, mostly as mosaic-like areas or color moiré.
Usually, I leave it on the standard (fast), unless I see artifacts, then I try AMAZE or LMMSE. I haven’t yet seen the need for the (slow) double demosaicing (but again, that will depend on the kind of images you take).
Also, if you want to see the differences, you will have to zoom in to 100 or 200% in most cases. With a 50MP raw file on a normal, 2MP screen, it’s hard to see the artifacts…
Be mindful that sometimes the algorithm result may affect other modules such as perspective correction. I find the outcome of the latter is drastically different depending on the method.
Most of the time it’s hard to see a difference. But my criteria is:
If not much fine detail, vng4
If lots of fine detail, rcd
If a mix (eg. Branches and Sky), dual rcd+vng4
If artifacts (moire, mazing), amaze (but Compare them all)
If high noise, lmmse (but Compare it to the one you would otherwise use).
Comparisons need to be done at 100%. If the difference can’t be seen there it’s not worth sweating about.
If your predominant destination for pictures is the web, I don’t think it matters what algorithm you choose. The resize to the dimensions of display in most web pages obliterates any benefit (or even detriment) of a particular demosaic algorithm. Downsize-resize is sometimes referred to as “poor man’s denoise”…
I batch process all my raws to 800x600 ‘proof’ JPEGs, and the demosaic algorithm I use is what’s called ‘half’; it simply combines the four pixels of the mosaic quad into one pixel, reducing the image size by half in the process. The demosiac performance is horrid at 100%, but not discernable after the final proof resize. For family snapshots, the proof rendition is all I usually need, even to print 4"x5". If I subsequently work an image for more serious reasons, I’ll re-open the raw with the proof processing as a starting point, then change things like demosaic to a better algorithm.
Demosaic performance is about retention of resolution, particularly in slanted lines and edges. Like @Soupy says, looking at anything less than 100% doesn’t tell you anything useful about demosaic performance.
It would be amazing if darktable was really scene-aware and chose their demosaic algorithm based on the scene AND changed the algorithm as the development proceeds to account for things like fine detail, increased noise, and perspective correction.
It could also be very annoying as the optimal choice also depends on the export conditions. And on what I think is important in a given image… I prefer picking settings I think best, even when that implies I have to know some of the gritty details about my tools. It’s time spent once in learning, and saves time every occasion where I have to fight the automatic choices. As always, YMMV.
Systems designed for the predilections of privileged users with time and intelligence to consider every gritty option create lots of confusion for the rest of us lesser mortals.
Amazing indeed. Here’s roughly how it’d have to go:
This is @jay_brightday's first post; let's welcome him to the forum!
Hi, I’m an AI engineer and my lifelong goal is to save humanity from the realities of the physical world. I made a crap-ton of money writing software for self-driving cars, but I grew weary of killing people in beta testing. So, I thought I’d come over to FOSS imaging software and see how I could help out…
Okay, a bit flip, but the point is that FOSS software is mostly the efforts of folk who have a certain axe to grind and have the singular resources to pitch in, because the pay is horrible. My point is that your nirvana won’t get any traction until a person with the right chops and motivation gets involved in the particular project in which you are interested.
@Thanatomanic all of us ignorant mortals aspire to be intelligent gods who can “see” the difference.
One of the wonderful things about Darktable is that we have so many choices. Most commercial packages don’t event tell you which demosaic algorithm they use or let you choose which one you want to use, probably because it would complicate and confuse their UI. I have been confused by the choices for a while but just thought “who else cares” and now I see the OP cares so I chimed in with an idea. If the dev gods like it great. If not, I will continue to live in demosaic confusion.
I mean, I didn’t even tried to fix moire patterns here. I just wanted to see apreciable differences.
I’m concluding that I’ll never touch the defaults of demosaic module haha. I never upload photos with full resolution, and rarely I care about picture quality at 100% crop.
Otherwise i personally have a few simple rules (btw i ported two of the demosaicers to dt, rcd with a lot of help by @heckflosse and LMMSE using rt code as a base but faster due to internal tiling)
For Moire patterns, AMaZE and LMMSE are often better (unfortunately both are CPU only yet)
VNG4 and PPG are inferior to the rest, VNG4 often flattens details and sometimes introduces a color cast and PPG tends to overshoot at edges or high-contrasty regions)
Use RCD in most cases (as it’s much faster than AMaZE at equal quality), for very high ISO images (depending on the noise floor of your camera) use LMMSE
On the topic of demosaicing, is there any change there’ll be new ones investigated for the x-trans filter? I personally don’t see the point, but someone might’ve read or seen some rumours around. Not complaining or being under appreciative as I am very grateful that there’s markesteijn and a few others that work very well, and after all, it’s the users choice to get into a system with such a proprietary mosaic.
The research is often done by people in academia, who then publish a paper. That paper is picked up by some FOSS Dev and implemented. Maybe searching Arvix or another academic database will yield something.
I think the available demoasicer for xtrans is quite good. What do you notice are its shortcomings?
I wrote about it somewhere. Let me see: Perspective correction - #2 by afre. However, there isn’t that much information there. I am sure this happened to me another time and I wrote about that too. No one followed up with my GitHub issue.
Anyway, little differences can affect how algorithms respond.
