dtourolle
35b126449b
Capture sharpening and noise reduction were written in parallel and both claimed `order: 110`; the codegen refuses that, which is the guard working — two nodes at one order is an ambiguous pipeline and operation order changes the result. Resolved in noise reduction's favour, for the reason its own `placement:` block already gives: denoising is a repair and everything else in this stage is an enhancement. Sharpening or adding clarity to a noisy frame amplifies the grain along with the detail, and no later pass can separate them again. So the detail stage now runs noise reduction, capture sharpening, clarity, texture, and the other three shift up a slot to keep the multiple-of-ten convention the rest of the chain uses. Noise reduction was also missing the required `attributes:` key. The order collision aborted the build before the attribute check could report it, so it arrived looking like one fault and was two.
24 lines
949 B
YAML
24 lines
949 B
YAML
# A hand-written node — see `clarity.yaml`, whose implementation this shares.
|
|
id: texture
|
|
order: 140
|
|
|
|
attributes: [detail]
|
|
rust: Texture
|
|
|
|
why_rust: |
|
|
The same neighbourhood operation as clarity, at a tenth of the scale: one
|
|
implementation in `src/ops/local_contrast.rs`, parameterised by the band it
|
|
acts on. Two nodes rather than one node with two sliders because the radius
|
|
is the *definition* of each control rather than a setting of it, and because
|
|
a texture at zero must then cost nothing at all — which `is_active()` gives
|
|
for free and a merged node would have had to hand-write.
|
|
|
|
placement: |
|
|
Immediately after clarity, and for the same reasons: after noise reduction,
|
|
which must not be handed amplified grain, and before capture sharpening,
|
|
which belongs last.
|
|
|
|
After clarity specifically, so that the fine base is computed on the
|
|
modelling the coarse control has already settled rather than the other way
|
|
round.
|