Topic-Free Mega Thread - v 1.11.2020

HDR10 ace is messed up no matters the settings like in the screens I posted, only Ace give me good colors

For the purpose of monitors? I don’t think PQ is any different between one display and another, just the input max luminance.

Parameterized, PQ is simply this

float3 ApplyREC2084Curve (float3 L, float maxLuminance)
{
  float m1 = 2610.0 / 4096.0 / 4;
  float m2 = 2523.0 / 4096.0 * 128;
  float c1 = 3424.0 / 4096.0;
  float c2 = 2413.0 / 4096.0 * 32;
  float c3 = 2392.0 / 4096.0 * 32;

  float maxLuminanceScale = maxLuminance / 10000.0f;
  L *= maxLuminanceScale;

  float3 Lp = pow (L, m1);

  return pow ((c1 + c2 * Lp) / (1 + c3 * Lp), m2);
}

That’s really all there is to it, input source image is either Linear or sRGB (using Rec 709 primaries) when dealing with SDR and then when rendering into an HDR target, the output is either Linear or PQ (using either Rec 709 primaries or Rec 2020 respectively).

Anything outside the scope of what goes into or comes out of a pixel shader is hidden from developers, and we are very thankful for that :slight_smile:

Technically, DXGI has a LUT that handles gamma, which is more than 99.9% of game developers know about or have any use for.

Using gamma correction

I am fairly certain that does not work at all in HDR. NVIDIA’s own API describes the display format as “pass-through,” where it is expected to use PQ to encode the signal range to 10K nits using Rec 2020 color primaries. Any kind of additional gamma interference would invalidate this.

Hmm I wonder why LG OLED’s does its PQ processing at 2.2 then according to the calibration experts i talked to at avsforum, if initial gamma doesn’t matter for a PQ curve, most likely LG/OLED doesn’t have a native PQ curve, and does some display side processing trickery.

I am discouraging the use of gamma as a means of balancing the image, I have come to terms with the fact that I’m probably never going to get the game’s HUD and the rest of the game scene processed independently and as such, applying a gamma curve is too destructive to the entire image. There’s really only one gamma value that will keep a game’s UI from drifting off into noticeably wrong colors.

That is why the middle-gray option is front and center where gamma used to be, it can be used to dial-in some additional tweaks for elements of the image that need the original SDR properties.

Do be aware, middle-gray is defined by your peak luminance, so you have to calibrate that first.


The entire process of handling LDR → HDR using gamma is wrong. Gamma operates on all ranges of the image the same way, HDR is supposed to have fine-grained control for low/mid/high-tones because entirely different aspects of a game’s image occupy these different ranges and they should not all be getting the same treatment if we want to call this HDR and not simply “make the image brighter mode” :slight_smile:

=====
Also, which version of Special K are you testing here? I applied a pretty significant gain to the ACES tonemap that should normalize the black level and eliminate (some of) the issues you are complaining about.

The ACES filmic tonemap is deliberately being used because it segments the low tones (where a game’s HUD is likely to be) in a much less aggressively curved response region and the increase in representable range is distributed mostly in the high-range. This is how HDR is supposed to work, stuff is going to get “contrasty,” but it has to or there would be no expansion in range.

Your goal should be to get the game’s UI balanced into the low-contrast part of this discussion and let the HDR characteristics emerge for highlights only. That does mean part of the image will be drab and other parts punchy, but that’s exactly what any true HDR game does.

You should not even need to tweak most of this, I’ve found the appropriate neutral point for games using standard gamma. You just need to set the peak luminance slider and verify the range of output is not going higher than display limits.

HDR10 ACES is only for games that are already HDR. There are huge differences in the way color is encoded in HDR10 and the format that SK uses for HDR, so these aren’t even comparable. There’s only one correct tonemap choice for a game and it is determined by the game’s HDR/SDR mode.

SDR = Passthrough or ACEScg
HDR = Passthrough (use for scRGB HDR games), HDR10 Passthrough (not recommended) or HDR10 ACES

Is SpecialK32.7z updated? It was built on the 28th, and not the 30th as the 64-bit DLL file.

You can try SpecialK32.7z (6.3 MB)

Thanks – that one is dated today. :+1:

Anyone else having issues with a ton of processes locking the specialk64.dll file each time they update, everything from explorer.exe to smartscreen.exe to sometimes even discord preventing overwriting?

  • Do you have global injection running when you try and replace the files?
  • And might you be running the injector as an elevated process (running as admin)
  • How does your whitelist look like? Documents\My Mods\Special K\Global\whitelist.ini

When you disable/stop the global injection service a signal should be sent to all processes ejecting Special K’s DLL files from them.

That’s normal, injection performance would be terrible if I immediately unloaded SK from software when it finds an app that it’s not supposed to be injected into.

If the DLL is locked and the service shutdown is not getting the apps to release it, you can just rename the DLL and eventually it won’t matter. Rename the locked SpecialK{32|64}.dll to something like _SpecialK{32|64}.dll, then extract the replacement and start Global Injection again.

You can delete those renamed DLLs whenever they become unlocked (might take a full system reboot).

It does eject the 32 bit one fine but for some reason it can’t eject the 64bit one without a full pc restart.

On another note kaldaien is it actually possible to fix games that has broken gamma correction when framebuffer is changed from UNORM_SRGB, or is that something only the developers can do?

hhmm something is wrong on my end. every hdr option no matter the settings makes the sky white, previous sk version worked flawlessly

This is how it looks with version posted in new hdr calibration guide

Will this version fix the massive FPS drop I got in WDL when using HDR mode from SK?

There is no SDR slider anymore. If you change this setting, you will be changing middle-gray contrast, not SDR level.

The game’s own HDR is probably enabled now. SK no longer disables a game’s HDR, which is the entire reason the HDR10 tonemaps exist.

If the game’s HDR is enabled, then set the values on the HDR widget to the defaults and go configure HDR in the game’s built-in menu. You can make small adjustments using SK later.

Kaldaien in benchmark FPS drops by a good 10 or 20 fps depending on area in benchmark. Barely holding decent fps in WDL.

Nothing will change

Damn. SO WDL is bad HDR anyways. I was hoping to fix it. But with SK it comes with great fps drop. Without SK its not bad at all. But HDR in my game looks grey as ■■■■ and dull beyond reason. WDL.

Edit:
Interesting. I edited some stuff for HDR Passthrough for WDL and that seemed to do the best out of all other options with HDR mode turned on ingame. Was able to tweak the gamma and lowered Brightness to 155 and now game looks fantastic. And FPS isn’t doing crap anymore.

Uhh okay new problem in WDL. Weirdest thing I seen. The noise level is thru the roof in the game.

This is Gamebar Screenshot but not the jxr screenshot.