Apply a camera profile's HueSatMap and LookTable after exposure

The second half of D20: a camera_profile scene operation at order 25
that converts working colour into linear ProPhoto, runs the DNG SDK's
HSV lookup through the HueSatMap and then the LookTable, and converts
back. Hue and saturation do not change under the uniform gains before
it, so a 2.5-D HueSatMap gives the same answer as straight after the
matrix, and the look sees the photographer's exposure as it does in
the SDK. Two departures for scene-referred values: value is not
clamped on the way out, and a colour outside ProPhoto passes through.

The operation holds only the switch (on by default) and a look
strength of 0-200 %. It is composed while the switch is on — a new
Operation::composes() separates "does something" from "moved from the
defaults", so an untouched raw renders through its profile and still
writes nothing. The tables come from the source: dr-gpu uploads the
ones DemosaicedImage carries into a storage buffer at @binding(8),
whose two-entry header tells the fragment whether there is anything to
apply, and binds a header of zeros for every other source.

apply_reference is the lookup on the CPU. The GPU test holds the
shader to it over 256 colours, through synthetic tables strong enough
that a wrong index shows, and through the library's real Adobe
Standard tables when the 6D DNG is present.

core/dr-pipeline/src/graph.rs

@@ -1170,19 +1170,21 @@ mod tests {
         // Opening an unedited image must produce the image, not an
         // interpretation of it.
         //
-        // One block, and it is the view transform: a view operation is
-        // composed at its defaults, because a photograph with no view
-        // transform is a scan rather than a picture (FR-DEV-3j). It is still
-        // neutral in the sense that matters here — nothing moved, nothing is
-        // written — and every adjustment is absent.
+        // Two blocks, the view transform and the camera profile: both are
+        // composed at their defaults, because a photograph with no view
+        // transform is a scan rather than a picture (FR-DEV-3j) and a raw
+        // with a profile is rendered through it (D20). They are still neutral
+        // in the sense that matters here — nothing moved, nothing is written
+        // — and every adjustment is absent.
         let g = EditGraph::default_chain();
         assert!(g.is_neutral());
         let source = g.compose().source;
         assert_eq!(
             source.matches("---- ").count(),
-            1,
+            2,
             "a neutral graph must generate no adjustment blocks"
         );
+        assert!(source.contains("---- camera_profile ----"));
         assert!(source.contains("---- view_transform ----"));
     }
 
@@ -1263,13 +1265,14 @@ mod tests {
     fn only_active_operations_reach_the_shader() {
         // The composition property, end to end: two adjustments out of seven
         // available must generate a shader doing exactly two things — and
-        // the view transform, which every render has (FR-DEV-3j).
+        // the view transform and camera profile, which every render has
+        // (FR-DEV-3j, D20).
         let mut g = EditGraph::default_chain();
         g.set_param(exposure::ID, exposure::EXPOSURE, 1.0);
         g.set_param(white_balance::ID, white_balance::TINT, 25.0);
 
         let shader = g.compose();
-        assert_eq!(shader.source.matches("---- ").count(), 3);
+        assert_eq!(shader.source.matches("---- ").count(), 4);
         assert!(shader.source.contains("---- view_transform ----"));
         assert!(shader.source.contains("---- exposure ----"));
         assert!(shader.source.contains("---- white_balance ----"));