darktable's dual white balance confusion

I’m not sure what/where these are, but it sounds like they could help…

this was sort of a hunch I had after discovering the camera doesn’t provide d65 scale info, and that when bypassing the CC the image stays warm.

so if i understand you correctly this is the pipeline:

1. WB via formula provided by camera (which from what I can see would be based on AWB)
2. A: De-mosaic AND B: convert image to D65
3. apply CAT
4. convert back to proper balance

If this is the case, step 2B seems like quite the curve ball… why not keep it where it was at and apply CAT at that point?- but again, I know more about the image capture and more hands on editing stuff. I came here genuinly looking for clearity as to what’s going on, and as i started to dive deeper my curriousty grew and thought I might be able to put in my two cents… but its certainly only worth .02, .03 would be too much :stuck_out_tongue:

Agreed, I didn’t meant to cast any shade onto the current level of sophistication!

Ansel is a fork of DT managed by the dev that worked on the CC module and filmic modules…

He has shut down his website for the moment in protest I believe for some of the political unrest in France … but I’m sure it will be back if you are curious later…

Maybe this will help? ansel-website/content/resources/white-balances/index.md at master · aurelienpierreeng/ansel-website · GitHub

I dunno, I didn’t see anything really related to the D65 thing directly, but it is pretty in-depth about white balancing.

This is a good thread and embedded in his initial explanation is maybe why…also noting the relationship to the input profile…I think also our documents say something about CC actually only working with the standard input profiles and perhaps there is a D65 connection there.

Good link, @priort, specifically:

So, we set the old white balance to “camera neutral (D65)”, which is a flat correction linked to the input profile but independent from our current scene, and we do the white balancing in CAT16 through color calibration instead (just sample the middle-grey patch or set empirically using the visual feedback):

Some code reading might be in order :eyes:

1 Like

Ya after taking a glance at this

https://colorjs.io/docs/adaptation#:~:text=CAT16%20defines%20both%20a%20one-stage%20and%20a,then%20to%20the%20destination%20white%20in%20a

I’m also wondering if AP uses a one step CAT16 but first converts to D65 instead of the 2 step model which goes to illuminant E and then converted in to the new illuminant all in the CAT space before offering it up to the pipeline…

I’m not sure I can follow the code and honestly if I run in to an issue I just compare to wb alone quickly looking for an improvement and if not I tweak the illuminant with the hue chroma sliders… I usually find the hue has been pretty accurately captured to just sliding the chroma up or down to fine tune it by relaxing the correction or adding more works for what I ever need but I as always remember I am but an N=1… :slight_smile:

https://colorjs.io/docs/adaptation#:~:text=CAT16%20defines%20both%20a%20one-stage%20and%20a,then%20to%20the%20destination%20white%20in%20a

I amended my rawproc white balance tool to alternatively work the pre-demosaic channels when I read somewhere that the demosaic algorithm work better with white-balanced data. Didn’t test it to see the difference, but on eyeball comparison it seems to work as well as post-demosaic application. I don’t apply it once, back it out, and re-apply after demosaic, just the once pre-demosaic. This, usually with the camera-supplied ‘as-shot’ multipliers.

I will sometimes add a second white balance tool after demosaic to massage the camera’s foibles. I have to do this as my patch and auto WB modes don’t work pre-demosaic. Gee, I might have to change that…

1 Like

I think Ansel was forked before the latest enhancements to darktable’s colour processing, and uses ‘camera reference’ (fixed multipliers for the D65 illuminant, if I understand correctly) for the white balance module. In darktable, the default is as shot to reference, which (again, if I understand correctly) uses the camera’s multipliers (benefitting demosaic, noise reduction, raw CA correction etc.), and then that gets undone in input color profile (going forward pretending the scene illuminant was D65), and then the process is the same as with Ansel. I haven’t read the source, though.

For my smartphone, Darktable can’t read the white balance coefficients from the DNG file, which messes up the White Balance module (huge color tints). Color Calibration can correct these errors partly, but the colors remain wonky. Only if I reset White Balance to something reasonable (auto picker), can Color Calibration actually do a good job.

Thus it seems that the dual stages are indeed beneficial, at least for the algorithms used in Color Calibration.

so this sounds like what @paperdigits and I were talking about, as well as what @priort pointed out about the one/two stage model.

It just seems like a strange practice to have everthing close to where it needs to be outside of the CAT, only to:

  1. deconstruct it
  2. apply adjustment
  3. reconstruct

Especially if there is clear path for a one stage approach as that paper made it sound like

1 Like