Stop describing a base curve the pipeline no longer has

D19 retired the per-body base curve, moved the matrix ahead of the
edits and the film into the view transform's place, but a dozen doc
comments still listed the curve among what a pixel passes through, or
said the film skipped it. The detail stage's module doc still drew the
matrix after the edits and the last detail pass encoding, which the
view pass took over. The film crate's README gave the base curves as
its reason for being data, and the ops README's list of hand-written
nodes had neither the view transform nor three of the five kernels.

FR-MRG-2 gave the base curve as why the merge cuts below the profile;
the view transform is why now. The decision table still said colour
defaults were a per-body curve, and FR-DEV-3j said only the default
view transform skips a JPEG, where the node skips one whatever its
sliders say. frame-budget.md records the view pass as unmeasured.

core/dr-pipeline/src/descriptor.rs

@@ -659,10 +659,10 @@ impl Attribute {
     ///
     /// `Effect` after `Colour` is a look laid over a settled picture — and is
     /// the one arguable slot. A spectral film simulation declares
-    /// [`crate::Operation::renders`] and replaces the base curve, which is an
-    /// argument for treating it as foundational rather than final; an array of
-    /// six cannot say "last, except when it is first". The tension is recorded
-    /// here rather than settled.
+    /// [`crate::Operation::renders`] and takes the view transform's place at
+    /// the very end of the chain (D19), which is an argument for treating it as
+    /// the rendering rather than one effect among others; an array of six
+    /// cannot say that. The tension is recorded here rather than settled.
     ///
     /// Both ends were wrong for as long as this list only fed a row of chips
     /// nobody reads in order. It stopped being harmless when the same list

core/dr-pipeline/src/detail.rs

@@ -24,9 +24,10 @@
 //!        v
 //!   +------------------------------------------+
 //!   | the fused point-operation pass           |  one dispatch
-//!   |   white balance, exposure, tone, colour  |
-//!   |   the mask layers                        |
+//!   |   white balance (camera RGB)             |
 //!   |   camera RGB -> linear sRGB              |
+//!   |   exposure, tone, colour                 |
+//!   |   the mask layers                        |
 //!   +------------------------------------------+
 //!        |  rgba16float, linear, **unclipped**, at render resolution
 //!        v
@@ -34,7 +35,13 @@
 //!   | the detail stage - this module           |  one dispatch per pass
 //!   |   sharpen, NR, clarity, texture, spots   |
 //!   +------------------------------------------+
-//!        |  the last pass applies the output transform
+//!        |  rgba16float, still scene-linear and unclipped
+//!        v
+//!   +------------------------------------------+
+//!   | the view pass                            |  one dispatch
+//!   |   view transform, or the film stock      |
+//!   |   output transform, mask reveal          |
+//!   +------------------------------------------+
 //!        v
 //!   rgba8unorm display or export texture
 //! ```
@@ -52,14 +59,13 @@
 //! texture, clarity, spot removal and sharpen/NR sit below the tone curve and
 //! the colour mixer.
 //!
-//! **In linear light, after the camera matrix.** The fused pass works in
-//! *camera* space, because white balance and exposure are physically
-//! meaningful there and nowhere else. A detail pass is the opposite case: it
-//! wants a luminance, and camera RGB has no luminance — the three channels are
+//! **In linear light, after the camera matrix.** A detail pass wants a
+//! luminance, and camera RGB has no luminance — the three channels are
 //! whatever the CFA's dyes passed, and weighting them 0.2126/0.7152/0.0722
-//! would be numerology. So the split is taken *after* the `cam_to_srgb`
-//! multiply, where the working space is linear sRGB and a luminance is a
-//! luminance.
+//! would be numerology. Since D19 only white balance runs in camera RGB; the
+//! `cam_to_srgb` multiply follows it, so every point operation, and every
+//! detail pass after them, works in linear sRGB primaries, where a luminance
+//! is a luminance.
 //!
 //! **Before the output transform, and before the clip.** FR-DEV-2 allows
 //! exactly one quantisation, at the display or export stage. A detail pass
@@ -70,9 +76,11 @@
 //! therefore `rgba16float` and holds linear values that have **not** been
 //! clamped to `0..=1`: a recovered highlight is still above one at this point,
 //! and clipping it before the sharpener sees it would put a hard edge exactly
-//! where the sharpener is most visible. The last detail pass performs the
-//! primaries conversion, the clip and the encode, so the single quantisation
-//! stays single.
+//! where the sharpener is most visible. Every detail pass writes such an
+//! intermediate, the last one included, and the view pass after them — the
+//! view transform, then the output transform's primaries, clip and encode —
+//! is the one place the scene is fitted to a display (D19, ARCH §6.14), so
+//! the single quantisation stays single.
 //!
 //! **After framing, at render resolution.** The alternative — running detail
 //! on the demosaiced source before the framing prologue — is superficially

core/dr-pipeline/src/mask.rs

@@ -2068,8 +2068,8 @@ pub(crate) struct LayerShader {
     ///
     /// Kept apart from the rest because it belongs at the other end of the
     /// shader. Everything else runs on scene-referred colour in the working
-    /// space, where a flat tint would then be pushed through the base curve
-    /// and the camera matrix and arrive as some other colour, and a
+    /// space, where a flat tint would then be pushed through the view
+    /// transform and arrive as some other colour, and a
     /// white-on-black alpha would arrive as neither. This runs after the
     /// output transform, so what is written is what is seen.
     pub reveal: String,

core/dr-pipeline/src/neutral.rs

@@ -82,8 +82,8 @@ const FLOOR: f32 = 1e-4;
 /// Move the graph so that `sample` renders neutral.
 ///
 /// `sample` is the linear triple the operation's own gains multiply — camera
-/// RGB with the camera's as-shot balance on, *before* the body's base curve
-/// and matrix, and with the sampling operation at its defaults. Not the
+/// RGB with the camera's as-shot balance on, *before* the camera matrix and
+/// the view transform, and with the sampling operation at its defaults. Not the
 /// pixel on the screen: the matrix mixes the channels on the way there, so
 /// a colour read after it does not answer to these gains, and a solve over
 /// one lands somewhere no sample asked for. Returns whether the graph was

core/dr-pipeline/src/operation.rs

@@ -518,7 +518,7 @@ pub enum OutputMode {
     ///
     /// What a merge stitches (FR-MRG-2). The shader is the linear tail with
     /// no operations, and the caller fills the reserved uniforms neutral —
-    /// unit white balance, identity matrix, base curve off — so what is
+    /// unit white balance, identity matrix, no view transform — so what is
     /// stored is the sensor's own numbers, demosaiced and undistorted. Only
     /// [`compose_camera_probe`] produces it — for a merge through
     /// [`compose_camera_linear`], and for the white balance picker under the

core/dr-pipeline/src/ops/film_sim.rs

@@ -706,10 +706,10 @@ mod tests {
 
     #[test]
     fn it_declares_itself_a_rendering_transform() {
-        // The whole reason the composer skips the base curve and the camera
-        // matrix. If this ever returned false the picture would be rendered
-        // twice and converted twice, which looks like a colour management bug
-        // a long way from here.
+        // The whole reason the composer emits the stock in the view
+        // transform's place rather than beside it. If this ever returned
+        // false the picture would be rendered twice, which looks like a
+        // colour management bug a long way from here.
         assert!(FilmSim::new().renders());
     }