At first sight, the implementation seems pretty straightforward, with my code almost untouched. Might it be because of the OpenMP declarations?
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)
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…
you’re totally right, of course
I could say it was late in the night when I added the omp stuff, but truth is, I simply overlooked this…
I just committed a new version without parallelization of step 4. We can always optimize later.
Thanks again @garagecoder for spotting this!
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.
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.
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.
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.
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.
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.
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!