It depends on whether you want to use HDR or not. As ReShade still doesn’t have proper support for HDR it’s no real use of using Special K HDR + ReShade alongside on another.
Beyond that, it’s usually just a matter of Special K and ReShade using different injection methods – e.g. d3d11.dll for ReShade and dxgi.dll for Special K.
Was just about to edit my post (done now) that I really want to be able to use SK_HDR too!
So in a nutshell, it’s not possible to use SK HDR with Reshade at the same time?
ReShade does not support the HDR format that Special K makes use of, which means that a loss of details and whatnot will most likely result.
I don’t use ReShade myself – I only know that due to limitations on ReShade’s end, it’s not really worth combining the two.
Crosire is making few updates to upcoming releases of ReShade that will allow me to plug-in HDR support dirrectly from Special K. Until then, I’d just avoid ReShade.
Ok thanks Kal and Aemony. Hope this can work in the near future then, it’s a tweakers dream to be able to use SK HDR and reshade together for me.
Hmm… I wonder if not ReShade’s various individual shaders also need to be updated to a higher format to fully support HDR as well… Otherwise I imagine that applying certain post-processing shaders would result in a loss of color detail in the final image.
@Kaldaien, is this correct?
Some of them have formats specified in the shader files (Like the SMAA one.) those I would imagine need to be altered.
ReShade itself has support for one specific 10-bit back buffer format at least and one override for this though I can’t see what it’s good for to toggle on especially if SpecialK already offers the 8-bit conversions and such towards HDR improvements.
EDIT: As to ReShade itself I use the proxy method frees up D3D .dll for potential improvements alternatively SpecialK can be this file instead freeing up DXGI.dll for any compatibility gains from doing this though I don’t think it’s too important, overlay and full-screen optimization settings perhaps.
Need to see what Microsoft is doing with FSO these days anyway think it’s lessened but still very much a thing albeit reduced especially from D3D9 due to compatibility concerns and breaking bugs, Game Mode apparently has the all important role now of delaying automatic updates while full-screen exclusive mode is on but I need to check that too. 
(And find a good overview of the upcoming/insider 21H1 changes ahead of time and expected problems ha ha.)
EDIT: Oh yeah for proxy loading ReShade the DXGI.ini file I’m using has these.
[Import.ReShade32]
Architecture=Win32
Blacklist=
Filename=ReShade32.dll
Role=ThirdParty
When=PlugIn
[Import.ReShade64]
Architecture=x64
Blacklist=
Filename=ReShade64.dll
Role=ThirdParty
When=PlugIn
ReShade also now loads from ReShade.ini so no need to change around naming although if you have multiple presets going that might need some tweaking.
But yeah a .dll file which here is ReShade64.dll is loaded by SpecialK and so far there’s been no problems between ReShade 4.8.2 and SpecialK December 2020 public compile of the day.
D3D11 / DXGI .dll and combinations thereof hasn’t really caused any issues either though so either method should work just fine baring any game compatibility issues or quirks of which unfortunately there can be several.
Some day I really need to document ReShade inter-operability on the wiki…
It’s not something I own use often, which is why it’s not high on the list of things to do.
Hang on hang on!
So it is possible then? I think I remember you Jonas from years ago on Guru3D? You always really knew your stuff and had loads of great tips and tweaks.
I’m a beginner really at all this and only have a moderate level of geekiness 
Any chance you could explain it to me in really simple terms how I might go about setting up reshade along with Special K HDR at the same time for a game?
I’m still somewhat active on G3D although overall it’s lessened a bit and I haven’t kept up very well with recent developments and changes.
(Trying to keep up a bit better with hardware and the OS and driver situation but even that’s kinda tough.)
If I understood the discussion from Kaldaien in a few topics around here and the Discord channel upcoming changes to ReShade should help with HDR it’s not something I myself have invested into and can utilize so while I am following this as I find it very interesting and something for consideration in the future I can’t utilize it or test anything currently when it comes to HDR functionality.
There’s a lot of developments on ReShade and if it’s still active there’s a channel on their Discord linking to a separate group with WIP builds but I don’t know how well they’d help currently or if there’s more to go before 4.9.0 or what the next major version will be can be considered for both SpecialK and ReShade with HDR without any drawbacks.
Simplified and without the overly lengthy text I tend to get into or corrections, edits and forgetting something or the other as per usual?
It needs more work still but it sounds like it’s coming but for now it sounds like ReShade is best left alone if you use HDR or it might affect the results until this is handled better don’t think it can be forced very well either but without proper hardware to test it I can’t check on this myself.
And then to complicate it further you have SRGB and scRGB though I think the latter is only utilized with Cyberpunk 2077 and Assassin’s Creed Valhalla.
Then on top of that color space difference there’s Microsoft with HDR10 and the upcoming HDR10+ then there’s NVIDIA NVAPI with some form of HDR and AMD AGS with another through FreeSync2 think there’s one or two older Dolby HDR titles too.
SpecialK and it’s HDR widget and tooltips can do a lot more than I would hope to be able to explain easily as to how some of these work, simply put the HDR Windows OS support and game specific solutions and implementations differ and complicate matter somewhat.
Next up would also be Vulkan and that might be a tough one with the various extensions but for now with D3D11 and D3D12 and the focus on this at least that’s less of a concern.
The post in question is right there in fact just a few replies above.
EDIT: Oh and the custom version of SpecialK ReShade is built on 3.0.8 I believe it was so it’s better to avoid for compatibility now that ReShade 4.0.0 or 4.5.0+ are recommended for shader compatibility or the newest stuff with early programmable shaders or compute shaders which needs 4.8.0+
So just go with the official version.
Could also just see how it works with HDR but I can’t imagine it working too well yet it’s going to need some of these upcoming changes to ReShade and then after that likely SpecialK and compatibility to utilize this too.
Wouldn’t want the results to be off or wrong from missing formats or the extended range HDR provides among other benefits after all.
EDIT: Also I missed the entire PC Gaming Wiki again and the existing guide but I think it’s going to be rewritten anyway or in the process of being so because a lot of HDR widget settings and options changed between 0.10.x and the 0.11.0.50 versions to this current build of 0.11.1.0
Or as it’s now labeled 2020.12.30 I believe is how it goes so it’s a compile date more than a version number at least.
EDIT: Speaking of edits the latest 64-bit .dll file is found here.
32-bit .dll should be December 27th or December 28th I think?
Possibly either the Assassin’s Creed Valhalla topic, Cyberpunk topic or the D3D12 Feature topic.
Or somewhere in the last few posts by Kaldaien in the mega topic about a bit of everything.
There.
And the changelog would be this.
https://gitlab.special-k.info/Kaldaien/SpecialK/-/blob/0.11.liberated/CHANGELOG.txt
Plus parts of the above December 20+ notes from Kaldaien’s posts in addition to the code checked in on Gitlab here.
As a overview of what’s added/changed/fixed and so on.
EDIT: That’s a lovely little partial summary there too on how this works and what it does.
Ha ha.
It won’t be the way I’m planning to do things. I will take care of colorspace conversion before and after ReShade runs its post-processing. Those shaders will remain blissfully unaware that there’s anything different
Wouldn’t having shaders perform their effects in SDR lose detail in the output? Many shaders don’t have any HDR support at all, using sRGB only.
That was what I assumed as well.
The only reason they lose detail is because the input/output is 8-bpc.
The design I’m adopting will take the either 10-bpc (or ideally 16-bpc) final output of a game, perform appropriate conversion into a linear colorspace, pass it through to ReShade (16-bpc), when ReShade’s done with all of its passes, re-apply gamma for output.
ReShade doesn’t technically need to know anything about the color depth and can be forced into replacing 8-bpc targets with 16-bpc, but it does @#$% with gamma, and that’s what makes it incompatible with HDR. It’s trying to post-process HDR gamma encoded images and only understands linear (or in some cases sRGB, but that’s silly).
EDIT: Oh, and, uh, negative colors… that’s the other thing ReShade doesn’t handle That one’s more problematic. When you make the post-processing pipeline FP16 instead of UNORM8, shaders that for whatever reason output negative values, no longer have those values clamped to 0.0 automatically the way they did in SDR.
The negative output of one shader becomes the negative input of the next instead of 0.
The concern isn’t about Reshade, but the shaders themselves. Not sure how you are going to do that without editing every shader that only support sRGB manually.
Yeah stuff like this.
Or formats.
(Smart Sharp and SMAA shader bits respectively.)
It can be changed but that’s a more advanced step and done incorrectly the shader might break or it’ll look off instead.
Updates to ReShade itself might help but it’s always a bit of a process when existing shaders have to be updated and how long it takes and how many are newer updated at all for the existing major updates and overhauls of ReShade and breaking changes to older files and presets.
Crosire will probably have to contend with users reporting using version 1.x and 2.x for a long time due to that and wanting support and compatibility with newer titles not an easy thing to balance.
3.0 and 4.0 has a few files to bridge compatibility but even that’s tough in the newer 4.0 changes and so there’s often a requirement in the shader itself or a different branch against two separate versions as some shaders also are written to try and support both.
HDR ReShade support would be a bit unavoidable for compatibility issues and having to touch up some of the existing shader files a bit if SpecialK or ReShade itself can’t override or change a few things in expected behavior and results.
Would be a pretty big feature though once the initial troubles are mostly overcome.
EDIT: The bigger ReShade reference file on the projects Github page with statements and functions probably covers some of these better and what can be found in some shader files and how that interacts with ReShade and overrides or adjustments of various sorts.
There’s also the shader Github page but it’s slowly being deprecated over a multiple repositories solution from different contributing authors so there’s a smaller core set of shaders and then a lot of others to browse through from that configuration / downloader helper software included with the ReShade installer.
I already have to add and remove sRGB for SK. It’s trivial, editing shaders to do it is barbaric.
I’m still not completely understanding, it seems. Most shaders simply do not support HDR formats, and don’t know how to handle any more than sRGB. Take almost any Reshade shader and use it in nearly any HDR game (some games, like RE2 as an example work fine, not sure why), and the output will look “wrong”. Usually with washed out highlights, but I have gotten a “deep fried” effect with some of them. I don’t see how the shaders that don’t know how to use anything but SDR sRGB (or equivalent) could ever work with HDR/WCG data, unless you first compress the detail being sent to them. But if you do that, you are losing the data in the output. Or am I missing something?
Most shaders don’t know how to handle sRGB either. They expect to be in linear-space, I think unless we clear up what is meant by sRGB there’s always going to be some confusion here.
I think what you’re calling sRGB is merely Rec 709 colorspace. Very few shaders are aware of the gamma curve that is going to be applied to the final output. It’s useful for luminance-based edge detection, which is why SMAA/FXAA likes it.
As for the rest of the stuff, any input/output in R8G8B8A8 UNORM can basically be treated as an alias for the swapchain format. Since that’s what 90% of games use, if you encounter a shader hard-coded to input/ouput that format, just replace it with R16G16B16A16 in HDR.
The only ill effect that would have in the case of ReShade would be double the required memory bandwidth (before colorbuffer compression).