Add HDR to Metal + Perceptual HDR

[Sam-Belliveau]

This PR:

1. Add HDR to Metal
2. Add PerceptualHDR

PerceptualHDR Menu:

[MayImilae]

Likely not ready to be merged unless it shows some huge advantage as it just removes a feature atm.

You should probably mark this PR as draft then.

[Filoppi]

Overall I find this PR to have more negatives than positives at the moment.
I don't like most of the code restructuring, I find it unnecessary (because it's working, and syntax doesn't matter as much) and detrimental (because it adds more problems and removes comments and code that made the shader easier to read).
To my eyes, it looks like "random" changes to refactor it in your style, instead of my style. Not saying any of the two styles is better, but that's exactly the point, these are just stylistic changes, I don't see this PR as making the code more readable to everybody, I feel like it might just be more readable to you :D.

I'm not against spacing changes, so if you want to make a PR for that, feel free to do so.

Scaling brightness by oklab in HDR isn't really wanted here.
The original idea of blending texture samples with oklab could have been elaborated more into something better though, as long as we can get the most physically accurate (which is a bit different than perceptually accurate) color mixing.

That said, I don't want to be rude, I appreciate the attempt. Let's build something from this.

[Filoppi]

Please just implement this as a post process, just like AutoHDR.glsl that's where it belongs with the way things are designed.
You are applying a subjective SDR to HDR upgrade, and that should not be part of the default feature set of "color correction", as it's something "random", based on taste.

[Sam-Belliveau]

I really disagree with the idea that this is something random based on taste. I showed before my exact derivation, reasoning, and verification that it is not distorting the underlying picture.

I explained exactly the problem it's solving. (dark colors becoming over exposed) I explain the requirements for an algorithm to resolve it, and I picked the single function that exists that solves this problem. There are no tunable parameters for the perceptual mode, because only one solution exists.

It fits the requirements for HDR Paper Nits. White is the exact same as in the Linear mode. Great lengths were made on my end to make sure this was more than just a random feature.

It was part of a larger effort undertaken to clean up this default post process shader. This is more than just a post process function, this is an entirely valid, mathematically backed way to scale SDR to HDR given certain constraints.

This is the form that I believe this feature should be in, because it's simple and offers substantive improvements. It would take extra work for me to go through my refactor and undo all and make it only support a single form of HDR Scaling.

I'd be willing to consider a post process effect in the future but this is the state of this project right now.

[iwubcode]

I am not as passionate as either of you about color output, HDR, or gamma. Regardless, I will give some general thoughts /opinions.

Maybe @Filoppi can remind me, why is HDR Paper White Nits even an option for the color spaces? To me it seems like an odd option to have in a color correction window about the original GC/Wii. From what I recall, you said that the HDR range was needed to show those color spaces. Can we not determine the appropriate white balance for those original spaces?

Even calling this window "color correction" gives off the wrong expectations. This window isn't about color correction or HDR, that is a post process function. Therefore I would lean toward not including anything that isn't related to our original goal (console accuracy) in this window. (Additionally, I'd like to avoid making this window too large)

Also, while it is great we cleaned the shader up, I don't think we should get too attached to our current shader setup for post processing. I can't make any promises but I'd like to rework shader management in the future (may or may not be a part of post processing enhancement).

Having done a number of ports of Reshade shaders and also worked on a number of custom shaders with my new material system, it's apparent that our current approach doesn't scale very well. Our global functions are difficult to find without reading through a lot of source and users get everything we put in global state when they implement their own shader. We really need some common code approach that I'll call a "library".

Sorry this was a long amount of text. I'll give it some more thought but my initial impression is that OkLab would be good to include in a Dolphin provided "library" but the perceptual color conversion makes more sense in a post processing shader that the user can opt-in to use.

[iwubcode]

Shader part LGTM.

[Filoppi]

Other than the few comments left, code looks good now. Thanks for making this a post process shader.

[TellowKrinkle]

Metal part LGTM
(Though I'd prefer if the Metal changes were in a separate commit from the PerceptualHDR shader)