Special K

Special K

Not enough ratings
HDR - The Big Book of Bright Ideas
By [SK] Kaldaien
Over multiple revisions, this guide aims to cover the entire subject of HDR as it pertains to Special K and some theory and terms we think are important and/or misunderstood by many users.

This is an extremely technical subject, and we want you to be as well educated on it as we can make you before your eyes roll into the back of your head and you stop absorbing information ;)

We'll try to hide the technical stuff somewhere in the middle where nobody will read it, but hope you'll stick around long enough to pick some of it up.
HDR Support Checklist
1. Windows 10
    A few games support HDR on Windows 7 and 8, but these games use NVIDIA’s NvAPI and AMD’s AGS supplemental driver libraries and the Special K development team highly discourages their use
      (if you are a developer, see the SK-Dev-Blog section below).

2. An HDR Capable Display
    There are many VESA HDR certified computer displays on the market, this simply means that they have a backlight that gets brighter than the standard 300 cd/m^2. Gamut is not a requirement for the first wave of certifications (thankfully the first wave of HDR games uses Rec 709 as its gamut), and there are no stringent requirements on localized luminance (meaning there’s not much distinguishing a display whose backlight makes the image 400 cd/m^2 everywhere from a display that can output 400 cd/m^2 in one corner of the screen and 200 cd/m^2 in a different corner).
    VESA HDR Certification is an okay place to start, but if you are after a real HDR experience, please do your best to find a local-dimming LCD display or an OLED. Other display technologies, even the ones carrying important sounding certifications, just will not give you an experience worth the hassle of setting all this stuff up. A slightly brighter backlight is not the same thing as a display designed to produce an image with isolated bright and dark regions; localized highs and lows are what HDR is all about, and most backlit LCDs are not capable of localized HDR. Since games are all about localized brightness for now and do not use wider color gamuts, an HDR display that cannot display multiple independent regions of high and low luminance will not do anything worthwhile in games.
Demystifying HDR Lexicon (by burying it in a wall of text)
Bpc (Bits-per-channel or Bits-per-color)
    Instead of the more common bpp (Bits-per-pixel) measure, HDR does away with the highly of describing the bit depth of all color channels combined and instead defines the precision of a single component.
EOTF (Electro-Optical-Transfer-Function)
    Gamma curve applied when displaying an image on a screen.
OETF (Opto-Electrical-Transfer-Function)
    Gamma curve applied when capturing light from a real-world source (i.e. through a camera) and encoding it for storage.
Color Gamut
    Defines reference (usually the purest version of a color producible) color points (i.e. primaries: red, green, blue; white; secondaries: yellow, magenta, cyan).
      A gamut is considered wide if it can saturate the primary colors beyond those defined using the most common SDR gamut: Rec.709
    The classical definition of a colorspace is a gamma function and color gamut, many graphics APIs have taken to define minimum color bitdepth and encoding format (i.e. fixed- or floating-point).Games rarely use the term colorspace correctly, often they are simply referring to gamma. No game on the market (in 2019) intentionally uses a color gamut wider than Rec. 709.
    Lazy-man’s way of writing 1 cd/m^2; a measure of Luminous Flux (candela) projected through a Unit Area (sq. meter). In other words, light energy passing through a unit area. The rest of the world calls this distributed flux by something simpler like luminance or brightness.
    (See nits, and then make a point of changing nits to cd/m^2 before assigning units for luminance in writing, because nits is silly and cd/m^2 immediately makes you appear more informed :P)
Perceptual Quantization (Sometimes called SMPTE2084)
    New gamma transfer function. This equation is shared by both Dolby Vision and HDR10 and includes min/max luminance as an input to perform gamma with fewer artifacts such as banding seen in previous EOTF equations such as power-law or sRGB

Characterizing Color Gamuts
    Many people may have seen or even described gamuts as a palette of colors covered by a triangular area on a CIE Chromaticity Chart. While the classical view based on CIE charts does—partially—describe a gamut, that description is incomplete. CIE chart coverage describes, across a display's entire luminance range, all possible colors.
    In reality, certain colors are only producible within narrow bands of luminance and you are looking at a top-down view of 3D data whenever you speak of gamut coverage using a CIE chart. The chart produces valid coverage maps whether we ignore luminance or not, but is a special case where luminance does not matter rather than a proper discussion of display's gamut.
    A gamut, when properly visualized is 3D and for each chromaticity, the gamut has a different range of luminance where the display can produce that color. HDR, as it pertains to gaming, is concerned entirely with the seldom pictured luminance range (height) of a gamut rather than the color range (width) everyone focuses on. You cannot appreciate what HDR actually is if you continue to picture gamuts using 2D coverage triangles.
    A gamut that can saturate (produce a purer version of) primary colors beyond the primary color points defined in Rec. 709
    Not widely used, but growing in popularity, to describe colorspaces that support luminance levels beyond SDR's reference white (usually defined between 80 and 200 cd/m^2).
    The end-goal of HDR; allows wider range of luminance and more saturated colors.

    Nobody describes an HDR gamut as “Wide & Tall” in casual conversation, and video game HDR would not qualify as "Wide & Tall" even if this were a more common phrase. Game HDR relies solely on a tall gamut (large luminance range) and does not ship art content mastered using anything wider than Rec 709.

    As of 2019, "Wide & Tall" characterizes HDR cinema, but not a whole lot else.
Retrofitting HDR into a D3D11 Game
Enabling HDR in a D3D11 game that does not normally support it

  1. Set the desktop to run in HDR mode, ideally you should ensure a minimum of 10bpc for the color format and if your driver lets you have it, use RGB or YCbCr 4:4:4 whenever possible.

      The absolute last thing you want is a driver forcing you to perform YCbCr 4:2:0, if you see this, try using 8-bpc HDR instead. This is not a normal pixel depth for HDR, but Windows can dither an 8-bpc image with higher quality than YCbCr 4:2:0 would give you.

  2. Launch the game, and configure it to run in borderless window mode

  3. Open Special K’s HDR widget, select scRGB and restart the game.

      Most games (not using Unity) will now be running a 16-bit Floating-point Framebuffer in windowed mode, and Special K’s control panel will include (HDR)

  4. Once running in HDR mode, use the HDR menu in Special K’s control panel to adjust the luminance of Special K’s UI as well as the Steam overlay.

  5. After setting SK’s UI to a comfortable luminance level, you can tweak the game’s luminance in the HDR widget.

    • To avoid clipping extremely bright details, it is suggested you DO NOT enable Full Luminance Range and instead work with the default slider limits for peak white.

    • To emphasize SDR brightness range objects and HDR highlights, you can apply a secondary gamma (power-law) equation for SDR content. This has the effect of moving the minimum brightness an object is required to have before it qualifies for HDR processing.
Manually Defining Pixel Format
[SK-Dev-Blog] — Vendor-Specific HDR APIs — Obsolete and Avoidable
Building the Case Against NvAPI and AGS-based HDR
    During the development of Special K’s HDR systems, we watched multiple games that shipped using the proprietary NvAPI / AGS HDR solutions work “acceptably” at launch and gradually break over time with driver updates. Special K has decided to avoid the proprietary libraries (whose primary appeal is compatibility with other platforms and versions of Windows older than 10) and use only the official DXGI-based HDR support introduced in Windows 10 for D3D11 and 12.

Reasons NvAPI and AGS-based HDR were once relevant
    They were stopgaps before Windows 10 had official HDR support, they also enabled HDR in Windows 7 and Windows 8 for developers who had not yet gotten the memo that they are crippling their games by trying to support anything more advanced than “barely functional” on Windows 7.

Reasons NvAPI and AGS-based HDR are no longer relevant
    It is true that NvAPI and AGS expose Dolby Vision, along with its dynamic metadata per-frame. However, this was experimented with by a few games and then the entire industry moved to HDR10 with static metadata. You will not be the developer who finally finds a novel use for dynamic metadata and you should not be clinging to the last remaining benefit the vendor APIs have to offer. Even display devices have next to no incentive to pay a premium for Dolby Vision support, it is not a technology with a long life ahead of it.
    DXGI has already laid the groundwork for HDR10+ and by the time anyone actually finds a good use for dynamic metadata in games, HDR10+ support will be standard in OS and on display hardware.

    We would really like to see new games stop shipping with NvAPI or AGS codepaths for HDR.
      If you are authoring a port and you still have a chance to go with straight DXGI, do it!
        Don't think twice about it, either.
    We have seen too many games using the proprietary API paths cease to work within a few months of launch and it is not a good idea to maintain separate codepaths for each vendor when the OS has perfectly functional vendor agnostic APIs on tap.
    There is no good reason to use NvAPI or AGS, and a million reasons to use DXGI.