Feature request - Use temperature and tint in white balance Style data rather than the RGB coefficients

[RawConvert]

The white balance data held in a Style includes the three coefficients. These values depend on the camera model and possibly other factors, so you might save values that are appropriate for say daylight, but if you apply the style to a raw from a different camera, it will not be daylight. The difference from daylight depends on the two particular camera models involved.

If instead the Style stored the temperature and tint in force when saving/making the style, it would be quite close to the desired colour temp when applied to a different camera. The user benefits of this change would be a) less confusion - "why are my white balance values nothing like what I expected form my style" and b) it would honour the intention of a style, which is to give a certain look to an image (e.g. see flash session use case below).

In my opinion styles and history have different functions. The history shows what happened to a particular photo, so it would seem correct to continue having the multipliers in the database and XMP files. Whereas a style represents an intent, what you want to happen to future photos, and temp+tint is more appropriate here.

A further possible mod would be to also allow standard camera settings like daylight. cloudy, flash etc. to be used in a style.

My original post follows but this was when I did not appreciate the coeffs were stored in a style and so thought there was a bug.

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Master 3.3.0+584~g5424fa2e3-dirty and previous versions. Ubuntu 18.04

In summary, applying my style works for most modules in the style (haven't checked exhaustively) EXCEPT for White Balance where my settings are not applied; or possibly the style is getting updated somehow.

To reproduce (though not sure this always happens) -

1. Import single image, open in darktable, set white bal to 5170K and 1.01 tint.
2. Create style ensuring WB module is included (Side issue - why does this panel open up with just a few modules ticked, what about the rest?)
3. In darktable, change the WB to say flourescent and back to lighttable.
4. Double click the style to apply it.
5. Go to darktable and with any luck see the WB is not 5170 / 1.01.

This issue replaces #6132

Note that dt 3.2.1 made a WB change - "Add a user-defined mode in the white-balance module to keep the last modification of the module. It is then possible to go back to the last modified setting after selecting another mode (spot for example)."

Here is a style that exhibits the problem (though it's not necessarily at 5170/1.01. Change from .txt to .dtstyle to use. Style12.txt xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

[parafin]

Please check RGB coefficients, not temperature/tint. only RGB factots matter (saved in the style), while temp/tint are recalculated and will differ e.g. for different cameras.

[johnny-bit]

Exactly what @parafin said :)

White Balance style saving works perfectly fine for me, however you got to understand it's limitations: Temp/tint are nothing but visual sugar on top of back-calculated values of rgb coefficients. That means that the only thing that matters is rgb coeffs and this is what's saved inside preset. Additionally coeffs are calculated based on camera matrix so one set of coeffs does not and will not match another camera unless they have identical sensor. Even then, temp/tint are calculated back from coeffs, so if you are on recent master (so there's safety cushion so that temp/tint don't seem too correlated) then actual temp/tint is "slightly different", say depending on temp +/- ~10-50K and tere's quite a big "margin of error" for tint ;) Also depending on temp, certain values of temp differences are "indistinguishable" form each other for a given range.

All in all - if you create a style with temp 5170 and tint 1.01 and see its coeffs, then i guaratee that if you apply that style to image done with same exact camera, then coeffs will be identical and temp/tint will be "close enough".

if you want to create style for use with different cameras - exclude white balance from it.

[parafin]

Yep, and if your question is if it's possible to create a style, that saves temp/tint instead of RGB coefficients, the answer is no, and it's probably not what you want anyway, since it won't work reliably. So please re-check if there is an actual bug here and close the issue if there's not.

[RawConvert]

@parafin , please chill! Why would using temp/tint not work reliably?

[junkyardsparkle]

Why would using temp/tint not work reliably?

Because temp/tint are only GUI elements, not actual parameters. Using white balance in a general purpose style doesn't really make sense, since its setting depends on more than just scene lighting... any two cameras might have different spectral responses, and different lenses can vary to a surprising degree (and not only old ones).

If what you want to do is something like, for example, to apply a particular white balance offset from any given cameras "daylight" setting, for warming or whatever, you might want to investigate using the channel mixer module (with the caveat that it can cause clipping if used after a strong exposure boost). I've created presets in that module for the color casts of various ND filters I own, for instance... if I have pictures of the same scene taken with/without the ND filter, I can apply the same WB to the images, and additionally apply the channel mixer preset to the appropriate images. Sorry if that's not relevant to whatever you're trying to do.

[RawConvert]

Interesting. In fact I'm not trying to do anything smart with the style, it started because I use uni WB and setting "daylight" in my general style is much more useful as a start point than seeing green. Then I noticed it gave different values from one raw to the next. I accept this issue is not massively important!

This is my understanding - The colour temp of a light source like daylight is the temperature a black body would need to be in order to radiate the "same" light. So colour temp is not dependent on any camera. If you dial in a temp of say 5000, then you are telling the software that the light illuminating your photo had a temp of 5000K. If you took the same shot with a bunch of cameras and then dialled in the same colour temp in the WB module, and probably adjusted the tint separately for each camera, then I hope you'd get pretty much the same pic for them all. I appreciate sensors vary but surely that is the job of the maths and input profile to normalise the colour etc. Lenses are another thing I accept.

So I reckon there are at least 3 ways dt WB could work in Styles -

1. Store temp and tint This would seem to be logical to me. It ought to give a fairly consistent result across cameras, at least re. the temp.

2. Store the "standard" choice chosen by the user. By that I mean things like "cloudy", "flash" etc. This also seems pretty logical. If you were processing a bunch of pics taken with flash across more than one camera, applying "flash" to them all should give a decent starting point.

3. Store the WB multipliers As these are dependent on camera, this seems not a great choice.

I will be away for a few days in case I'm slow replying to anything.

[parafin]

The problem is that both 1 and 2 won't give you the same results across cameras because sensors are different, so people will end up complaining that it doesn't work as they expect. Also saving the WB multipliers is the only future-proof way to store WB, which guarantees that history stack will be intact after darktable upgrade. So options 1 and 2 aren't implemented currently and it's not obvious how to do it correctly and if it's a good idea at all (not supporting this use-case explicitly might be more honest).

[jenshannoschwalm]

I am not sure whether it's really worth to work further on this module as there is something new in @aurelienpierre pipeline.

But - two remarks.

Atm styles and history only keep the wb multipliers parameters in the blob, this for sure leads to completely wrong wb calculations on a different camera. Shouldn't we include some sort of sensor id (probably the camera name in the blob) to make sure the data is correct when applying and if not give an error message? At least this would protect users from mis-usage.

For 2 it could be implemented via sort of symbolic id in the blob. If set it would mean, has this camera implemented something like cloudy and if so use it? This could be done - but is it worth it? Plus it probably would lead to issues "why does camera xyz does not have this or that ...

[johnny-bit]

I've looked at possible solutions and some things could be implemented, but it's mostly beating around:

1. a marker defining selected style: as shot/camera reference. As shot for cases where you "mistakenly" include wb in style it defaults to "as shot", camera reference to make it easier for things in pipeline to use something that we assume to be d65 or close enough.
2. a temp/tint combo can be saved, but that needs to go through camera matrix and calculation to be "close enough".
3. a rgb coeffs (what we have now).

I don't think having sensor id in blob is good idea (or even doable) because if the sensor id is "wrong" what can we do about it in IOP? It's user's responsibility :) params look shite? not iop's fault :D Another impossible thing is "cloudy" & company + finetuning. While sensor id is teeeechnically do-able (still don't know how anyting would/could be communicated to user), the "cloudy" preset (+ finetuning :D) is imo way out there in terms of usability. Temp/tint combo would be better in that case.

Well, there could be a sensor_id-based rgb coeffs in case sensor id's didn't match: calculate temp/tint from coeffs basing on matrix from original sensor_id and then back-calculate coeffs for current sensor_id.

While I already pondered (and plan to) implement point 1 and maaybe 2 (leaving 3 intact) I ain't doing no sensor_id stuff ;)

[junkyardsparkle]

it started because I use uni WB and setting "daylight" in my general style is much more useful as a start point than seeing green

...and you can certainly do that. It just needs to be understood that what this setting consists of is the (so-called) "RGB" multipliers (which actually operate on the uncorrected camera primaries, which have a somewhat arbitrary relationship to what becomes RGB after the input color profile is applied). The values used for (also somewhat arbitrary) "daylight" presets will probably be different from camera to camera (in fact, it gets worse: my Olympus cameras use information about mounted lenses to determine the values mapped to these nominal presets) All of which to say, don't get hung up on those named presets, or the "guessed" value shown on the temperature slider. As long as the multipliers are being applied, the style is working properly as currently implemented... so if you want to keep this issue open as a feature request, you might want to edit the title. :-)

That said, using camera-specific auto-applied presets in the WB module is probably a better solution for this.

[jenshannoschwalm]

I don't think having sensor id in blob is good idea (or even doable) because if the sensor id is "wrong" what can we do about it in IOP? It's user's responsibility :) params look shite? not iop's fault :D

Right :-) It would mean nothing more than "Sorry - you really didn't want to do this!" And the wb setting would be ignored.

[junkyardsparkle]

This could be done - but is it worth it? Plus it probably would lead to issues "why does camera xyz does not have this or that ...

Personally, I think this would just create more confusion about what the WB module actually is/does, and which parts of it are really just for convenience (and maybe even questionable for that).

[RawConvert]

I should be packing but will chip in with a further thought... I am guessing that styles and history are considered intimately connected because of a common data structure. But they have different functions. The history shows what happened to a particular photo, so continue having the multipliers in the database and XMP. Whereas a style represents an intent, what you want to happen to future photos. So have the temp & tint in a style, not multipliers, and do whatever is needed when you apply the temp/tint style to a history stack. Then hopefully? no one can complain it's not doing what they expected, because it's doing exactly the same as if they had entered the temp/tint into the module themselves.

This is interesting to discuss, but to repeat, I don't see it as a big problem and I can easily imagine there are other enhancements and fixes that are more worthwhile.

[johnny-bit]

I will still insist that temp/tint, presets etc are just a visual sugar (and presets too) on top of coefficients. There are (interesting) people who even do white balance via coeffs alone and coeffs are the only important thing here :)

history and style are one and the same, both are record of operations to do on image. and history is not a done deal - it's a non-named style that will be applied to your RAW at the time of export :) (sorta ;) ) so data for style and data for history MUST be universal.

I'll echo what @junkyardsparkle said - the current behaviour is not a bug, it's intended functionality. If you think it's worth a FR, then please edit this issue title and edit up opening post to reflect what you'd like to see.

[junkyardsparkle]

I will still insist that temp/tint, presets etc are just a visual sugar (and presets too) on top of coefficients. There are (interesting) people who even do white balance via coeffs alone and coeffs are the only important thing here :)

Exactly. My preference would be for any future tweaks to the module serving to somehow make this more obvious to the user, since ultimately this is the only real solution to confusion. I won't seriously suggest putting the "real" controls above the other ones... but I do kind of like the idea. ;-)

This is partly why I have slightly mixed feelings about making this module more fun looking with color-changing widgets, etc... it would probably serve users best if its appearance suggested "this isn't the place to do creative things with color, it's just some calibration to compensate for the various physical realities at capture time, and make gray things gray". It's something I wish I had understood better when I first started messing with RAW files... I baked some pretty bad JPEGs early on...

[RawConvert]

coeffs are the only important thing here

@johnny-bit , I insist on disagreeing! White balancing is fundamentally about the colour temperature of light. The colour temp is how you measure it. The coeffs are just factors used to adjust the pixels so that you get the correct colours. If you want other colours then other/better modules are available; or you can tweak temp/tint/RGB coeffs.

[johnny-bit]

Yes and no. The actual proper way to go at it would be to only use camera reference D65-based coeffs for all cameras and then later in pipe use channel mixer to mix temperature into play having "white balance" module be simply "coeff normalization" module :P

[junkyardsparkle]

The coeffs are just factors used to adjust the pixels so that you get the correct colours.

As far as RAW data from digital cameras is concerned, that's exactly what white balancing literally is. Your camera isn't a calibrated measuring instrument, and its properties are just as significant as the so-called "temperature" of the light source, and the temperature model is very limited as to what it can describe about any of that... hence the need to also have a "tint" slider. Many real world light sources don't resemble a black body radiating through a vacuum, and modern artificial light sources in particular can have a spectrum that's all over the place. Now add in the fact that the white balancing happens in a space defined by arbitrary camera sensor primaries, and the idea of even being able to make highly accurate relative adjustments to "temperature" becomes questionable (but still useful enough as a slider control).

All white balancing can really do is make objects that are considered to be "white" in the real world appear white in the image by juggling the weighting of those unknown camera primaries. A module later on, in a real color space, could probably be made to apply accurate relative shifts according to the temperature model, but it still couldn't tell you anything objectively accurate about the light source itself, because, again, your camera/lens/etc isn't a calibrated measuring device. This is why the temp slider is just a convenient widget for making a certain kind of adjustment to the coefficients. Maybe it would be less confusing if it didn't try to display a Kelvin value at all. ;-)

[parafin]

coeffs are the only important thing here

@johnny-bit , I insist on disagreeing! White balancing is fundamentally about the colour temperature of light. The colour temp is how you measure it. The coeffs are just factors used to adjust the pixels so that you get the correct colours. If you want other colours then other/better modules are available; or you can tweak temp/tint/RGB coeffs.

If the point is to make light source appear as neutral gray, then coeffs is exactly what you want. Most auto white balancing algorithms just average red, green and blue channels and then come up with multipliers that will make them match. Note how temperature concept doesn't appear here at all. I'm not even sure how it can be useful in this context. What is the use-case here anyhow? Besides trying to adapt wb between different cameras (have you noticed BTW how we have a lot of wb presets for each camera model, instead of re-computing them from wb/tint of one camera?).

[RawConvert]

Another example of where a Style might store the intent rather than the result of a change is the Perspective Correction module. If you set it to correct converging verticals, save in a style, then apply to a different image, you're not going to get parallel verticals. I guess it's storing the geometry adjustments in the style, rather than storing an instruction to activate the automatic fit converging verticals icon. If it did the latter then presumably you could use it on any image and it would correct the verticals.

[junkyardsparkle]

I guess it's storing the geometry adjustments in the style, rather than storing an instruction to activate the automatic fit converging verticals icon.

Yes, exactly... this is what is stored in a style/preset: the actual module parameters. This can create confusion in modules which include significant GUI elements which are not, themselves, directly coupled to a parameter, but rather provide an indirect means of adjusting the actual parameters. Besides the tint/temp sliders, another example known to have caused some confusion is the "mix" control in the "color zones" module - it moves the spline nodes vertically as a group, changing those parameters, but is not itself coupled to a parameter, and if you come back to the module later, it will have zeroed itself... there was talk of changing it, but it hasn't happened yet.

There are a very few cases where a module has a special, selectable mode which allows you to make a more abstract "intention" the saved parameter for copy/paste/preset/etc... the one that comes easiest to mind is the "auto" mode on the exposre module, in which the parameter is the target scene brightness, rather than an explicit amount of EV shift. The old (non-RGB) version of the "levels" module has something similar. I suppose a mode could be added to WB which takes as a parameter a "target" temp setting, and tries to find (or interpolate) it based on the information in the camera presets for the current image... but I doubt this would turn out to be very useful in practice, personally. Maybe I'm wrong, though. :-)

[jenshannoschwalm]

I think this is all about what styles can do in a meaningfull matter. Many modules are simply not meant to be used in this way. Modules specific to hardware (like color temp or raw black point) can be used within presets easily but in styles?

[parafin]

I think this is all about what styles can do in a meaningfull matter. Many modules are simply not meant to be used in this way. Modules specific to hardware (like color temp or raw black point) can be used within presets easily but in styles?

Yep, I agree with that. WB is not a type of module that should be included in the style that can be used across different camera models.

On the other hand there are indeed some other more universal processing modules that could benefit from "auto" setting applied from a style instead of specific computed settings. This is a long-standing feature request that was implemented in limited fashion in some modules. Still no universal approach on that.

[github-actions[bot]]

This issue did not get any activity in the past 30 days and will be closed in 365 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.

[aurelienpierre]

Made possible with color calibration

[RawConvert]

Yes, thanks, I can see a test style is re-applying the inputs including the temperature and illuminant.