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 
obviously the file is right there!
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. 
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 
@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.
@Elle, I have updated the repository with the full code I compile. I hope you can build it now in 64-bits.
Thanks, @heckflosse, I’ll have a look.
Yes, thanks! all built and it works.
Not 100% sure, but replacing the true with a false in this line should do that
ri->get_colorsCoeff( ref_pre_mul, scale_mul, c_black, true);
Ingo, isn’t this pre_demosaic autoWB common way of demosaicing of both RT & Dcraw … ?.
This is how l recall from years ago when Anders Torger reinplemented in RT this Dcraw behavior (Emil had changed it to “camera WB” some time before …)
Ilias, you may be right. I don’t know whether Dcraw uses pre_demosaic autoWB as well 
See this RT issue: Using "as_shot" WB in early stages instead of current WB results in artifacts when WB difference is large · Issue #2043 · Beep6581/RawTherapee · GitHub
I had reported a problem with weird speckling artifacts in RawTherapee results, but not in dcraw or darktable or photivo results (photoflow hadn’t yet been released, so it wasn’t included in the comparison), when the raw file white balance was UniWB. This apparently is when “auto white balance” was substituted in the RT code for using the raw file white balance.
Maybe dcraw changed the relevant code since I wrote this article (click the last link in the article to get to the actual annotated code):
https://ninedegreesbelow.com/photography/dcraw-c-code-annotated.html
Or maybe I somehow managed to skip right over the auto white balance step when I dissected the dcraw code to see what the code actually does.
But I never saw any evidence - neither in the code nor in the output from dcraw interpolations - that dcraw incorporates an auto white balance step unless the user specifies to use Auto White Balance. Instead dcraw uses the actual white balance specified by the user .
Hmm, redoing the comparisons, this time also including the dcraw-rcd, those saturated green pixels from the RT-RCD branch are only there when auto chromatic aberration correction is enabled in RT. When auto chromatic aberration is not enabled, I don’t see much difference between the dcraw-rcd output and the RT output. I didn’t try to do any chromatic aberration correction using dcraw-rcd.
Thanks Elle … yes this was the issue I am refering at.
So you say that Dcraw feeds non_pre_Wbalanced data to it’s demosaicers ?. And even so it manages to not have artefacts with UniWB raws ?? … This would be very strange !!.
I am not able to read C code … but from disqussing with demosaic algorithm developers, I understood that all of them need WB info in order to take correct decisions about interpolation direction …
May be I am missreading … but Anders mentions he used the Dcraw method … Using "as_shot" WB in early stages instead of current WB results in artifacts when WB difference is large · Issue #2043 · Beep6581/RawTherapee · GitHub
BTW … this pre_demosaic_autoWB used by RT (and maybe by Dcraw) is very basic … and easily falls in error when a raw channel is clipped … we need more robust statistic methods than pure averaging the non clipped data …
No, at least in the version of dcraw for which I analyzed the code in depth, the white balance multipliers are applied before interpolation, assuming I got the order of execution correct, which I think I did - a fair number of people have used my “outline” of the dcraw code, and none of them have come back to say “by the way, you got this wrong”.
But these white balance multipliers are whatever the user has chosen. See the function “void CLASS scale_colors()”. “Auto” is only used if that’s what the user has chosen.
hi @ilias_giarimis,
I tried to give a look at the latest dcraw code, and it seems to me that @Elle is right. dcraw does use WB info for demosaicing, but it uses whatever the user specifies. I didn’t find any hardcoded “auto ref WB” like in RT. (of course, I might have overlooked this).
fwiw though, I tried hacking RT so that it uses a different WB than the “auto ref WB” one (only for demosaicing), and although this results in different output, I couldn’t see any significant improvement in quality. so I suspect there is also something else in play…
Elle and Alberto … OK … thanks
… so when our raw file is a UniWB one, and the user chooses the “AsShot” option, Dcraw use the unitary multipliers i.e no_W.B … what happens with the artefacts ?.
Well, I don’t know. I’ve been using UniWB even for interpolating raw files for a long time now, not always, but for specific images, for various reasons, and then setting the white balance in my patched version of high bit depth GIMP (“GIMP-CCE”).
I do this by outputting as raw color from dcraw and applying a custom camera profile from disk, which profile is also a well-behaved RGB matrix working space profile, made using this procedure: Make a better custom camera profile
Or else I use PhotoFlow and use my camera input profile as the output profile. Or etc. I’ve never noticed any problems applying the white balance in GIMP-CCE instead of before interpolating the raw file. But you all have made me very curious about artifacts that might or might not result from whatever white balance is set before interpolation.
I have to say that as a confirmed pixel peeper I’ve never noticed any problems using UniWB as the white balance for interpolating raw files. But on the other hand, I’ve never been very happy with the whole process of white balancing raw files, whether before or after interpolation and regardless of the white balance used during interpolation - but to be completely honest here, I’m not even sure what it is about the process that makes me uneasy . . .
So I’m doing some experimenting and will share results when I’m done. This might take a day or two. Hopefully other people might also experiment and share results.