# A hand-written node, and a neighbourhood one: it reads the pixels around the
# one it is writing, so it runs in the detail stage rather than as a fragment
# in the fused pass. See `../src/detail.rs` for why that stage exists and
# `README.md`'s "Nodes that read their neighbours" for the contract.
#
# As with every `rust:` node, its descriptor, parameters and behaviour come
# from the type; this file exists so that `ops/` remains the one place the
# pipeline's order is written down.
id: capture_sharpen
order: 110

attributes: [detail]
rust: CaptureSharpen

why_rust: |
  A convolution, not a point function. The schema in `README.md` describes an
  operation handed a colour with no way back to a coordinate, which is exactly
  what a kernel cannot work with — and stretching it to cover taps, kernel
  extents and a per-render conversion from source pixels to render pixels
  would produce a worse language than Rust aimed at one caller.

placement: |
  First among the detail nodes, because capture sharpening is a correction to
  the capture: it recovers the acutance the anti-aliasing filter, the lens's
  circle of confusion and the demosaic interpolation each took out, and it is
  meaningful before any effect built on top of it. The compositional detail
  controls — texture, clarity — reasonably follow it, since they are about the
  picture rather than about the sensor.

  Being in the detail group at all is what places it after every tonal and
  chromatic operation: an amount tuned before a tone curve is amplified by
  whatever slope that curve happens to have, so the amount that looked right
  stops looking right the moment the curve moves.