colorcalibration also for manual wb

RELEASE_NOTES.md

@@ -758,6 +758,21 @@ changes (where available).
   instead of the copies bundled in the app. Without Homebrew, the
   modules were not found at all.
 
+- Fixed stale color temperature and illuminant color in color calibration
+  after white balance changes when using "as shot in camera".
+
+- Fixed input color profile and highlight reconstruction (opposed and
+  segmentation modes) still applying part of the white balance
+  correction when the white balance module, set to "as shot to
+  reference", was switched off on a raw image. Edits made that way
+  render with different colors.
+
+- Fixed a color cast when white balance in "as shot to reference" mode
+  was pasted from another image, or applied through a style or preset:
+  white balance applied the pasted multipliers, but input color profile
+  completed the correction with the target image's own as-shot
+  multipliers.
+
 ## Lua
 
 ### API Version

dev-doc/GUI_Threading.md

@@ -415,7 +415,9 @@ instance. It is torn down again straight away, and `exposure`'s `gui_cleanup()`
 instance behind it. In tree the callers carry that check:
 `dt_dev_exposure_get_effective_exposure()` resolves a live, enabled instance itself and
 passes that one, and the other two getters go through a helper that requires
-`proxy.exposure.module` to be set (`src/develop/develop.c`).
+`proxy.exposure.module` to be set (`src/develop/develop.c`). `dt_dev_cat_is_active()`, the
+only caller of color calibration's `proxy.cat_is_active`, passes only the `channelmixerrgb`
+instances it finds in `dev->iop` (`src/develop/develop.c`).
 
 The producing side — usually `commit_params()` or `process()` — must take the same lock.
 Publishing a raw pointer into `gui_data` through a proxy is worse still: the reader then

dev-doc/IOP_Module_API.md

@@ -488,7 +488,7 @@ Called when an image is loaded, including when switching images. Its purpose is
 
 When invoked through the wrapper `dt_iop_reload_defaults()`, the framework calls `dt_iop_load_default_params()` after the module's own `reload_defaults()` returns, copying `default_params` into `self->params`. So on the wrapper path, writing to `default_params` inside `reload_defaults()` immediately affects `self->params` as well. Most callers use the wrapper (for example `_dt_dev_load_pipeline_defaults()`, the per-module reset button, and instance duplication).
 
-**Caveat: direct calls skip only the framework copy, not the module body.** A few sites invoke `module->reload_defaults(module)` directly instead of through the wrapper (for example, `dt_dev_read_history_ext()` calls `temperature->reload_defaults(temperature)` to refresh the white balance state). Those callers do **not** get the automatic `dt_iop_load_default_params()`, so the wholesale `default_params` -> `self->params` copy does not happen. This does **not** mean `self->params` is left untouched: the module's own `reload_defaults()` body may still write specific `self->params` fields directly. `temperature.reload_defaults()` does exactly this: it writes `p->preset` (via `p = self->params`) together with `default_params`, while the white balance coefficients are written to `default_params` only. On a direct call, the result is therefore a *partial* update: the fields the body touches change in `self->params`, the rest do not, and no history entry is recorded. If you add such a call, prefer `dt_iop_reload_defaults()`, or check exactly which `self->params` fields the body changes and sync the rest yourself.
+**Caveat: direct calls skip only the framework copy, not the module body.** A few sites invoke `module->reload_defaults(module)` directly instead of through the wrapper (for example, `dt_dev_read_history_ext()` calls `temperature->reload_defaults(temperature)` to refresh the white balance state). Those callers do **not** get the automatic `dt_iop_load_default_params()`, so the wholesale `default_params` -> `self->params` copy does not happen. This does **not** mean `self->params` is left untouched: the module's own `reload_defaults()` body may still write specific `self->params` fields directly. `temperature.reload_defaults()` does exactly this: it writes `p->preset` and `p->late_correction` (via `p = self->params`) together with `default_params`, while the white balance coefficients are written to `default_params` only. On a direct call, the result is therefore a *partial* update: the fields the body touches change in `self->params`, the rest do not, and no history entry is recorded. If you add such a call, prefer `dt_iop_reload_defaults()`, or check exactly which `self->params` fields the body changes and sync the rest yourself.
 
 #### Job 1 (all modules that implement this): compute image-specific default params
 
@@ -513,7 +513,9 @@ Widgets created with the `_from_params` helpers take their default value (the on
 
 Some modules use `reload_defaults()` to write shared state, such as `dev->chroma`, that other modules depend on. This happens whether or not the module is enabled or has a history entry.
 
-Example: `temperature.c` always computes the camera's as-shot white balance coefficients and its D65 reference coefficients, and writes them into `dev->chroma.as_shot[]` and `dev->chroma.D65coeffs[]`. `channelmixerrgb.c` reads `D65coeffs` in its own `reload_defaults()`, `commit_params()` and `process()` for chromatic adaptation. White balance allows only one instance, which is always present when defaults are loaded, so its `reload_defaults()` runs on every image load. Color calibration therefore has this reference even when the white balance module is disabled or absent from the history.
+Example: `temperature.c` always computes the camera's as-shot white balance coefficients and its D65 reference coefficients, and writes them into `dev->chroma.as_shot[]` and `dev->chroma.wb.D65coeffs[]`. `channelmixerrgb.c` reads `D65coeffs` for chromatic adaptation, from `dev->chroma` in its own `reload_defaults()` and from the per-pipe copy `pipe->wb` in `commit_params()` and `process()`. White balance allows only one instance, which is always present when defaults are loaded, so its `reload_defaults()` runs on every image load. Color calibration therefore has this reference even when the white balance module is disabled or absent from the history.
+
+[How white balance and color calibration share state](iop/wb_and_colorcalibration/README.md) lists which module writes and reads each field of `dev->chroma` and `pipe->wb`, and explains why the reverse-order default load is safe.
 
 #### Where `default_params` is consumed
 

dev-doc/Module_Lifecycle.md

@@ -365,17 +365,25 @@ history up to the given position, updates every module's GUI, then calls
 
 ## 4. Cross-module interactions
 
-### 4a. White balance -> color calibration (through `dev->chroma`)
+### 4a. White balance -> color calibration (through `dev->chroma` and `pipe->wb`)
 
 White balance (`temperature.c`) and color calibration (`channelmixerrgb.c`) share state in
-`dev->chroma`; there is no signal. White balance writes the camera's reference coefficients in
-`reload_defaults()` and the coefficients it applies in `commit_params()`; color calibration
-reads them in `reload_defaults()`, `commit_params()` and `process()`.
+`dev->chroma` and in each pipe's `pipe->wb`. There is no signal. White balance writes the
+camera's reference coefficients into `dev->chroma` in `reload_defaults()`. In
+`commit_params()`, it writes the coefficients it applies into `dev->chroma` and into its pipe's
+`pipe->wb`. Color calibration reads `dev->chroma` in `reload_defaults()`, and `pipe->wb` in
+`commit_params()` and `process()`. Its GUI calls `dt_dev_get_gui_wb()`, which asks white
+balance, through a proxy, for the values that white balance's current params give.
 
 Commit order does not guarantee that white balance commits first: `synch_all` replays the
 history in history order, and `synch_top` re-commits only the top item. Color calibration
-therefore recomputes its camera illuminant (`DT_ILLUMINANT_CAMERA`) in `process()`, which runs
-after all the pipe's commits are done.
+therefore recomputes the two illuminants that depend on white balance, `DT_ILLUMINANT_CAMERA`
+and `DT_ILLUMINANT_FROM_WB`, in `process()`, which runs after all the pipe's commits are done.
+
+[How white balance and color calibration
+share state](iop/wb_and_colorcalibration/README.md) lists which module writes and reads each
+field, explains the per-pipe copy `pipe->wb` and the proxies between the two modules' GUIs, and
+shows why the reverse-order default load stays correct.
 
 ### 4b. Color-profile change (colorin / colorout)
 
@@ -424,7 +432,8 @@ Shared state that a `reload_defaults()` depends on must therefore be **reset to
 value before the reverse default-load**. The framework does this for white balance: it calls
 `dt_dev_reset_chroma()` just before `_dt_dev_load_pipeline_defaults()`. The neutral white
 balance coefficients make color calibration compute its default illuminant from the image's own
-as-shot coefficients, instead of from values left by the previous image.
+as-shot coefficients, instead of from values left by the previous image. [How white balance
+and color calibration share state](iop/wb_and_colorcalibration/README.md) has the details.
 
 ---
 
@@ -508,9 +517,17 @@ section above.
 | `enter` | views/darkroom.c | Darkroom entry: load image, create GUIs, reload defaults, replay history |
 | `_dev_load_requested_image` | views/darkroom.c | Darkroom image switch: keep base instances, read history, replay |
 
+The white balance and color calibration symbols (`temperature.*`, `channelmixerrgb.*`, and the
+`dev->chroma` helpers) are listed in [How white balance and color calibration share
+state](iop/wb_and_colorcalibration/README.md#key-symbols).
+
 ## See also
 
 - [IOP_Module_API.md](IOP_Module_API.md): the callback API reference (signatures, the two
   [`reload_defaults`](IOP_Module_API.md#reload_defaults---per-image-defaults) jobs).
 - [pixelpipe_architecture.md](pixelpipe_architecture.md): pipeline architecture, including the
   [ordering-asymmetry note](pixelpipe_architecture.md#pipeline-ordering-asymmetry).
+- [How white balance and color calibration share
+  state](iop/wb_and_colorcalibration/README.md): the data that the two modules exchange through
+  `dev->chroma` and `pipe->wb`, as a worked example of the ordering rule in
+  [section 5](#5-pipeline-ordering-asymmetry).

dev-doc/New_Module_Guide.md

@@ -83,7 +83,7 @@ Ensure your module is in the correct place in `iop_order.c`.
 -   **Scene-referred** modules should generally be earlier.
 -   **Display-referred** modules should be later.
 
-**Note:** Pipeline ordering affects `commit_params()` execution order. Modules that share state (e.g., via `dev->chroma`) depend on earlier modules having committed first. See [pixelpipe_architecture.md](pixelpipe_architecture.md#pipeline-ordering-asymmetry) for details.
+**Note:** `commit_params()` does not always run in pipe order. During history replay, modules commit in history order. A module that reads state written by an earlier module, as color calibration reads white balance's `pipe->wb`, cannot rely on that module having committed first. See [pixelpipe_architecture.md](pixelpipe_architecture.md#pipeline-ordering-asymmetry) for details.
 
 ### Shortcuts
 By using `dt_bauhaus` widgets, shortcuts are automatically supported.