[j64esatxzdrhfg]

Players asked for a contrast control for HDR, as the RenoDX HDR mods have. The Expanded picture is otherwise fixed at the game's SDR contrast.

Lands together with #1942, which builds on this PR. With Sharpness, the Window scaling filter or ultrawide's menu sides on, the game's own (Native) picture reaches this pass through an 8-bit RGBA8 image until #1942 scales it in 10 bits, and contrast above 100% would make that banding worse. (Since main's 0a28ff2 gave RGB10A2 its own texture-cache class, Native itself is taken on main.)

What changed

• shaders/hdr_encode.comp: after the SDR expansion (mode 0, Expanded, unchanged) or the game's own PQ picture decoded (mode 1, Native), the light is graded as RenoDX's Contrast does it: on luminance relative to the paper white, pow(Y * exposure / 0.18, contrast) * 0.18, hue kept. Exposure is pushed as 1 for now. Push constants grow to 48 bytes.
• A shoulder eases the graded light back onto the peak (peak / paper white). Above a knee it uses Reinhard's rational shape, matching the graded curve's slope at the knee and reaching the peak exactly at the graded top. Contrast above 100% pushed the top far past the peak (about 3500 nits at 150%), and a plain limit then cut every highlight flat. With the top its own target, the shoulder is the identity at 100%, so the grade moves on smoothly from the ungraded picture. At 100% the grading does not run at all, and the picture is the same as before.
  • Expanded puts SDR white at the peak, and the display's peak still limits it after the shoulder.
  • Native is fitted under the peak the game is told: the HDR peak row, which Hookshot passes to the game as its display's peak. In game, with an 800-nit row, the game's own light stayed at about 700 nits. Light the game puts above that peak is not limited by the pass, as at 100%: past the top the shoulder keeps rising, and there is no peak limit for Native. At 800 nits peak and 330 nits paper white, a 700-nit highlight goes to about 720 nits at 105% and about 780 nits at 150%.
• HDR contrast row (Graphics, with the other HDR rows, hidden with HDR off; row_shown takes it in the paper white / peak clause): 50–200% in steps of 5, default 100%, saved as hdr_contrast. Its help says the highlights ease into the peak brightness, and that Native is graded under the peak brightness the game is told.
• shaders/hdr_encode_comp_spv.h: glslang 16.6.0, with the source hash line as before.
• Tests: test_hdr_encode.py runs the shader's own grade()/shoulder() in Python, and also checks the push constants and the row.
  • Expanded: unchanged at 100%; rising from black at 50–200%; top exactly on the peak; at most 3% of the picture at the peak.
  • Native: the identity at 100%; every PQ code from 0 to 1 rising strictly at 50–200%, above the peak row too (nothing cut flat); the peak landing exactly on itself; light at or under the peak row staying at or under it. At 95% and 105%, the paper white and 0.9 of the peak stay within a fifth of the 100% picture.
  • The present fixtures take the new argument; test_upscaler_rows.py checks the row's visibility.

Testing: RTX 5080, 3840x2160 HDR10, 800 nits peak, 300 nits paper white, Expanded at 100% and 150% in a build of main (8c92fe3) with this series (screenshots, tone-mapped to SDR for this page). Before the shoulder, 150% clipped the highlights; that was found and fixed in game on the v2.0.13 build. Rebased directly on main d7a7306: it compiles with the build's clang. tests/run_all.py hdr_encode upscaler_rows present_aspect present_geometry present_source_crop upscale_independent menu pass (19), except present_aspect_vulkan. That one fails to compile the same way on main (its stubs predate the HDR pass), and #1942 fixes them.

In game after the review changes (a build of main d7a7306 with this series, Native, 800 nits peak row, 330 nits paper white): at 100% the game's own picture topped out at about 700 nits; at 150% the graded picture's brightest light was 784 nits, under the peak row, with the light shaft still graded rather than cut flat (screenshots). Expanded's math is unchanged.

Not tested: AMD/Intel, Linux, displays other than 800 nits.

Screenshots (Expanded, 800 nits peak, 300 nits paper white)

HDR contrast 100%	HDR contrast 150%

Native (800 nits peak, 330 nits paper white)

Native 100% (the game's own picture)	Native 150%

HDR10 captures, tone-mapped to SDR for this page (paper white to white, highlights rolled off up to 800 nits).

🤖 Generated with Claude Code

[ghost]

Thanks, the Expanded side of this looks right to me. I went through the shoulder: it meets the graded curve at the knee with slope 1, it rises for s above and below 1 (b(1+b) > 0 in both cases), and it lands exactly on the peak at grade(top). At 100% the contrast != 1.0 gate is exact, since 100 / 100.0f is exactly 1. Running the shader's own grade()/shoulder() in Python is a nice way to test this. The push constants (48 bytes, same order on both sides), the hdr_contrast ini key (clamped on load), the row's visibility and the stubbed fixtures all match, and the header's hash line matches the shader at this head.

The Native half is where I have questions:

• It only works with #1942. #1942 says Native is never actually taken on main (the cache's RGBA8/RGB10A2 aliasing means present_native_pq stays false), so on its own this PR can't grade the game's HDR, despite the title and the row's help text. Also, with Sharpness, the scaling filter or ultrawide's sides on, framegen_scale still writes the game's PQ codes into an RGBA8 scale.scaled, so the grade works on 8-bit PQ. Contrast above 100% will make that banding worse. #1942 fixes both. I'd land #1941 and #1942 together (or fold the Native part into #1942), and say so in the description.
• Native highlights above the HDR peak row get cut flat once contrast isn't 100% (inline). Details are on the line.

Nits: row_shown could fold hdr_contrast into the existing paper white / peak clause instead of adding a second one (the test string would follow). Exposure is pushed as a constant 1, which is fine, but it's dead weight until a row uses it.

CI hasn't run on this branch yet (no checks reported). It's 63 commits behind main but GitHub reports it mergeable. No other discussion on the PR so far. The Expanded path looks ready to me.

[ghost]

For Native, top is the HDR peak row, but the game's own picture isn't bounded by it. If the game puts light above pc.peak / pc.white, shoulder() takes the t >= 1 branch and the luminance limit below then clips it at the peak. With the row at 1000 nits and the game's highlights reaching 1500, everything from about 1000 to 1500 ends up flat at the peak as soon as contrast moves off 100%. At 100% the pass is skipped and those highlights show. That's the flat-cut highlights the shoulder was added to avoid, just on the Native side. Could Native use a top that covers what the game can output (the PQ ceiling, or the game's own peak setting if you can read it), or should the row's text at least say the peak row has to match the game's?

[j64esatxzdrhfg]

Changed. Native's grade is now fitted under the peak the game is told: the HDR peak row, which Hookshot passes to the game as its display's peak, and which the game's own light stays under (about 700 nits at most with an 800-nit row, in game).

• For mode 1 the shoulder's top and its target are both pc.peak / pc.white, the same as Expanded.
• There is no luminance peak limit after grading for Native. Light the game puts above the peak isn't limited by the pass, as at 100%: past the top the shoulder keeps rising, so it isn't cut flat. Only our grade is fitted under the peak.
• At 100% the shoulder is the identity, so the grade is continuous with the ungraded picture. At 800 nits peak and 330 nits paper white, a 700-nit highlight goes to about 720 nits at 105% and about 780 at 150%.
• Expanded is unchanged, with its peak limit after the shoulder.

test_hdr_encode.py runs the shader's grade()/shoulder() over every PQ code:

• the identity at 100%;
• strict rising at 50–200%, above the peak too;
• the peak landing exactly on itself;
• light at or under the peak row staying at or under it;
• at 95% and 105%, the paper white and 0.9 of the peak within a fifth of the 100% picture.

[ghost]

Thanks, fitting Native under the peak row and dropping the peak limit for it answers this; nothing gets cut flat by the pass any more.

One small thing left on the "as at 100%" part: past the top the shoulder continues with slope 1 in graded light, and in the game's light that's a slope of about contrast * grade(top) / top. At 800 nits peak and 330 paper white I get, for game light of 790 / 800 / 810 / 900 / 1000 nits: 798 / 800 / 855 / 1367 / 1967 at 150%, and 749 / 800 / 801 / 813 / 826 at 50%. So above the row the game's light is stretched about 5x at 150% (the display will clip it) and squashed at 50%, with a kink right at the peak. Since you saw the game stay well under the row, that's a nit, not a blocker. Continuing in ungraded light instead (top + (y - top) in the game's light once y > top) would make it really "as at 100%" there. This code is on main now (via #2342), so it would be a follow-up.

[ghost]

nit: (v != &opts.hdr_white && v != &opts.hdr_peak && v != &opts.hdr_contrast) || opts.hdr != 0 reads as one rule (update the string in test_upscaler_rows.py with it).

[j64esatxzdrhfg]

Done: (v != &opts.hdr_white && v != &opts.hdr_peak && v != &opts.hdr_contrast) || opts.hdr != 0. The string in test_upscaler_rows.py follows.

[j64esatxzdrhfg]

Thanks. This is now rebased directly onto main d7a7306; #1940's commit is gone, since its fix landed with #2038.

• Native's top: Native is now fitted under the peak the game is told, and light above it isn't limited by the pass (inline).
• row_shown: folded into the existing clause (inline).
• Lands with fix(hdr): Native HDR scaled in 10 bits and shown as the game made it at 100% contrast #1942: the description now says so, and why. Since main's 0a28ff2 gives RGB10A2 its own cache class, Native is taken on main. But with Sharpness, the scaling filter or the sides on, Native still reaches the pass through RGBA8 until fix(hdr): Native HDR scaled in 10 bits and shown as the game made it at 100% contrast #1942 scales it in 10 bits.
• Exposure: I've kept it as the constant 1 for now. fix(hdr): Native HDR scaled in 10 bits and shown as the game made it at 100% contrast #1942's 100% pass-through tests it alongside contrast. Happy to drop it until a row uses it if you prefer.

[ghost]

Re-review at 35f8125. Both of my earlier points are resolved:

• Native highlights above the peak row cut flat: fixed. Native's grade now uses the peak row as both its top and its target, and there's no peak limit after it for Native, so the pass no longer flattens anything. I left one nit in the thread: past the top, the game's light is stretched (150%) or squashed (50%) instead of left as it is.
• Only works together with #1942: answered. The description now says it lands with #1942, and why.
• Nits: row_shown is folded into the existing clause (fixed). Exposure is kept as the constant 1 (answered, fine by me).

I checked the rest again. The shader hash in the header matches the shader at this head. Push constants are 48 bytes on both sides. Expanded at 100% is unchanged: the gate skips the grade, and the new luminance limit can't fire there because the expansion already tops out at the peak. With HDR off nothing here runs, so SDR output is unchanged. No new option id (the row is saved under its hdr_contrast ini key), so nothing collides with main's or the open PRs' ids. Native at 100% still skips the pass in present_image.

However, this PR's whole change is already on main. #2342 was squash-merged today as a0dfd28, and it carried the whole stack (#1941, #1942, #2243). Every line this PR adds is on main, apart from the ones #1942/#2243 later changed. That's also why GitHub shows every file conflicting. So there's nothing left to merge here, and I think this PR (and probably #1942 and #2243 too, once you've checked) can be closed as landed via #2342. I'd have approved it otherwise. CI only ran the title check (passed).

[Joey-Magnus]

I think this can be closed: it reached main inside #2342 (a0dfd28, "FSR 4 for the game's native HDR"), which was stacked on #1941, #1942 and #2243 and squash-merged. I checked file by file against origin/main:

• This PR's vk_menu.cpp, vk_menu.h, present_source_crop_test.cpp and test_upscaler_rows.py changes are on main exactly. The HDR contrast row is at vk_menu.cpp:781, and hdr_contrast is in row_shown.
• The other files (hdr_encode.comp and its header, vk_framegen, vk_replay, the tests) don't reverse-apply only because #1942 changed them again on top. #1942's final versions of those files are on main exactly.

The conflicts GitHub shows are that history and nothing else: there's nothing left here to merge. Thanks for the work, it shipped.

[j64esatxzdrhfg]

Closing as landed: this reached main inside #2342's squash merge (a0dfd28), which was stacked on #1941, #1942 and #2243. Thanks @Joey-Magnus for checking it file by file, and @hckrman101 for the reviews. The last nit (Native light above the peak row continuing in ungraded light, top + (y - top)) I'll send as its own small follow-up.