Diagonal interpolation correction artifacts with AMaZE Demosaicing

(Luis Sanz Rodríguez) #121

At first sight, the implementation seems pretty straightforward, with my code almost untouched. Might it be because of the OpenMP declarations?

(Alberto) #122

Hi @LuisSanz, thanks for checking!

Yes, I tried to keep it as close to the original as possible, intentionally. I think in general it is important to have the “pristine” version working first, before doing any optimization. I only added some openmp pragmas to parallelize stuff…

I just recompiled with openmp disabled in rcd, and I don’t see any difference… but I’m not an expert in this, so here are the two results for you to examine (I used the neutral profile)

(Samuel Chia) #123

Thanks @agriggio, I see tiny differences, which is easier to see in an exaggerated difference map of the two images overlayed - it looks like the differences caused by JPEG compression or maybe something else. Not the kind that would cause the zipper artifact bug. They also appear in the smooth areas of sky mostly rather than in the more textured parts.


A long time since I’ve done any programming but some of the later loops appear to read/write from/to the same array (which might be a problem in parallel, I really don’t know). Maybe it’s just precision differences…

(Alberto) #125

you’re totally right, of course :flushed:
I could say it was late in the night when I added the omp stuff, but truth is, I simply overlooked this… :wink:
I just committed a new version without parallelization of step 4. We can always optimize later.
Thanks again @garagecoder for spotting this!

(Luis Sanz Rodríguez) #126

That’s true. However step 4 has no influence on the green output, which is also slightly different. I believe the problem might be with V_stat and H_stat showing negative values or not being stable enough. I will try to compile myself RawTherapee to be able to do some tests and be sure.

(Alberto) #127

well I don’t know the code enough (well… not at all in fact) to determine if the parallelization is really problematic or not, but I turned it off just to stay on the safe side.

(Luis Sanz Rodríguez) #128

I was unable to find the cause for the green channel differences between my implementation in dcraw and the one in RawTherapee. I ported the algorithm myself and the results were identical to those I posted before using @agriggio’s branch.

Is there any change in the pipeline the raw data goes through before the demosaicing between dcraw and RT with the neutral profile applied?

In the meanwhile, @samuelchia, I can send you a compiled dcraw. Which OS do you use?


@LuisSanz I don’t have the programming chops nor the critical eye but I would like to try the patched dcraw as well. I am currently using win7 but have a Linux Mint vm handy.

(Elle Stone) #130

Hi @LuisSanz ,

I’m not sure what you mean by the green channel differences, but I just compiled the RCD branch and then interpolated _MG_4393.CR2.

At the very pixel-peeping 800% zoom, after applying sharpening, I’m seeing some relatively saturated green pixels along the edge of the mountain, in one of those 45-degree slant areas (the only area I’ve pixel-peeped at).

I looked at your github code, and I’m comfortable compiling dcraw from source if that is required. But I couldn’t figure out how to interpret the the “README.md” in terms of getting from the github code to something that works with dcraw.

I’m on Gentoo Linux and would very much like to take a look at the dcraw output, if you have a version compiled for Linux, or could give instructions on how to proceed with the github code.

(Luis Sanz Rodríguez) #131

@afre, @Elle, I have uploaded some binaries to the repository:

You can call the demosaicing with -q 4:

dcraw -v -T -6 -H 0 -W -o 1 -w -q 4 file.raw


You can use the moiré reduction method to replace the red and blue channel interpolation in other algorithms. The downside is softness in the red and blue channels and some artefacts if the green channel direction is different to the red/blue channel direction with the moiré reduction. Those artefacts will probably be reduced with false colour suppression.


New compiled test version ( 95d303f ) for Windows (x64. Gtk3.22.26) can be downloaded from here:

No installer included. Extract the folder “RawTherapee_rcd-demosaic” to e.g. your Desktop and run “rawtherapee.exe” inside this folder.
Cache and settings are saved into “%localappdata%\RawTherapee-rcd-demosaic”. It leaves your existing installation untouched.


@LuisSanz suggested doing

dcraw -v -T -6 -H 0 -W -o 1 -w -q 4 file.raw

I typically use other settings including -H 2. However, it doesn’t appear to be working ATM. Comparison among -H 0 (clip), -H 1 (unclip) and -H 2 (blend) highlight modes using DSC04028.ARW from [PlayRaw] High ISO Challenge. Hint: zoom, then download.

(Luis Sanz Rodríguez) #137

I usually develop with -H 0 -W -o 0 or with -H2 -W -o 0 when I’m working on an algorithm. I find the output the easiest to compare.

@afre, I’m sorry. Yesterday I forgot to remove a testing code before compiling and it seemed to be causing the false colors with any other option rather than -H 0. I have reuploaded the binaries.

(Luis Sanz Rodríguez) #138

If any of you would like to perform a comparison involving RCD, please, use the binaries from my repository rather than the version from RT. The output is not the same. I still have to figure out why in RT there are more artifacts. Thanks!

(Alberto) #139

@LuisSanz I just noticed that your dcraw exectuable is a 32-bit one. By default, gcc uses the 387 FPU for floating-point computations in 32-bit mode, whereas in 64-bit mode it will use sse instructions. This might explain some differences. To be sure, you could try recompiling dcraw on a 64-bit machine, or use the flags -march=pentium4 -msse -msse2 -mfpmath=sse and see if that makes a difference. (Just guessing at this point, but worth checking out IMHO…)

(Luis Sanz Rodríguez) #140

Thanks for the suggestion. Yes, it could be a precision issue.

I’m compiling the dcraw binary under an old 32-bit netbook running Lubuntu. I’ll build a 64-bit executable and try it in my desktop system later. Anyway, the Windows version is 64-bit and the output still differs.

The good thing about this is that I was able to compile RT, which I have never tried before, so I can now play a bit and integrate other functions apart from demosaicing.

(Samuel Chia) #141

Thanks @LuisSanz! I have both OSes here but I prefer to use Windows. I see that you uploaded a dcraw.exe file in your Github repository. Is that the one I should use?

(Luis Sanz Rodríguez) #142

Yes, that one should be fine. Thanks!