In-Depth Demosaicing Algorithm Analysis

At the completion of a project that uses LibRaw, I want to share the more intense algorithm artifact analysis to be helpful for anyone hoping to use LibRaw in the future, and as a thank-you to Alex for the direct support.

To summarize, algorithm (user_qual) 11, DHT, is the best. It's better than the best offered by RawTherapee, too.
Here are the most important examinations I performed!

Fence / Roof comparison:
https://drive.google.com/file/d/0ByFHxc7qU-svVXd6MVEzN0pUajQ/view?usp=sh...

Light comparison:
https://drive.google.com/file/d/0ByFHxc7qU-svQlAwMlZubFJvelk/view?usp=sh...

Cone comparison:
https://drive.google.com/file/d/0ByFHxc7qU-svR2NETGNocWRwUkk/view?usp=sh...

Track line comparison:
https://drive.google.com/file/d/0ByFHxc7qU-svb1ROZXlmWGdTbUE/view?usp=sh...

Black / white checker comparison (animated GIF!):
https://drive.google.com/file/d/0ByFHxc7qU-svUHBPZjUycUxhOGM/view?usp=sh...

Summary table with performance times (on a decently large 16bit image):
https://drive.google.com/file/d/0ByFHxc7qU-svRkVhWGdYTnlOdE0/view?usp=sh...

You can see why DHT is the best choice for image quality, and one of the better choices for speed, but of course nowhere near as fast as bilinear or PPG.

Hope this is helpful!

Forums: 

Thank you for sharing your

Thank you for sharing your analysis results.

Could you please note:
- was OpenMP used, or not?
- if yes, what is computer CPU/core count?

-- Alex Tutubalin

Nope

I do not know what OpenMP is. My project didn't use it :)

Thank you for the info.

Thank you for the info.

OpenMP is a easy way to use multiple cores/cpus from program. It requires compiler and runtime support, also program code needs to be modified (#pragma omp ...)

DHT demosaic code already uses these pragmas, so if compiled witf -fopenmp (this is command line key for gcc compiler) it may run much faster on multicore/multicpu.

-- Alex Tutubalin

DHT Issues in near-nodata regions

Falka, As the guy who sat in the office next to yours, i figured i'd come on and say thank you for your help this summer!

On a more technical note, taking a closer look at the imagery generated utilizing DHT, we found some artifacts in near-nodata (CFA ~= 0) regions of an image (or if you just hack off the bottom end prior to passing it into DHT). I believe these are just integer wrap-arounds.

lexa, we'll be sure to look into compiling with OpenMP!

sorry, could not understand

sorry, could not understand what is 'CFA ~=' (CFA is color filter array, it is constant over the image). Is it really 'data values ~= 0' ?

-- Alex Tutubalin

Dark dark dark

Hi Alex,
We're preforming some noise suppression prior to passing the raw buffer into the demosaicing chain, so yes, we have raw pixel values in the neighborhood of 0.