Hello everyone,
I have been analyzing the pipeline architectures and color science concepts behind darktable and ART regarding the relationship between White Balance (WB) and demosaicing. I put together a summary of my thoughts and findings, and I would love to hear your insights or corrections.
The Ideal Color Science Pipeline
From a color science perspective, a proper raw processing pipeline should conceptually look like this:
RAW → Black Point → Linearization → RAW White Balance (Channel Gains) → Demosaicing → Camera RGB → Input Profile (Camera → XYZ or → Working Color Space)
— At this stage, the image stops being camera-specific —
→ Chromatic Adaptation (Bradford, etc.), Exposure (if needed) → Channel Mixer → Local Adjustments → Filmic / Tone Mapping → Output Profile
There are two fundamentally different types of “white balance” here:
- The RAW White Balance: This is part of the sensor characterization.
- The Chromatic Adaptation (e.g., Bradford): Other color transformations that operate on a fully reconstructed, tri-stimulus color image.
One could easily imagine a RAW converter that does not apply any white balance prior to demosaicing. While colorimetrically elegant and more aligned with classic color management, the trade-off is that the demosaicing algorithm would have to work with unbalanced channels. Many established interpolation algorithms deliver inferior results under these conditions because their directional decisions depend heavily on channel ratios. This is why software like darktable or ART introduces sensor-side white balance early in the pipeline.
However, from a software engineering perspective, this practical solution slightly violates the Single Responsibility Principle:
- A module named White Balance should ideally only handle white balance.
- A module named Demosaicing should solely perform interpolation.
In reality, these are two entirely different mathematical operations:
- Case 1: Camera White Balance (“As Shot”)
RAW → R *= 2.1; G *= 1.0; B *= 1.6 → Demosaicing
These are pure channel gains applied directly to the CFA (Color Filter Array) data. - Case 2: Bradford Adaptation
Linear RGB → XYZ → Bradford Matrix → XYZ → RGB
This is a proper chromatic adaptation operating on full color vectors.
Mathematically, these two methods share almost nothing. The RAW white balance is part of sensor calibration, whereas a Bradford adaptation works with a fully formed color image.
- The darktable Architecture (The “Feedback Loop” Problem)
In darktable’s classic architecture, the White Balance module is positioned before the Demosaicing module in the pixel pipe.
- How the code works: The white balance module applies RGB multipliers directly to the incomplete RAW mosaic data. Only after this step does the demosaicing module interpolate the missing color values. Algorithms like AMaZE or RCD use these already white-balanced pixel values to detect edges and compute gradients.
- Why it degrades ICC profile precision: If you modify the multipliers in the White Balance module, the input data for the demosaicing stage shifts. The demosaicing is recomputed, causing minor variations in the fine color and brightness gradients on a pixel level. Because the pixels now have a different mathematical “history” due to the altered demosaicing, the foundation for the subsequent input ICC profile is no longer 100% accurate.
- The Modern Solution (Color Calibration): To bypass this inaccuracy, darktable introduced the modern scene-referred workflow. The classic White Balance module is locked to a fixed Camera Reference (based on D65). This keeps the demosaicing mathematically stable and identical. The actual user-controlled white balance happens much further down the pipeline via the Color Calibration module using a Chromatic Adaptation Transform (CAT) matrix, after the input ICC profile has been applied.
- The ART / RawTherapee Architecture
In ART (and its upstream codebase, RawTherapee), the pipeline is designed differently to eliminate this issue at its root. ART utilizes a Camera Standard Matrix (often extracted from Adobe DNG specifications or dcraw/RawSpeed) to perform demosaicing in a mathematically neutral space.
- Pre-Decoupling: Demosaicing occurs based strictly on native sensor data and a fixed, camera-specific reference.
- White Balance as a Linear Multiplier: Moving the white balance sliders in ART does not retroactively change the demosaicing behavior. The multipliers are applied linearly to the already debayered (interpolated) RGB pixels.
- Stability for ICC Profiles: Since the demosaicing output remains identical regardless of your creative white balance adjustments, the mathematical integrity for the subsequent input ICC profile is perfectly preserved.
Direct Architectural Comparison
| Criterion | darktable (Classic Mode) | darktable (Modern Mode) | ART / RawTherapee |
|---|---|---|---|
| Pipe Order | WB → Demosaic → ICC |
WB (Fix D65) → Demosaic → ICC → CAT |
Demosaic (Fix Matrix) → WB → ICC |
| Demosaic changes with WB shift? | Yes (Causes minor pixel-level color shifts) | No (Locked to D65 reference) | No (Calculated with native camera matrix) |
| ICC Profile Precision | Can become imprecise. | Highly precise. | Highly precise. |
Conclusion & Important Caveat
If you use the old white balance slider in darktable, you inadvertently shift the mathematical foundation of the demosaicing stage, which can degrade the precision of your input ICC profile. ART avoids this architectural pitfall by completely decoupling the demosaicing stage from user-defined white balance multipliers.
However, a crucial nuance exists in darktable’s modern approach: applying complex, non-linear ICC profiles (like LUT-based profiles) before the linear Color Calibration (CAT) module introduces mathematical inconsistencies. Because the Color Calibration module expects purely linear input data, darktable’s manual explicitly recommends avoiding complex profiles when the CAT module is active.
Consequently, while darktable’s modern workflow achieves demosaicing stability, its ICC-before-CAT ordering sacrifices precision when utilizing bespoke or complex custom color profiles—a trade-off that ART’s pipeline architecture does not require.
