mirror of
https://github.com/bherbruck/solidcraft.git
synced 2026-11-06 20:02:16 +00:00
CamWight
14acdc2a6d
* Render: one sRGB transfer function, geom::srgb, for the hand-written copies (#7161) Twelve places wrote the sRGB encode or decode formula out by hand (doc's glass recipe, engine's render library, glTF import, the PNG film, photographic and presentation output, the ray tracer's image, the stage, the surface decoder, texture normalisation and the theme's contrast check). They now call solidcraft_geom::srgb: encode/decode on 0..1 values, encode8/decode8 for 8-bit codes. render::surface::srgb8_to_linear stays as a re-export, so its callers are unchanged. Same results: the module's tests compare it bit for bit with the formula as the callers wrote it, over all 256 codes and a dense sweep of linear values plus the knees, out-of-range values, infinities and NaN, for each way the callers clamped (after encoding, before it, or not at all), and decoded values either side of the decode knee, where no 8-bit code falls. One change: glTF import encoded in f32. Over every f32 in 0..1, 218 of 1,065,353,217 values sit on a rounding tie that f32 got wrong and now give the neighbouring code (f64 gives the nearer one). Left as they are: render/job/image.rs (replaced by exact tables in its own change), the tests and the starter-pack validator that keep their own copy as an independent reference, and the WGSL shaders (they can't call Rust). Fixes #7161 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Tests: the sRGB codes of five callers that had no test of their output (#7161) The glass swatch, a library surface applied as a plain appearance, glTF's fallback for a colour channel that isn't a number, a stage panel and an empty pixel in presentation output each get an assertion with their sRGB codes worked out by hand. A planted wrong conversion at each is now caught by that test. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>