Twist on 8/12/2023 at 01:24
Quote Posted by Kerrle
Yeah, SpecialK does allow for HDR, though it isn't a tailored experience the same way a native implementation would be.
While it would be impossible to match what a good developer could achieve with native implementation, it appears to me that SK's HDR Calibration options provide a ton of flexibility. You can create custom configurations to load with different games. In particular, the "Pipeline Remastering" option could be especially useful for achieving as close to a tailored experience as possible:
Quote:
Pipeline remastering is a feature of Special K's HDR retrofit that increases the range and precision of intermediate render passes to infuse/preserve HDR qualities early in the render pipeline rather than try to produce an HDR image using a game's final output alone (i.e. Xbox Auto-HDR).
Remastered passes include things like atmospheric scattering, HDR (pre-tonemap) light accumulation, and (unfortunately) shadow maps and FMVs. Not all passes work as intended when their range and precision are increased, and the performance cost of upgrading these render passes varies from game to game.
Special K has disabled all of the render pass remastering options by default, since they were the source of many compatibility issues.
However, remastering is important for image quality and, in some games, even required for the UI.
You are encouraged to enable these yourself, they just cannot be the default policy or support requests from first-time users would never end.
I figure using SK's HDR Calibration (with Pipeline Remastering, if possible), accommodating for the HDR by changing some NewDark settings (as you illustrated), and maybe even trying a little ReShade* (such as a UI Mask), we should be able to get a pretty good result.
*I don't know about the ReShade aspect. Using 3rd party post-processing to artificially compensate for non-native HDR could get janky. But I'd still experiment with it.
Quote Posted by Kerrle
That's the one. So, the simple fact is MS has left Cleartype to rot on the vine and it no longer really supports tweaking at all - it sucks at subpixel rendering for basically any non-RGB subpixel layout, including things like monitors in portrait mode.
Have you tried this replace-ClearType-with-MacType fix?
(
https://www.reddit.com/r/Monitors/comments/w9qm0y/actual_fix_for_the_aw3423dw_subpixel_layouttext/) Actual fix for the AW3423DW sub-pixel layout/text fringing
(Although maybe it bothers you so little it wouldn't be worth the effort.)
Quote:
But in practice, it isn't something I even notice, even knowing what to look for... It's possible you'd be more sensitive to it than I am, but I personally think it's overblown.
Thank you for the picture -- that helps! I figured it probably wouldn't really bother me. And I can always try the MacType fix if it does. Given all the praise the monitor receives, I kind of guessed (or hoped) all its positives would more than compensate for some minor text fringing. Your praise earlier in this thread is the kind of thing I've heard or read all over the place:
Quote Posted by Kerrle
It's been fantastic - I can honestly say it's the best display I've ever seen. Pure blacks, damn near painfully bright HDR highlights in games like Ori.
Kerrle on 8/12/2023 at 02:23
I'm exclusively on Linux the past six months or so, so I haven't messed with mactype. I've heard it's good even for other monitors, though.
But yeah, I mean it when I say it just isn't even notable to me in Windows unless I purposely look for it. I was running Windows for most of the year after I got it.
Skol on 8/12/2023 at 03:57
Quote:
Special K’s HDR retrofit that increases the range and precision of intermediate render passes to infuse/preserve HDR qualities
lol?
Kerrle on 8/12/2023 at 04:57
What's the LOL for? It's a real thing. Heck, that's basically what the 32-bit color setting in cam_mod is doing.
Skol on 8/12/2023 at 11:45
Quote:
that's basically what the 32-bit color setting in cam_mod is doing.
No it's not. That's color
precision - we have more values with which to represent colors, between (0.0, 0.0, 0.0) and (1.0, 1.0, 1.0). What we
don't have is, say, (1.2, 1.0, 1.0). Regular monitors will still display that as pure white, but at least it retains the notion that red is contributing more than blue and green, which is important information for some shaders; it's in this context where "HDR" matters most (most current renderers are HDR, but it's not and never was primarily for the benefit of HDR monitors). Now HDR monitors can take the value (1.2, 1.0, 1.0) and it'll be brighter than (1.0, 1.0, 1.0).
But the GPU needs to send it that value in the first place, which Dark is not capable of doing. Remember: Dark's DX6 renderer is rudely hacked onto the ass-end of a software renderer. That the renderer is currently DX9 doesn't tell us much of anything, and it's unlikely that anything was rewritten prior to those DX9 calls just to accommodate HDR. In all likelihood, the GPU never even gets a whiff of anything above #FFFFFF.
Hence my lol: They can't be preserving HDR values, because the GPU never sees them to begin with. So what do they mean by "infuse" HDR "qualities"? It reminds me of that old Sound Blaster crystallizer feature that claimed to upsample audio. Like... how? You can't introduce things that aren't there to begin with.
Kerrle on 8/12/2023 at 15:31
With DLL injection it can literally change the render pipeline. It's not just applying stuff to the final output.
And the quote you were loling was explicitly about color precision, so I don't even know what your initial comment is on about.
Kerrle on 8/12/2023 at 16:49
And sorry if that came across combative. It's entirely possible that the technique can't work with Thief; they're very up front about it only working with some very common methods in DX9 class games, so your comment about Thief being based on an old software renderer may be totally valid.
But after poking around it does clearly work with some old games in a very real way.
Also, I think you may be making an error in how you think about HDR. Nothing stops you from representing an HDR scene with just 8-bit color - the value of FFFFFF doesn't have to be any specific brightness, it's just that as you increase the represented range you'll get banding. That's why increased color precision is important. What you're doing in your explanation is akin to Spinal Tap's "this goes to 11" - we can just make 10 louder, instead.
The bloom that newdark implements can be thought of as an early way to "fake" some of the effects of HDR. If you had increased internal color precision, nothing would prevent you from replacing that step with a tonemapping step that used a cutoff or curve to figure out which brightness values were supposed to represent emissive lights like streetlights and increase their brightness in an HDR space. It wouldn't be as good as an artist-authored HDR - it would require a lot of tweaking to get fire and less intense lights right - but it would work.
And on that note, those of you that are trying this should probably disable bloom if you had it on.
