Advanced option: run the native Radiance/hdrgen binaries instead of the WebAssembly ones

[adulbrich]

Not blocking. The WebAssembly pipeline is the right default and should stay the default: it is what removes the install step, and it is the only thing that works in a browser at all.

But two groups are worse off than they were, and both are the project's actual users:

• Anyone running large brackets. WebAssembly costs roughly 2x native wall clock, measured in Phase 0: hdrgen to WebAssembly spike (go/no-go) #228 (11.6 s vs 4.7 s on the CR2 bracket, 26.9 s vs 12.0 s on JPEG). On a batch of twenty sets that is minutes, repeatedly.
• Anyone above the resolution ceiling. wasm32 is capped at 4 GB, and the floor scales with frame area at ~70 bytes/pixel, so the ceiling arrives around 55-60 MP (Epic: port the pipeline to WebAssembly for a zero-dependency desktop app and a fully client-side web app #227). A native binary has no such limit. Today those users simply cannot process the image.

Both had a working path before the port and do not now.

The seam already exists

ToolRunner (src/lib/pipeline/types.ts) is the abstraction the orchestrator drives, and its own docstring anticipates this:

One implementation instantiates an Emscripten module per call, stages inputs into its filesystem and calls callMain. Another can shell out to native binaries, which is what makes the orchestrator testable without any wasm.

So this is a second implementation of a five-method interface, not a second pipeline:

interface ToolRunner {
  exists(path): Promise<boolean>
  readFile(path): Promise<Uint8Array>
  release?(paths): void
  run(tool, args, io?): Promise<ToolResult>
  writeFile(path, data): Promise<void>
}

A native runner maps the virtual paths onto a real temp directory and run onto @tauri-apps/plugin-shell. The stage sequencing, the argument construction and every test above it are untouched.

Scope

• NativeToolRunner, desktop only. canRunNativeTools() belongs in src/lib/host/env.ts alongside the other capability checks, and must be false in a browser rather than merely unused there.
• A Settings control, off by default and clearly marked advanced, plus the tool-directory paths it needs. These were removed in Phase 4: browser I/O layer (File System Access, OPFS, drop tool-path settings) #232 and would come back narrower: opt-in, not required to use the app at all, which was the whole complaint.
• Report which runner produced a picture. A run that silently used a different implementation is a reproducibility problem, and the two are not bit-identical (see below).
• Fall back to WebAssembly, loudly, when a configured binary is missing or the wrong version. Silently doing something different from what the setting says is worse than refusing.

The part that needs care

The two paths do not agree to the last bit, and the differences are known and documented rather than mysterious:

• RAW/TIFF matches native to 1e-8.
• JPEG differs by an unbiased ~1.7%, traced to the float IDCT (Decide PANLIB_JPEG_REPRODUCIBLE_DCT for the wasm build (recommend ON) #235).
• The residual on the RAW path is AHD demosaic's pow(), a libm difference no compiler flag reaches. Bilinear and VNG are byte-identical.

So a user who switches runners mid-study gets slightly different numbers, which for a luminance-measurement tool is a real hazard rather than a footnote. Whatever the header records about provenance (#241) should say which runner ran, and the Settings copy should say plainly that switching changes results.

Version skew is the other trap. public/wasm/versions.json pins exactly which Radiance and hdrgen the bundled artifacts came from. A native install is whatever the user has, which may be older, newer, or a different build entirely. Refusing to run on a mismatch is probably too strict; recording it is not optional.

Explicitly out of scope

Shipping native binaries again. That was rejected in #227 for good reasons: 8 tools x 5 targets is 40 artifacts to rebuild per Radiance release, and Radiance tags a release per upstream commit. This is about pointing at an install the user already has, not maintaining one.