WIP: clarity and texture
Checkpoint committed by the coordinator, not by the authoring agent: the session hit its API limit mid-task and left this work uncommitted. Committed so it survives, NOT because it is finished - expect failing tests and half-applied changes. The agent resumes from here.
This commit is contained in:
@@ -0,0 +1,23 @@
|
||||
# A hand-written node — see `clarity.yaml`, whose implementation this shares.
|
||||
id: texture
|
||||
order: 130
|
||||
|
||||
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.
|
||||
Reference in New Issue
Block a user