Diagonal interpolation correction artifacts with AMaZE Demosaicing

@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.

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.

@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
1 Like

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:
https://filebin.net/wawtef7nn9byebsb

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.

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.

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!

@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…)

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.

2 Likes

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?

Yes, that one should be fine. Thanks!

That would explain why ttrying to run the executable on a pure 64-bit install produces the following odd output?

$ dcraw
bash: /usr/local/bin/dcraw: No such file or directory

Which has to be one of the most uninformative bits of “terminal feedback” that I’ve ever seen :slight_smile: obviously the file is right there!

1 Like

It’d work if you have the 32bit libs installed on your machine. If you don’t have 32bit libs, then that error probably explains it.

Sure. Nevertheless, Elle’s comment on the “terminal feedback” still holds true and “explains it” is a bit far-fetched. :smile:

1 Like

No 32-bit libraries - adding such would probably require reinstalling Gentoo, or at least would require digging far deeper into the system than I care to try.

Luis … can you share the raw file of this screen ?.

If the differences are mostly near white clipping … this could come from different white levels used by Dcraw vs RT (defined in camconst.json) … You can equalize Dcraw vs RT by commenting out the item of the specific model in camconst.json :wink:

@ilias_giarimis, here you go. To be honest, I don’t remember where I obtained the file, I believe it was a repository of raw samples that was available at rawtherapee.com. Or maybe it was from the time of perfectRAW. It’s a nice file for testing moire (the speaker) and interpolation in saturated regions (the stained glass) at the same time. I hope its original author won’t mind.

DSC_7738.NEF (4.8 MB)

The camera of the sample is a D40, which doesn’t appear in camconst.json. I suppose that means RT uses the default dcraw values for that camera model.

The differences between rt RCD and dcraw RCD maybe caused by this

Thanks! Thats exactly the bit of RawTherapee code I was looking for, but I didn’t have a clue where it might be hiding. Can that bit of code be somehow easily disabled? I’m not very good at modifying c++ code.