Sync with integration
This commit is contained in:
@@ -209,11 +209,12 @@ They still belong in this directory, because the pipeline's **order** is the
|
||||
one thing a reader comes here to learn, and an order written half in YAML and
|
||||
half in Rust would be worse than either alone.
|
||||
|
||||
Currently hand-written: `tone_curve` (a curve widget over five interpolated
|
||||
points), `colour_mixer` (thirty-six faceted parameters from twelve computed hue
|
||||
bands), `capture_sharpen` (a separable convolution, which is the other reason a
|
||||
node is Rust — see the next section). `vignetting` is hand-written too but is
|
||||
not in the develop chain — it
|
||||
Currently hand-written: `tone_curve` (one widget over four curves of five
|
||||
interpolated points — master, red, green, blue — each reaching the shader only
|
||||
when it has been moved), `colour_mixer` (thirty-six faceted parameters from
|
||||
twelve computed hue bands), `capture_sharpen` (a separable convolution, which
|
||||
is the other reason a node is Rust — see the next section). `vignetting` is
|
||||
hand-written too but is not in the develop chain — it
|
||||
carries lens-profile coefficients that are not parameters. `distortion` and
|
||||
`aberration` are `Warp`s rather than operations: they rewrite coordinates
|
||||
before sampling rather than transforming a colour after it.
|
||||
|
||||
@@ -16,13 +16,26 @@ attributes: [tone, colour]
|
||||
rust: ToneCurve
|
||||
|
||||
why_rust: |
|
||||
Five control points presented as one curve widget, with an interpolator and
|
||||
a monotonicity guarantee behind it. Its neutral is a *relationship* between
|
||||
parameters rather than a set of values — the identity diagonal — which is
|
||||
not something the declarative `active:` rule can express, and its
|
||||
`presentation()` spans parameters rather than describing one.
|
||||
Four curves — master, red, green, blue — of five control points each,
|
||||
presented as one widget, with an interpolator and a monotonicity guarantee
|
||||
behind them. Its neutral is a *relationship* between parameters rather than
|
||||
a set of values — the identity diagonal, on every channel — which is not
|
||||
something the declarative `active:` rule can express; its `presentation()`
|
||||
spans forty parameters rather than describing one; and its fragment is
|
||||
*assembled* rather than written, because each curve reaches the shader only
|
||||
when it has been moved off the diagonal. A declared node's `wgsl:` is one
|
||||
fixed block of text, which is the right shape for nearly everything here and
|
||||
the wrong one for a node whose cost has to follow what the photographer
|
||||
actually touched.
|
||||
|
||||
placement: |
|
||||
After the fixed-weight region controls, so the curve is the final word on
|
||||
tone: a photographer reaches for it to fix what those controls could not
|
||||
place exactly.
|
||||
|
||||
Within the node, the master curve runs before the per-channel ones. Both
|
||||
orders are visibly different images and the reasons for this one are written
|
||||
out in `src/ops/curve.rs`: the master is tonal and hue-preserving, the
|
||||
per-channel curves are the chromatic grade over the tones it produced, and a
|
||||
point placed on a channel curve should act on the tone the photographer can
|
||||
see rather than on the one the master is about to move.
|
||||
|
||||
Reference in New Issue
Block a user