HDR WTF ??

[starshipcommand]

But, as Dio says, a lot of games are no doubt doing what I'm calling "internal HDR". That they render it all to a floating-point texture (that can hold really big and small values). Then you've got a "tone map" equation in your pixel shader that takes the floating-point and converts it to something the display can display.

This is useful, even when the target display isn't HDR, because you're basically avoiding clipping.

[...]

There's a wide range of brightnesses in the real world, which 0-255 with RGB can't represent. So you work it all out in floating-point and then have a pixel shader do a floating-point to RGB8 thing for you at the final stage.

The neat thing is, that you can use this in order to get a higher dynamic range output out of a lot of games, even if they (or your display) don't officially "support" HDR as a feature. Crank your monitor's output really bright, then turn the in-game brightness down to compensate. It doesn't work for all games (for some it looks a bit weird), but for others it makes them really pop. Tried this with GTA5, Far Cry 2/3 (Far Cry 2 looks amazing for its age), Sleeping Dogs, etc with great results.

[Little stoned kiwi]

Wouldn't that decrease the dynamic range?
Not saying you're wrong about liking the end result and will try it myself. From the language you used you're doing this on PC?

[Dio]

Increased range, decreased precision.

[starshipcommand]

Increased range, decreased precision.

Yep, exactly. There is a possibility of banding at the darker end if you take it too far; but you're in control of the sliders, so you can dial in how dynamic you want it to be. (And yes, I'm doing this on PC)

[Little stoned kiwi]

Ah, chur!

[gilesgoat]

OK, OPENING ALL THIS AGAIN

"This time let's say almos for real".

This is mostly "questions for Dio" but practically "for whoever can answer".

1. WHAT THE HECK means when a monitor declares to be "HDR capable" ?

2. "as far as I practically know", when you create a "framebuffer/rendertarget/display" NORMALLY you have only 2 choices : LINEAR R8G8B8A8 OR SRGB R8G8B8A8

3. difference between the two "numerically approximate" is that F_LinearToLinear(X) = X and F_LinearToSRGB(x) = approx POW(x, 1.0/2.2)

4. SRGB is to say "there's too little perceptual difference between 0 and something and between 1-something and 1" there's a waste of bits let's space things a bit different so it's a non-linear scale that looks better

Now HDR if I understood says "o from 0 to 255 there's too little resolution" and/or "I see an image that is too white/too dark if I'd have more greys/black/whites/etc. would look diffferent".

So in theory let's say that if instead of from 0 to 255 you'd have from 0 to 1024 you'd see more detail ?"

Anyway let's say again 0 is my black 1.0 is my "super white" .. then I am in FLOATING POINT, all floating point R32G32B32A32 yes you can do 32 bits FP per channel.

Ok and now I have the HDR capable monitor .. "in a perfect world" I'd say "get those FP values do dunno what but display nice".

Except that seems is NOT the way it worse "the coder has to do the magic" .. WHAT MAGIC ???! And WHAT MEANS THE MONITOR IS HDR CAPABLE ??

And why it appears ( to me ) that when you say HDR you immediately hear R10G10B10A2 .. .ok "what magic formula you use between floating point and that ?".

Is there a STANDARD, if 1010102 is "the standard" there should be "one formula for all" ??

How the heck it works then ?

[gilesgoat]

Someone pointed me to this long article that I am reading : https://www.lightillusion.com/what_is_hdr.html

[Little stoned kiwi]

It's all above my paygrade but I'm curious to learn more. Until someone better comes along this may help:
https://learn.microsoft.com/en-us/windo ... amic-range
It talks about two options for setting up the swapchain after you've determined the display supports HDR:

Option 1. Use FP16 pixel format and scRGB color space.
"We recommend that general-purpose apps use Option 1. It's the only option that works for all types of Advanced Color displays, content, and rendering APIs."
This uses 64-bits per pixel so consumes more GPU and memory bandwidth.

Option 2: Use UINT10/RGB10 pixel format and HDR10/BT.2100 color space
"Option 2 is a performance optimization that's available only if your app meets all of the following conditions:

- Targets an HDR display
- Uses Direct3D 12 or Direct3D 11
- Swap chain doesn't require blending with alpha/transparency
If your app doesn't meet all of those conditions, then you must use Option 1."

Then there's information on using the Advanced Color swapchain when the display is in SDR mode. I assume that requires Option 1 since Option 2 requires that you are targeting and HDR screen.
I also assume you'd want to do this to avoid duplication of code for working with two different colorspaces (SDR/HDR).

Not an actual graphics developer, not actual graphics advice.

[Little stoned kiwi]

???! And WHAT MEANS THE MONITOR IS HDR CAPABLE ??

There's a snippet of sample code on the linked page that gets the display the app is being rendered to then works out if HDR is supported from the colorspace:

Code: Select all

// Retrieve the current default adapter.
ComPtr<IDXGIAdapter1> dxgiAdapter;
ThrowIfFailed(m_dxgiFactory->EnumAdapters1(0, &dxgiAdapter));

// Iterate through the DXGI outputs associated with the DXGI adapter,
// and find the output whose bounds have the greatest overlap with the
// app window (i.e. the output for which the intersection area is the
// greatest).

UINT i = 0;
ComPtr<IDXGIOutput> currentOutput;
ComPtr<IDXGIOutput> bestOutput;
float bestIntersectArea = -1;

while (dxgiAdapter->EnumOutputs(i, &currentOutput) != DXGI_ERROR_NOT_FOUND)
{
    // Get the retangle bounds of the app window
    int ax1 = m_windowBounds.left;
    int ay1 = m_windowBounds.top;
    int ax2 = m_windowBounds.right;
    int ay2 = m_windowBounds.bottom;

    // Get the rectangle bounds of current output
    DXGI_OUTPUT_DESC desc;
    ThrowIfFailed(currentOutput->GetDesc(&desc));
    RECT r = desc.DesktopCoordinates;
    int bx1 = r.left;
    int by1 = r.top;
    int bx2 = r.right;
    int by2 = r.bottom;

    // Compute the intersection
    int intersectArea = ComputeIntersectionArea(ax1, ay1, ax2, ay2, bx1, by1, bx2, by2);
    if (intersectArea > bestIntersectArea)
    {
        bestOutput = currentOutput;
        bestIntersectArea = static_cast<float>(intersectArea);
    }

    i++;
}

// Having determined the output (display) upon which the app is primarily being 
// rendered, retrieve the HDR capabilities of that display by checking the color space.
ComPtr<IDXGIOutput6> output6;
ThrowIfFailed(bestOutput.As(&output6));

DXGI_OUTPUT_DESC1 desc1;
ThrowIfFailed(output6->GetDesc1(&desc1));

[KlaxonCow]

Now? something lossless. I'm aware of PNG and GIF, there may well be something better by now.

These days, WEBP is the latest shizzle.

https://en.wikipedia.org/wiki/WebP

Because, basically, it has unified it all. There's a "lossy" dial with WEBP that means you can turn it all the way down to "lossless" and then it's like a PNG. Or you can turn up the "lossy" to get better compression, JPEG-style. Or, of course, in-between values to exactly choose your trade-off and compromise level.

And it can contain multiple frames for animations, like a GIF.

Plus, the headline that it just has better compression than both PNG and JPEG, when like-for-like benchmarked against each other.

It's a Google-developed format, but all the major browsers now support it, and it lives inside a standard RIFF container (which is a simple "chunked" format that has its origins all the way back with the Amiga).

They're even working on a WEBP2, to try to bring the compression ratios up to the level of the AV1 video codec (or AVIF format, which is just the AV1 codec applied to a single frame image).

Here's a sample image and the file size comparisons:



Like, it beats PNG at lossless compression anyway, but you can potentially turn up the "lossy" dial just a little to get better compression for no perceptible difference.

And it similarly beats JPEG at its own "lossy" game as well:



And, against GIF, for animations:



Basically, it can do what the other formats can do, but with a better compression algorithm behind it. Leading to the conclusion that, other than support for it (though all major browsers and most art programs now have it), WEBP should probably just be used for everything now.

The logo wasn't line art, it was a circle of one colour on a background of another colour, there were probably some words or letters, but I remember the circle. Or that's what it should have been, but it was a JPEG.

To be clear, I mean "line art" as a general term for geometric, as opposed to photographic, art. It doesn't literally have to feature only lines.

Stuff what would be better as an SVG, basically.

Which brings us to:

SVG IS ONE OF THE CRAPPEST FORMATS I EVER SEEN TO PARSE/TRY TO WORK WITH !

Horses for courses.

The point with SVG is that it's vector graphics, not bitmapped. It works differently.

With all these formats, there is no universal "best format" - though, you know, the WEBP mentioned above is trying its darnedest to be as one-size-fits-all as possible, in the bitmapped arena - but it's about using the format that suits what you need to do.

SVG is actually really good for web development. Can be scaled to any size and never loses its sharpness. XML-based format that can be embedded directly into a web page. You can even manipulate it with CSS. Vector graphics for simple "line art" stuff uses way less bytes.

Indeed, I created an SVG with JavaScript inside of it that animates it all. Mere bytes, perfect sharpness, can be "tweened" to any frame rate and all stuffed into a single file. In the right places, it's fucking brilliant.

But, if you're not making websites, then why are you using SVG? It's terrible for nearly everything else, exactly because it really is highly "specialised" for being used on the web (XML-based, CSS manipulation, etc. but, equally, in the other direction, a text-based graphics format?!?).

(Sorry, should have answered these ones at the time, but was distracted elsewhere and was only reminded just now.)

[gilesgoat]

TO KlaxoCow about SVG !

You are TOTALLY MISSING MY POINT HERE !

Yes SVG is vector, yes SVG is cool .. SO POSTSCRIPT !

What I am saying "the way the SVG file/syntax/format is designed" is UTTER CRAP to parse/work/deal with !

I am NOT talking about "the visual results of it", that of course are "nice vector graphics", I am talking about how the file is organized and the data is put in.

OR IN MORE PLAIN WORDS : TRY TO WRITE A CPP PROGRAM TO READ IT/USE IT/TRANSFORM IT into something else, IT'S A MASSIVE PAIN IN THE ARSE BECAUSE THE FILE FORMAT IS *CRAP* !!

More clear now ?

[gilesgoat]

???! And WHAT MEANS THE MONITOR IS HDR CAPABLE ??

There's a snippet of sample code on the linked page that gets the display the app is being rendered to then works out if HDR is supported from the colorspace:

Code: Select all

// Retrieve the current default adapter.
ComPtr<IDXGIAdapter1> dxgiAdapter;
ThrowIfFailed(m_dxgiFactory->EnumAdapters1(0, &dxgiAdapter));

// Iterate through the DXGI outputs associated with the DXGI adapter,
// and find the output whose bounds have the greatest overlap with the
// app window (i.e. the output for which the intersection area is the
// greatest).

UINT i = 0;
ComPtr<IDXGIOutput> currentOutput;
ComPtr<IDXGIOutput> bestOutput;
float bestIntersectArea = -1;

while (dxgiAdapter->EnumOutputs(i, &currentOutput) != DXGI_ERROR_NOT_FOUND)
{
    // Get the retangle bounds of the app window
    int ax1 = m_windowBounds.left;
    int ay1 = m_windowBounds.top;
    int ax2 = m_windowBounds.right;
    int ay2 = m_windowBounds.bottom;

    // Get the rectangle bounds of current output
    DXGI_OUTPUT_DESC desc;
    ThrowIfFailed(currentOutput->GetDesc(&desc));
    RECT r = desc.DesktopCoordinates;
    int bx1 = r.left;
    int by1 = r.top;
    int bx2 = r.right;
    int by2 = r.bottom;

    // Compute the intersection
    int intersectArea = ComputeIntersectionArea(ax1, ay1, ax2, ay2, bx1, by1, bx2, by2);
    if (intersectArea > bestIntersectArea)
    {
        bestOutput = currentOutput;
        bestIntersectArea = static_cast<float>(intersectArea);
    }

    i++;
}

// Having determined the output (display) upon which the app is primarily being 
// rendered, retrieve the HDR capabilities of that display by checking the color space.
ComPtr<IDXGIOutput6> output6;
ThrowIfFailed(bestOutput.As(&output6));

DXGI_OUTPUT_DESC1 desc1;
ThrowIfFailed(output6->GetDesc1(&desc1));

Sorry to say but "have you even just looked what this code actually does ?" ..

It "just misses ALL the parts where it understands/does anything about/with HDR" ...

"Do people actually READ code ??"

[Little stoned kiwi]

Go fuck yourself, Giles.

[KlaxonCow]

What I am saying "the way the SVG file/syntax/format is designed" is UTTER CRAP to parse/work/deal with !

It's XML.

There are plenty of libraries available, for all languages, to parse and manipulate XML.

(Because, like, it's the foundation of HTML and other web stuff, so this is a solved problem more than a dozen times over.)

[gilesgoat]

Go fuck yourself, Giles.

I'll try but I am not sure I can, I am NOT so flexible

Sorry if I made you mad, that wasn't the intention, take it easy, it's only coding ! Sorry !