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.
Thanks, I didn’t know about Arvix, will give it a look. I didn’t explain myself properly but my idea was that as it’s not used in any other cameras, be it for photography or scientific instruments, there’s not many motivation to research on it, like Bayer has with all kinds of different algorithms for different scenarios.
I think the available demoasicer for xtrans is quite good. What do you notice are its shortcomings?
Agree with you on there, it’s quite good and I really can’t fault it. The only thing I sometimes notice is a pattern in the noise, but that’s just pixel peeping(bad habit…) and it’ll never show up the final image.
