Project

General

Profile

Feature #9012

White balance module: temperature sliders do not correspond to anything

Added by Richard Levitte over 6 years ago. Updated about 4 years ago.

Status:
Fixed
Priority:
Medium
Assignee:
-
Category:
Darkroom
Target version:
-
Start date:
10/18/2012
Due date:
% Done:

100%

Affected Version:
git development version
System:
all
bitness:
64-bit
hardware architecture:
amd64/x86

Description

Hello,

In the white balance module, it seems that the temperature sliders are always initialised to 5000K and stay there, even when it takes the white balance from the camera (the exif data).

This strikes me as confusing, since it means that the "temperature" in the white balance module do not correspond to anything else in the image, or in the camera.

My wish is that when the white balance data is taken from the camera, the temperature sliders are set to correspond to the temperature given by the camera.


Related issues

Related to darktable - Bug #9362: The displayed kelvin white balance temperature is very off for D7100 NEFs Fixed 04/12/2013
Duplicated by darktable - Bug #9297: white balance module temperature Duplicate 03/15/2013

History

#1 Updated by Ulrich Pegelow over 6 years ago

  • Tracker changed from Bug to Feature

While I follow your point that the whitebalance sliders should represent the camera white balance if that mode is selected, this is not a bug. I moved it to the "feature" category. I fully support your wish!

#2 Updated by Tobias Ellinghaus over 6 years ago

  • Status changed from New to Triaged
  • % Done changed from 0 to 20

#3 Updated by Pascal de Bruijn over 6 years ago

This is due to white balance being applied in two stages:

sensor data -> camera white balance -> demosaic -> white balance iop (which defaults to in=out, which effectively means camera white balance)

White balance has to be applied before demosaic to avoid artifacts, and it's not a good idea to place the main white balance iop before demosaic because of performance issues.

So to resolve this, the current white balance iop ("temperature") would have to do some magic with the numbers displayed to the user (converting numbers relative to camera white balance to absolute numbers again).

#4 Updated by Johannes Hanika over 6 years ago

src/iop/temperature.c:529: for(int k=0; k<3; k++) mul[k] = p->coeffs[k]/fp->coeffs[k];

i think this line is the root cause of the confusion, the wb coeffs are normalized to these factory presets (fp->) when computing the input temperature (for a fixed output temperature).

not sure why it's there, if i don't forget i'll try to remove it and see what happens when i get home.

#5 Updated by Richard Levitte over 6 years ago

Johannes, that's a detail one might question, sure... but I think the point in this is that as currently implemeted, the actual number on the temperature sliders are meaningless in themselves.

Just as an experiment, I took an image (it really doesn't matter which one) in my collection, and simply changed 'temperature out' to something other than the default (in=5000, out=5000)), say 6200, and then changed the preset to "camera white balance". That set 'temperature in' to 6200, all other values where the same as when I started, as well as the image itself.
So that gets me to wonder, what does 5000K mean? What does 6200K mean? Absolutely nothing, there could as well be a 'temperature factor' that goes from, say, 0.0 to 10.0, no 'termperature in' or 'temperature out', and we would end up with the exact same values (well, except the user wouldn't be able to feed in temperature values).

#6 Updated by Johannes Hanika over 6 years ago

well, these numbers could be absolute temperature values, if you know the temperature of your light in your studio and the intended whitepoint after transformation.

the problem is just that at this point (before demosaic and before color matrix) you don't know which part of the false color comes from the sensor characteristics of your camera and which part comes from the illuminant. so the code as it stands normalizes with the assumption that camera wb would result in a 5000K illuminant, which may be idiotic.

#7 Updated by Roman Lebedev about 4 years ago

  • Status changed from Triaged to In Progress
  • bitness set to 64-bit
  • System set to all
  • Affected Version set to git development version
  • % Done changed from 20 to 50

There has been a lot of changes in this area, especially https://github.com/darktable-org/darktable/pull/859
Right now there is only one kelvin temperature slider, which loosely matches(see #9362) the K values you can enter in-camera.

So i think this is (mostly?) fixed.
Objections?

#8 Updated by Roman Lebedev about 4 years ago

  • Related to Bug #9362: The displayed kelvin white balance temperature is very off for D7100 NEFs added

#9 Updated by Roman Lebedev about 4 years ago

  • Status changed from In Progress to Fixed
  • % Done changed from 50 to 100

Also available in: Atom PDF