Feature request: Adaptive local contrast enhancement for low-dynamic-range restoration (VHS/old film masters)

[alfonslm]

Use case
Content digitized from VHS, LaserDisc, and old broadcast/film masters frequently has flat, low-local-contrast images: raised blacks, compressed midtones, little separation. This is a characteristic of the source itself.
There are two legitimate places to correct it, and they serve different roles:

• Mastering side: whoever creates the preservation/distribution copy (digitizing the tape, uploading to an archive) can bake the correction into the delivered encode — keeping an untouched mezzanine (e.g. ProRes) as the raw, and applying CLAHE to the distributed file (e.g. MKV). This is the correct place to re-encode.

• Playback side: but the end user who only has the untouched source — a download with no corrected version, an old personal capture — shouldn't have to re-encode to view it correctly. This is where a live playback toggle belongs.

This is exactly the deinterlace model: the correction can be baked in at the mastering stage, yet players still offer a live toggle because the end user often has only the un-corrected source. Adaptive local contrast fits the same two-role pattern.

The gap in current playback tools
On the playback side, global contrast/gamma controls can't address this cleanly. Pushing global contrast enough to lift a murky scene clips highlights and crushes blacks in punchier scenes within the same content, and the "correct" global value shifts shot to shot or even within a shot, requiring constant manual adjustment. This is exactly what adaptive/local methods solve: per-region contrast stretching (CLAHE, local Laplacian) treats bright and dark areas of the same frame independently, avoiding global clipping and needing no per-shot babysitting.

Why this should be a built-in toggle, not a user shader
The natural response is "write a user shader," but I'd argue this belongs as a built-in for the same reasons deinterlacing is: it's a canonical correction for a source characteristic, not a stylistic embellishment. It's a common need across a whole class of old-source content, and there's a broadly correct way to do it. Built-ins earn their place by being both common and canonical, and adaptive local contrast for flat SD masters qualifies on both counts — it's part of faithfully reproducing this kind of source, the same way deinterlace is.

Why a deterministic operator rather than the AI-shader ecosystem
There's a growing set of neural/AI enhancement shaders, but those synthesize detail that was never in the master — which makes them unsuitable as a faithful default. CLAHE-style local contrast is different in kind: it's a deterministic, information-preserving operation that redistributes tonal information already latent in the signal per-region, rather than inventing new content. That principled, non-generative character is exactly what makes it appropriate as a restoration default, in a way generative upscaling isn't.

Anticipating "isn't tone-mapping already this?"
The existing adaptive tone-mapping is deterministic and adaptive too, so this may look redundant — but it targets a different problem. Tone-mapping handles dynamic-range conversion between color volumes (e.g. HDR→SDR). This request is within-range local contrast recovery on SDR→SDR content, which the tone-mapping path doesn't address. Different goal, different stage.
Not prescribing an implementation — CLAHE and local Laplacian are named as the well-understood examples; whatever fits the existing pipeline best. The ask is for the capability, framed as a restoration operator analogous to deinterlace: enable it for old-source playback and forget about it.

A possible second use case: SDR→HDR expansion, conditional on source quality
The same adaptive-local-contrast primitive is also a foundation for SDR→HDR inverse tone-mapping — but only where the source justifies it. Naive inverse tone-mapping produces the "fake HDR" look precisely because it expands range without recovering local contrast first; this operator is the missing building block. That said, it's garbage in, garbage out: on a degraded master, expanding a compromised signal just yields a compromised result, so this second use case applies to clean, well-preserved SDR source material, not the degraded captures the restoration case targets. Worth noting as a related application of the same primitive, with that caveat.

[haasn]

Note that we already have a HDR contrast recovery pass (for HDR->SDR). We could maybe retool that? The way the algorithm works is a bit simplistic, it just does a lowpass by subtracting the image from a blurred copy, then re-adds that difference onto the tone-mapped result.

[alfonslm]

Thanks — that pass is a useful starting point, but working through it I kept landing on the conclusion that it's the last step, and the earlier ones matter more. Laid out by pass:

Range recovery (the core issue)
The main problem with these masters isn't local contrast — it's that the whole tonal range is compressed: blacks read as dark grey rather than black, whites top out early, everything clumps toward mid-grey. Once that's the framing, a lowpass-and-re-add can't be the fix — it's a local operation, so it adds micro-contrast around neighbourhoods but can't pull the black point back down, which is a global redistribution. The milky look survives no matter how good the local contrast is. So the range has to be stretched back out first, on luma. Even a plain global black/white-point stretch would be the single biggest visible win; per-region adaptive is the nicer-to-have.

Local contrast (your existing pass — the second big win)
Once the range is stretched back out, this pass is what recovers the mid-tone contrast — range recovery fixes the endpoints (black and white back where they belong), but the mid-range separation is still flat, and that's exactly what the local-contrast pass restores. So it's a big improvement in its own right, just second in line rather than first. Two questions that came from thinking about pushing it harder: does it clamp to avoid haloing at strong settings, and could the single lowpass extend to multiple radii for a multi-scale result instead of one frequency band?

Chroma (a separate axis, not the luma fix on colour)
I first assumed this was just the range fix applied to the colour channels, but it isn't. You can't expand chroma toward a fixed target, because the "correct" saturation is per-shot intent: a candyland scene wants to be vivid, a noir shot wants near-zero chroma. Push both toward a global average and you wash out the first and pump false colour into the second — and a naive measurement can't tell a correctly-graded noir shot from a badly-faded colour one. That rules out auto-targeting and points to relative expansion: stretch whatever distribution is present outward from its own centre, via a midtone-weighted curve on Cb/Cr rather than a flat multiplier. It's self-protecting (a near-mono shot has nothing to expand, so noir stays noir) and has a much larger safe range above neutral than a flat multiply, since the lift targets the muted midrange instead of dragging already-saturated pixels toward clipping — more so if the curve soft-rolls near the top. Wants to sit after denoise, since it amplifies chroma noise too.

Ordering & scope
The order isn't arbitrary — each step depends on the one before. Range comes first because local contrast needs a properly-ranged signal to work within. Chroma goes last because perceived saturation depends on brightness: adjust colour before the luma is settled and you're tuning against a brightness that's about to change, so it looks wrong once the luma work lands — set it against the final image and it looks natural. So: range → local contrast → chroma, all on the same signal (luma on Y, chroma on Cb/Cr), which also lets them be independent toggles since a master might need one, two, or all three.
This assumes a clean, reconstructed input upstream — denoise and AI reconstruction/upscaling are user-filter stages, not asks here, but they'd need defined insertion points ahead of this chain (denoise first, since everything downstream amplifies; reconstruction before the tonal passes). Running both should be allowed but needn't be supported, since you can't guarantee behaviour from arbitrary user-filter combinations.

On scope: range recovery and the local-contrast questions are really just clarifying and refining what's already on the table — range is the core of what I was originally after, and local contrast is your existing pass. Chroma is the one genuinely new axis, but it's also the most tractable — the mechanism is just a curve on the chroma channel, so the only real design work is the relative-expansion behaviour rather than the operation itself. It's also the most severable if you'd rather keep this focused. On priority, the range stretch is the actionable core — biggest single improvement, most self-contained. Happy to supply before/after test sources, and to go into the chroma behaviour in more detail if that's useful.

PS — sorry for the length; once I started thinking about how it'd actually need to work, the pieces kept connecting, and it seemed more useful to lay out the whole reasoning than to drop conclusions without it.