Diagonal interpolation correction artifacts with AMaZE Demosaicing


(Elle Stone) #143

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!


(Mica) #144

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.


(Flössie) #145

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


(Elle Stone) #146

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.


(Ilias Giarimis) #147

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:


(Luis Sanz Rodríguez) #148

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


(Ingo Weyrich) #149

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


(Elle Stone) #150

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.


(Luis Sanz Rodríguez) #151

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


(Elle Stone) #152

Yes, thanks! all built and it works.


(Ingo Weyrich) #153

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);

(Ilias Giarimis) #155

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


(Ingo Weyrich) #156

Ilias, you may be right. I don’t know whether Dcraw uses pre_demosaic autoWB as well :frowning:


(Elle Stone) #157

See this RT issue: https://github.com/Beep6581/RawTherapee/issues/2043

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 .


(Elle Stone) #158

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.


(Ilias Giarimis) #159

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 … https://github.com/Beep6581/RawTherapee/issues/2043#issuecomment-130014520

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 …


(Elle Stone) #160

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.


(Alberto) #161

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…


(Ilias Giarimis) #162

Elle and Alberto … OK … thanks :slight_smile:
… 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 ?.


(Elle Stone) #163

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: https://ninedegreesbelow.com/photography/well-behaved-camera-profile.html

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.