Why FilmicCurve doesn't work as it should?

Acording to filmicgames.com/archives/75 Here's how Uncharted 2 filmic should work applied to this image.

Before



After (Better blacks, more detail in light areas)



While FilmicCurve in Reshade does something like this



Why? It says it is "improved" version of Uncharted 2 tonemap, but it's bad, nothing is improved here.
And tweaking Gamma lower in LiftGammaGain doesn't help at all. I don't know how to make shaders, but could anyone please do (if it is not hard) appropriate version of Uncharted 2 filmic tonemap that does what it suppose to do?

Answer is here: reshade.me/forum/general-discussion/1422...-tonemaps-done-wrong (See the post from Marty McFly)

"Code is on github, feel free to commit changes." - I'm fine with that. Fair.

But considering "tone mapping is "useless"." etc. - Here's the image. Here's how filmic tonemaping should work on it. It doesn't work as it should, hence - it's not proper filmic tonemap.

Marty : "tonemapping already tone mapped images [...] it's essentially color grading."

That's the actual quote that explains it. I may be wrong but the tonemapping is applied to an HDR image or to an HDR framebuffer in a game. Reshade captures a 8bit (not HDR) sample of a game and applies shaders to process those pixels.

Tonemapping is a technique that is used to fit the extended dynamic range of an HDR source inside the limited range of an 8bit per channel image so it can be displayed in a screen.
When the image arrives to Reshade is already 8bit (it has no extra information beyond whats displayed on screen), hence it makes no sense trying to tonemap it to try to rescue extra information. You only get extra white or extra black. Therefore no tonemapping is possible in reshade, only color correction.

Feel free to correct me if I'm wrong.

piltrafus wrote: That's the actual quote that explains it. I may be wrong but the tonemapping is applied to an HDR image or to an HDR framebuffer in a game. Reshade captures a 8bit (not HDR) sample of a game and applies shaders to process those pixels.

This is correct. The image from the blog post is HDR too (which is why it is in DDS format, common image formats usually cannot save HDR data). HDR (i.e. 32-bit per component) is able to save much more lighting information compared to LDR (8-bit per component), which is normalized to the color range a monitor can handle. As for the "before" image, the monitor basically clips all values to the highest it can display, which is why you can still view the picture, but it does not look like it is supposed to look like. Tonemapping converts the huge HDR color range to the limited LDR color range, depending on overall brightness, exposure etc. Applying it to an image that already is in LDR space is thus, as Marty McFly stated, essentially useless. It still can produce interesting results, but does not bring the technique justice.

The reason ReShade captures 8-bit LDR output is because that is what Direct3D and OpenGL write to in the last step, as that's the information sent to the monitor. A game may implement HDR in the rendering pipeline before that final step and then do the tonemapping right before finish, but this is entirely voluntary and every game can do it differently. It's thus almost impossible to capture HDR output (if it exists) generically. Game specific graphic injectors have an advantage here, as they are free to hardcode a certain implementation.

So, why does those tonemapping shaders even there? Wouldnt it be better to just use colorcorrection through the 3dlut?

Yaruosu wrote: So, why does those tonemapping shaders even there? Wouldnt it be better to just use colorcorrection through the 3dlut?

They are there for artistic purposes. ReShade is not a (technically) color correction software. In the past, there was a similar debate on the Witcher forums. In exclusive fullscreen mode, some games -such as the Witcher 3- forces linear gamma, hence causes your customized .icc profile to be ignored. In response to this, some users suggested using ReShade for correcting the colors. But as you can see ReShade cannot be used in such a technical way because the implementation would be wrong. If we would have generic access to other textures than backbuffer, then it could be used for various technical purposes. Imagine a true HDR photograph where you take multiple shots then combine them afterwards. Then imagine a single photograph with an HDR "effect".

Again the similar issue also occurs in color banding. The correct implementation would be dithering the 32-bit result when writing it to an 8-bit texture. When developers forget adding dithering to the pipeline, color banding occurs as a result. Then we use technically non-correct implementations such as Deband shaders to artificially "guess" the original image. It gives the viewer the impression that there is no banding in the image by masking it.

That is the difference between "artistic implementation" and "technical implementation".

Oh, i see now. Thank you, i guess. Btw, where can i ask how to use current github shaders ?

Yaruosu wrote: Oh, i see now. Thank you, i guess. Btw, where can i ask how to use current github shaders ?

Normally, you just download the files from the repository. And replace your current ReShade.fx file and ReShade folder with them. The rest is easy, you just configure the shaders as you normally would. But the latest revision includes a change in how preprocessors work, which requires the latest (currently not available to public) binaries to work. So I believe everyone has to wait a little while until the major release that includes the latest binaries becomes available.

Oh, now i understand, why shaders do compile, but no changes occurs. Thank again !
Just curiosity - those mentioned changes influence performance, or is it for some new features?

Yaruosu wrote: Oh, now i understand, why shaders do compile, but no changes occurs. Thank again !
Just curiosity - those mentioned changes influence performance, or is it for some new features?

Both. Rewrote the entire preprocessor from scratch, which yields in faster compile times now, but more importantly adds/fixes some features requires for the new preset management seen on GitHub.

Speaking of artistic purposes. Please keep technicolor 2. It seems a lot more authentic than technicolor 1. I actually use 1 as a quick and dirty color correction before fine tuning with vibrance. But I made this with technicolor 2 real quick www.nexusmods.com/fallout4/mods/8216/ ?