dtourolle
b4e55b47c1
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.
31 lines
1.5 KiB
YAML
31 lines
1.5 KiB
YAML
# A hand-written node. `rust:` names the type in `crate::ops` that implements
|
|
# `Operation`; its descriptor, its parameters and its passes come from that
|
|
# type rather than from this file.
|
|
#
|
|
# It appears here anyway so that `ops/` lists the whole pipeline in order —
|
|
# including the neighbourhood operations, which run as a group after every
|
|
# point operation but are still ordered among themselves.
|
|
id: noise_reduction
|
|
order: 110
|
|
|
|
rust: NoiseReduction
|
|
|
|
why_rust: |
|
|
A kernel, not four facts. The declarative schema hands a fragment a colour
|
|
and no coordinate, which is precisely what a denoiser cannot work with — it
|
|
is defined by what the neighbouring pixels are doing. It is therefore a
|
|
`DetailStage` (see `../src/detail.rs`), which means deciding at every render
|
|
how many dispatches to emit, converting a radius stated in *source* pixels
|
|
into the render pixels this frame is being drawn at, and declaring the halo
|
|
the tile scheduler needs. None of that is expressible as a uniform
|
|
expression, and stretching the schema to cover it would produce a worse
|
|
language than Rust aimed at one caller.
|
|
|
|
placement: |
|
|
First among the detail operations, because 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. Its position relative to the point
|
|
operations is not this number's to decide — the whole detail stage runs
|
|
after the fused pass, in linear light, before the output transform.
|