call for support: Darktable 3.6 changes colors of RAW files significantly

Hi Kofa

thx for this excellent hint - i was not aware of the fact, that Capture NX and Studio NX is already processing before I even have started to process

Wow - Looks much better

1 Like

Well, it’s called a raw file for a reason :wink:
Read Eek! My Raw Photo Looks Different than the Camera JPEG

You bought an expensive camera to get exactly this: access to the raw data to bring out something the in camera jpg processor doesnt give.


If you check out the Play Raw category here, you’ll see in how many different ways a photo can be developed – often completely altering the mood.

I also enjoy @s7habo’s ‘Editing moments with darktable’ series, for example here is the latest instalment:

1 Like

I think the true question here is: what makes you believe NX Studio holds some kind of ground truth ?

Because it does not. Every software has its own interpretation of the non-image that is a raw photograph.


Don’t be the grumpy old wizard :slight_smile: @Chris2205 simply didn’t know what a raw file was, but that misunderstanding has been cleared above. Everyone has to get started somewhere.


Maybe a question on the side.

Maybe this is the default rendering of darktable (since yes, no raw converters are the same. Some try to get close to what the camera does, some do not bother :))…

… but maybe something is wrong in the settings here. Giving your raw makes sure we can compare to how it looks out of the box on our end.

As a hint, in a modern workflow, if white balance module is set to “camera reference” than the ‘color calibration’ module must be enabled (and in one of the Illuminant settings is a "as camera shot’.

This should be the default but maybe something went wrong there.
If color calibration is disabled, white balance must be set to something ‘real’ :).

I’m guessing here, but the way the white balance looks of, reminds me when white balance is set to camera reference without enabling color calibration :).

sigh again I only see a small discussion and start a reply and then 25 other replies appear. Kofa already gave an answer and came to the same - or a better - conclusion :s.

With respect for the expertise here, I found your “Eek!..” article helpful but I actually like most of my camera’s JPEG profiles and do save a RAW+JPEG or Fine+RAW (as the setting is called in my camera). If I desire a particular JPEG version and save in just RAW, then the camera is not going to embed the JPEG version I want. Is it? And if it’s not, then have I wasted space saving what I want? Perhaps it’s time to re-read my manual.

1 Like

If I’m using RAW=+JPEG, my Nikon cameras will make the embedded JPEGs and the +JPEG with the same Picture Controls. Same render.

Now, check your image sizes, as I’m not sure embedded preview JPEGs are the same image resolution, (width, height) as the saved JPEG file. That might make a difference in your decision.


$ dcraw -e filename.CR2

or in Windows with dcraw.exe in the same folder as your raw file:

dcraw.exe -e filename.CR2

Starting point with default settings
ART (let it use AM film curve)

DT color preservation

DT no color preservation

1 Like

Your idea regarding color calibration helped a lot - thx for that.
Is in dt a possibility to set “as camera shot” as default. The default setting seems do by “daylight”

If you use the modern wb in preferences then it reads your exif data and extracts WB info. I think at least for me initially you are on as shot. It will show daylight as the illuminant (in many cases or if non daylight it will show custom) but if you change to as shot it wont change the WB …

1 Like

Like priort says, if your workflow is set to ‘modern’ color, new pictures should get the white balance module enabled and set to ‘camera reference’, and have the color calibration module enabled to a ‘set as shot’ setting, giving you a as-shot starting point.

Pleas note that a module can be ‘reset’, and can be reset to ‘auto defaults’. So if you mess around and reset the color calibration, there is a chance that ‘reset’ will not get you back to the starting point, but ‘reset auto defaults’ will. Also, you can use the history list to go back.

Somewhere in the settings is an option for ‘display referred’ or ‘scene referred’. Underneath that is an option for ‘modern color workflow’ or something similar.

I recommend using it, but remember to leave the old white balance module set to ‘camera reference’ and then use the color calibration module for white balance duties.

So ik guessing you used an old xmp file / setting / style for a picture, or you accidentally reset the color calibration completely to defaults, removing the ‘as shot’ default mode.

Note that as shot in camera and daylight can represent the same values:
Set to as shot in camera:

After resetting the module (sets D daylight):

It’s still a D (daylight) illuminant with 4020 K.
Switching to custom after the reset (which set daylight):

Switching to custom after setting as shot in camera:

Interestingly, there’s a tiny change in the histogram between as shot in camera and reset to daylight:

Overlaid in the Gimp with difference blending (and then stretching the histogram):

Or zoomed in:

I found the same but in the image I tested it was noted when going from the initial setting of daylight as determined when the module was activated to as shot. Then after that toggling back and forth between them there was no change triggered…

Note that not all settings can be expressed perfectly by all illuminants. So often you start on one, if you then switch illuminants, DT tries to convert your current value to a value that can be expressed by the new illuminant. This works ‘close enough’ but it’s never 100% perfect (what is…).

So when you have value A in ‘custom’ illuminant , and you convert it to daylight illuminant. It turns into value B, there is a change, a rounding error. Because A was a value that doesn’t exist in daylight. B does.
If you now select the custom illuminant again, it converts value B into custom. But custom can represent all values, so there is no rounding error or loss here. This gets value C.

If you now switch back to daylight illuminant again, the conversion can be done perfectly, because that value exists. So you get a perfect B back. So if you now keep on switching between those two illuminants, there is no loss or rounding error, so you also get no slight change in the histogram.

This is all not something to be worried about or even remember when you’re making changes to pictures.
But setting white balance means setting a hue (over simplified) and the color calibration module goes to work with your selected hue in the space/model/illuminant that is selected.

As aurelien described in his introduction to this module, using ‘temperature’ and ‘tint’ is a real restricting way of picking a hue, and not all colors can be selected (his words were stronger :P).
So when you flip between modes and illuminants, it’s constantly taking the hue that is selected, and converting it - the best it can - to the new illuminant and mode. There can be very slight differences in the results.

According to the manual (

Switching from any illuminant to custom preserves your settings entirely

With the raw file posted in this topic, switching from a reset module (daylight) to custom does introduce a small change (darktable 3.6.0 on Windows, and also yesterday’s master on Linux).

I found this sample image really interesting because it looked so much better with no color preservation. So I run off to the user manual to read up on these options for preserve chrominance and this is part of what was written there “if you choose “no” in the preserve chrominance parameter. This value may yield seemingly “better” results than the other values, but it may negatively impact later parts of the pipeline, for example, when it comes to global saturation.”

There are just so many ways to approach image editing in DT and that is what I love about it.