"reverse tonemapping"?

so, this has come up a few times on these forums, and i'd like some clarifications.

i understand that games use tonemapping to convert a HDR signal path to a LDR signal for display. however, why would a reverse tonemapping shader allow you to go back to the HDR original? if i understand correctly, there's a loss of data precision going from HDR to LDR, and that data is just gone, and won't come back. is the reverse tonemapping shader going to make guesses to fill in the lost data, or is the reverse tonemapping shader merely expanding dynamic range, and the missing data simply stay missing?

Well, it's basically like down scaling and up scaling an image. Afterwards it has the same size like before but less data.

Before tonemapping, you have HDR data. It has a huge amount of different color values, a lot of these are above FFFFFF white, like 60000 instead of 255, hence displaying them on a screen would show white only.

Tonemapping compresses this color range into 0-255 range. Easiest way would be dividing all values so they fit into this range. But that would mean that most areas would end up being almost black. So a tone mapping function comes in that compresses the HDR data exponentially, leaving darker values almost untouched.

So HDR 0-255 ends up in LDR 0-230 or so, HDR 256-10000 in LDR 231-250 and HDR 10001+ in 251 to 255. the exact mapping is depending on the function obviously.
But that means that you have a huge data loss as well. If we put 10000-20000 in 251 to 252, all values between 10000 and 15000 will have the same LDR value after, 251.

Inverse tone mapping now basically reverts this action, putting LDR 251 to HDR 12500. As you can see, if we have LDR 251 there is no way to know if it was 10000 or 10001 or 11000 or 15000. The values after inverse tone mapping have their original HDR range but it's still 256 different steps.

That's why inverse tone mapping is no magical solution for higher color range, it's just useful for bloom to know which pixels are truly bright. LDR 220 and 230 are just a little different but before tone mapping, the HDR equivalent of 230 was multiple times brighter than 220 and so must produce much stronger bloom.

This is also the reason why tone mapping a tone mapped image is just wrong. LDR 255 before second tonemap will be mapped to LDR 230. You can see a lot of presets where true 255 255 255 white is just a light grey, those have a wrong tone mapping on them.

i think i understand now.

basically, my assumption about the huge loss of precision is correct - reverse tonemapping merely brings the LDR output into the same range as the original HDR signal, but obviously don't get the same color accuracy back.

correct me if i'm wrong: the only time i'd want to use reverse tonemapping, is to correctly judge where to apply bloom, and how strong the effect must be, for everything to look realistic. i should never use it in a effort to increase dynamic range, or produce "better" colors. the former is impossible, and the latter i can use use a LUT shader instead.

Absolutely correct

thanks.

last question for this thread: how do i go about finding what tonemapping shader a given game is using? i remember reading somewhere that i have to decompile the game's executable.

That's basically it. But you can use a simple one (reversing uncharted tone map for example is a huge ass formula) and approximate. Based on the curve and formula you choose, you can control how much the compression is, and so control bloom, in my example from earlier it's defining if 220 to 230 end up in 10000 to 15000 range or 250 to 252.

What sonic ether did specially was to modify the game tonemapper to include a higher range. Most tonemappers clip colors above a certain threshold, so these are ultimately lost. So anything above say 1000 ends up at 255. He modified the game so it makes distinctions between higher ranged colors as well. But this also means the game got darker as the lower areas now have a smaller range after compression. So he has to remove the tone mapping and retonemap.
Basically too strong tone map-> HDR restored-> bloom generated and applied-> correct tone mapping.

Marty, Is it possible to do something like this with the effects in Reshade 3.0.6?
I mean, this effect found in Photoshop HDR, which leaves something darker and some edges lighter and more prominent ...

Image

You know that this is an artifact photographers usually try to avoid at all cost because the algorithm failed at stitching the differently exposured images together ?

I am still quite inept at GLSL/HLSL, however, I recently reversed a LUT color correction in perfect succession by simply ripping the LUT texture from the game and setting the LUT chroma intensity to -1.0. I just wondered if "Tonemap reversal" would be done similarly (For ex. find the tonemapping technique, along with it's values and then just add minuses) Am I correct?

NoMansReshade wrote: Yes, but how do you go about reversing tonemapping? Don't most games use different algorithms, and if not, different parameters? There can never be a sure-way to reverse tonemapping across multiple games, correct? Reverse tonemapping seems to be a "Sacred" thing as I can find NOTHING on google that talks about it... Any answers are greatly appreciated!! Thank you.

I'm responding to you here instead because it seemed a bit off-topic in the other thread.

Read the introduction from this paper .

You can't just reverse tone mapping because a lot of information is lost when the image is tone mapped. I think the best you could hope for is some kind of selective reverse tone mapping like what this paper describes. And even if you did reverse the tone mapping it would just need to be tone mapped again to bring it back to the LDR to be displayed by ReShade. So basically you would be trading one tone mapping technique for another.

It could be helpful for separating light sources from bright objects, this would help create a better bloom effect, but I think it would come at a pretty heavy performance cost.

But I'm far from an expert on the subject so I could be wrong. I'm sure someone will correct me if I am.

NoMansReshade wrote: I am still quite inept at GLSL/HLSL, however, I recently reversed a LUT color correction in perfect succession by simply ripping the LUT texture from the game and setting the LUT chroma intensity to -1.0. I just wondered if "Tonemap reversal" would be done similarly (For ex. find the tonemapping technique, along with it's values and then just add minuses) Am I correct?

This only works with bijective changes. Imagine a LUT that makes your whole screen black. Lost information cannot be restored. This applies to LUT's that clip colors in any way, so after the original LUT is applied, more than one pre-LUT color has the same post-LUT color.

About inversing tonemap, you need to think a bit more math-y. Imagine a simple (not a tonemap but will do for the example) formula that basically does

color =pow(color,0.5)+0.7;

in mathematical spelling:

y = x^0.5 + 0.7

Reversing the formula is now equivalent to finding the inverse formula. We solve for x:

y-0.7 = x^0.5
(y-0.7)^2 = x

now we switch x and y:

y = (x-0.7)^2

And that's our inverse formula. Let X1 be our HDR data, the first formula Y1 = X1^0.5 + 0.7 translates it to Y1, our LDR data. Now X2 = (Y1-0.7)^2 translates Y1 back to X2 which is our HDR data after back and forth. X2 == X1 in theory, but as the data gets rounded to 0-255 steps, X2 has less precision than X1.

This is an example of the simplest possible tonemapper, y=x/(x+1); inversed is y=-x/(x-1). Both graphs plotted here:

Funnily enough, some tonemappers cannot be inversed because they only work as expected in >= 0 range. y = (x^k - x)/(x^k - 1) for example, k being the tonemapping factor. Try solving it for x

Interesting... I managed to gain HDR data in a dummy game of mine from inversing the reinhard algorithm (if 1.0 - tonemapPass counts ), but was too lazy to reverse the algorithm correctly, so blending it back didn't go so well . I will continue to do some testing, but at least I have an adolescent-esque understanding of what actually goes on under the hood. Thank you!!

NoMansReshade wrote: Interesting... I managed to gain HDR data in a dummy game of mine from inversing the reinhard algorithm (if 1.0 - tonemapPass counts ), but was too lazy to reverse the algorithm correctly, so blending it back didn't go so well . I will continue to do some testing, but at least I have an adolescent-esque understanding of what actually goes on under the hood. Thank you!!

Feel free to use my bloom to test your reverse tonemapping if you want to.

I Have been It's very simple to understand (the comments help.) At this point I have a decent understanding of reverse tonemapping, and have managed to achieve it myself using your bloom. I'm more focused on the "Cinematic" side of bloom, rather than "Natural". If it's one thing I do know, though; Your bloom looks great no matter what

I think I may have started to crack into inverse tonemapping.

I tried inverting a simple reinhard tonemapper:
This was the result I got by inverse tonemapping to an HDR texture, making a blurred copy of it, adding it to the non-blurred one and re-tonemapping:


Looks HDR enough, with all things considered. Even though Morrowind isn't an HDR game this may find use in LDR games, we need to test it more.
I'm going to insert this into my bloom shader in a few hours and will reply back with the result.

Edit:
The reason the brightest "blurs" look squared is because the sigma isn't high enough to cover such a bright value, which can be fixed by downsample+blurring numerous times, like bloom.

I found another simple tonemapper, it's called "ACES Filmic Tonemapping"... The algorithm goes like this:
The reversed algorithm would look something like this:This is the default tonemapper used in Unreal Engine 4 (hint, hint)... It reminds me of Marty's Haarm Peter modification, but slightly simpler.

EDIT: after testing this myself, it seems to work well, even on a Unity game
Here is a screenshot of it wigging out in an amazingly beautiful way


Here is a gif of it working correctly (Ignore the overpowering intensity, I did that intentionally to make the algorithm more apparent):


Here is my code. No additive tonemapping is required, btw:
Then I call the return in the first blur pass (aka thresholding pass) like this:


And no, this does not apply the tonemapping to the final image. And yes, I removed the HDRPass thing I used to have!

On/Off comparison of the final image:

Wow, I guess you just need to add exposure (using adaptation) and we may have a winner!

These are just test screenshots of the bloom from the game portal 2:

Off


On

(Ignore the other effects that I have turned on)
Keep in mind that other pixels with the light's intensity do not give off any bloom, which would lead me to believe that the bloom is receiving actual HDR colors from the inverse tonemapping. I will continue testing... Regardless, I think it looks great so far, and it's not overpowering even in outdoor scenes!!!!

EDIT:
Videos speak a million words, so here:


Notice how the bright lights high up (Possibly the sky, idk) barely give off any bloom, but the lights indoors give off lots of eye-candy bloom

Try using the actual UE4 values (it does use ACES but those aren't the values) and also, do try hable/uncharted tonemap. Inversing it is fun but the end result pays off, mostly because whites get hugely bright. Careful though that 1.0 whites are compressed to 0.93333333 so you need to divide colors by that value respectively.

Wow that worked surprisingly well