54772f94d60aec8fc429589fc69575bcfcddeaf8
3
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
c07f81edcb |
Run the view transform after the detail stage, in a pass of its own
The fused pass stops at "linear working values" when a sharpener, a blur or a repair follows, and the detail passes convolve what it hands on. Until now it handed on the rendering: the base curve, and since the last commit the view transform, ran before the store. So every kernel worked on display-referred values while its comments promised the opposite — D19's second finding. A fused pass composed for a detail stage now stops before the view transform, and carries a second shader, `ComposedShader::view`, composed from the same inputs. It runs the same prologue, for the positions a fragment reads (a film's grain seeds from `source_px`) and the corners it blacks out, takes its colour from the detail stage's result bound where the sample cache would be, and runs the view transform, the output transform and the mask reveal. `render_detailed` dispatches it after the last detail pass, in the same encoder. So no detail pass encodes any more. Every pass writes an intermediate, the last one included, which retires three things that existed only to make the last pass encode: `writes_output` and the runner's second layout, the body-less resolve pass for an active kernel with nothing to draw at this scale, and capture sharpening's pass-through, which now emits no pass at all. An empty chain is a whole render: the view pass reads the fused result directly. The detail stage no longer takes an output space either, so `compose_detail_for` folds into `compose_detail` and the space is named once, on the fused half. The cost is one full-render read and write per frame when a detail stage exists, and a third intermediate for a one-pass chain. |
||
|
|
404fea47a8 |
Wrap the lines the merge resolution left long
Benchmarks / CPU and I/O (per commit) (push) Successful in 2m59s
Benchmarks / Frame budget (on demand) (push) Skipped
Build and test / Desktop (Linux) (push) Failing after 33m34s
Build and test / Layer separation (push) Successful in 55s
Traceability / Requirement traces (push) Successful in 42s
🐳 Android image / Build and push (push) Successful in 3s
Build and test / android-image (push) Successful in 3s
Build and test / Android (aarch64) (push) Successful in 23m43s
`cargo fmt --check` failed the desktop job, on three files and for one reason: routing the mask handlers through the `Masking` global was done by substituting the call prefix, which is a text edit rather than a Rust one. It left `window.global::<Masking>().on_part_join_picked(...)` on a line that had been short enough as `window.on_mask_part_join_picked(...)` and no longer was. Formatting only. The whitespace-stripped source is identical in the two `ui/` files; the third differs by the trailing commas rustfmt adds when it breaks a call across lines. The matrix moves with it, because the tags shift by a few lines and the check compares line numbers. |
||
|
|
4c217c9be6 |
Show what a control does to a photograph, one parameter at a time
Benchmarks / CPU and I/O (per commit) (push) Successful in 2m52s
Benchmarks / Frame budget (on demand) (push) Skipped
Build and test / Desktop (Linux) (push) Failing after 56s
Build and test / Layer separation (push) Successful in 37s
🐳 Android image / Build and push (push) Successful in 4s
Build and test / android-image (push) Successful in 4s
Traceability / Requirement traces (push) Failing after 54s
Build and test / Android (aarch64) (push) Successful in 26m29s
A node that has just been declared can be read, reasoned about and tested, and none of that answers the question a photographer asks first: what does moving this do to the picture. Colour grading, dehaze and the range masks were all argued into the tree on their behaviour and none of them had been *looked* at. So two diagnostics. `sweep` walks one operation from its minimum to its maximum and writes a frame per step; `rangesweep` does the same for a mask band, which is not an ordinary parameter — it lives on a layer, is rasterised by its own pass, and only becomes visible through whatever adjustment the layer carries, so it gets two stops down to make the selection legible. `sweep` names no operation. The id arrives as a string and the parameters and their ranges come from the graph's own capabilities, so a node declared yesterday sweeps on the same terms as one that shipped a year ago — the property `ops/README.md` promises, used rather than asserted. Three things it learned the hard way and now records. It renders through `render_detailed` unconditionally, because the fused path refuses a shader composed with a detail stage rather than rendering it wrongly, and that call falls through when there is no such stage. It takes `SWEEP_HOLD`, because a parameter grouped under one widget is not meaningful alone: a hue with no strength behind it renders the same frame every time, which reads as a broken node rather than a correctly declared neutral. And it bounds the output, since a 25 MP frame is a 75 MB PPM and a sweep is hundreds of them. Both read a rendered file as readily as a raw one, so a JPEG can stand in where no raw is to hand — on the terms `from_rgba8` documents, with the controls still working and their neutral being what the camera left rather than what the sensor recorded. |