hdr Tone mapping

[MirceaKitsune]

The good news is tone mapping is applied to those GUI's as well. This reduces the white value on readables and even the main menu, it actually makes them look pretty good! They're far more bearable and natural looking with r_postprocess_brightness 1.5, still can't go as high as 2 which looks good in-world but blasts the GUI in over-brightness.

[Taffingtaffer]

So the latest dev build enables this by default... I'm not sure if that means the implementation is considered done, but I don't see the improvement; there's an overall grey fog over the image, dark is less dark and colors are less rich. First screenie is on, second is off.
 

Edited January 2 by Taffingtaffer

[Baal]

I only tested this feature (r_postprocess_compress on/off, no changes otherwise) on a (terrible) netbook screen for now. The most noticable issue (to me) is a slight desaturation. It is not an improvement in my opinion.

[Daft Mugi]

I appreciate the effort that went into implementing the new tonemapper. It’s clear that a lot of thought has been put into refining the visuals, and I wanted to share some observations and questions based on my experience.

Using my monitor, which is optimized for creating art (100% sRGB, 100% Rec. 709, Color Accuracy ΔE < 2, Calman Verified), I’ve noticed the following:

1. Visual Changes: The new tonemapper doesn’t appear to improve blown-out or overbright areas, as they remain overexposed. Additionally, the rendering feels more desaturated, with reduced contrast and significant color shifts (e.g., gold to bronze, red to salmon, white to gray). This results in a flatter scene with less depth and vibrancy. Firelight now feels more like the glow from fluorescent lighting, which shifts the overall tone and mood of scenes. The overall scene can appear hazy.
2. Gameplay Impact: The new tonemapper can make it harder to notice when objects and doors are frob highlighted, which could make gameplay more challenging for players.
3. Art Style Consistency: The new tonemapper can significantly change the visual style of existing missions, which might affect the overall player experience, especially for those familiar with the original look. Also, mission authors who have spent time carefully tweaking colors may find their work visually altered in unintended ways.

While the new tonemapper may have strengths in certain scenarios, its impact seems to vary widely depending on hardware and context. Would it be possible to consider making the new tonemapper opt-in while gathering additional feedback? This might help ensure that everyone can choose the visual style that works best for their setup and preferences.

Here are 4 sets of screenshot comparisons:

• Original: first in set.
• New Tonemapper: second in set.

Spoiler

Spoiler

Spoiler

Spoiler

[Frost_Salamander]

I agree with @Daft Mugi that going by the screenshot comparisons alone, this really isn't an improvement.  It's the opposite.

Under what circumstances will this feature improve the player experience?  Maybe an explainer is needed for dolts like myself that don't understand this thread (but can see the difference in the screenshot comparisons).

[thebigh]

Yeah, this looks worse IMO. It looks like Corbin is developing cataracts.

[JackFarmer]

I also think it looks worse in the new screenshots and like Frost, I do not understand the fundamentals behind this change.

[stgatilov]

If you want to do screenshot comparison, you should rollback several cvars:

• r_postprocess_compress: 0 instead of 1
• r_postprocess_overbright_desaturation: 0 instead of 0.1
• r_postprocess_desaturation: 0 instead of -0.2

And you might as well check that the following cvars have default values:

• r_postprocess_gamma
• r_postprocess_brightness
• r_postprocess_exposure

Or even better, just copy TDM installation and compare new build vs old build.

It is inevitable that allowing overbright colors to be more distinguishable reduces contrast and saturation of colors. Unless you agree to have eye adaptation or to tweak stuff manually for each scene.
The saturation was somewhat increased using r_postprocess_desaturation, so you should definitely change both cvars if you want to compare.

I think it is okay to return to the old LDR tonemapping with clamping of colors over 1. But I guess we should ask the people who initiated this why they want to avoid clamping so badly.

[Daft Mugi]

To add to what stgatilov said:

For those who want to try this in-game, I recommend creating a binding to toggle between the original and new tonemappers for convenience.

Initially, make sure the cvars start with values for one of the tonemappers.

Bind a key:

bind "b" "toggle r_postprocess_compress; toggle r_postprocess_desaturation 0 -0.2; toggle r_postprocess_overbright_desaturation 0 0.1"

Check that the binding is toggling correctly as a group. In the console, you should see output like the following:

set r_postprocess_compress = 1.000000                                                                                          
set r_postprocess_desaturation = -0.2                                                                                          
set r_postprocess_overbright_desaturation = 0.1 

set r_postprocess_compress = 0.000000                                                                                          
set r_postprocess_desaturation = 0                                                                                             
set r_postprocess_overbright_desaturation = 0 

 

To take comparison screenshots of something with motion, such as flames, sparks, or NPCs: First, stop the game time, and then take the screenshot.

toggle g_stopTime

It's recommended to start the game time after your are done taking screenshots as things that are far away from where "g_stopTime" was stopped can be in a weird state.

[lowenz]

With the new tonemapper the low contrast dark areas ARE improved a bit.

Edited January 4 by lowenz

[thebigh]

Most of the game is dark. Areas where clamping, or other artifacts of bright lighting, occur are pretty rare. I'd rather put up with some plasticky appearance in 5% of a level than endure a milky cataract look for the other 95%

[kingsal]

@Daft MugiBrought this to my attention

Tone / color mapping is awesome to see, but this new version looks worse. 
Its clamping the highlights as mentioned and overall reducing the color saturation of the scenes. 

It would be nice to keep messing with it and have as an option for authors to play with, but this should not be implemented by default (not yet at least)
 

[Baal]

On the occasion of the 2.13 beta test, I tried to compare the look by switching the cvars stgatilov suggested earlier. I am having a hard time deciding what is better. 

Dark areas are less straining on the eye, but I don't think that is worth the noticeable desaturation. The game already looks much less vibrant (compared to screenshots and videos of older versions, I am not sure when that happened). 

In my opinion, this should not be the default, at least not in this state.

[datiswous]

Looking at this I don't entirely understand what problem this is trying to fix. It removes atmosphere in the process.

I've tested multiple missions now. Sometimes it looks ok (but not an improvement), sometimes it looks worse.

Darker area's are now brighter, which doesn't look good mostly, because they're supposed to look dark. Over-bright area's look (maybe) a bit better, but saturation seems lower, making everything look a bit boring.

I can also say that flickering light for example from a torch, looks less visible. This is probably because there seems to be less contrast between light and dark in the environment.

It's a bit the effect of when you take a jpeg (not a raw image) and lower the contrast. You don't get more detail. Looks a bit washed out.

I think it could be helpful in daylight missions or in very brightly lit rooms?

Spoiler

Active

Inactive

 

 

Active

Inactive

 

Active

Inactive

 

 

 

Edited January 17 by datiswous

[snatcher]

The implementer simply forgot to set the gamma to 1 by default (where it actually belongs).

With gamma set to 1 blacks are a tad darker, whites aren't as bright and saturation is improved.

Do please compare 2.12 with gamma set to 1.2 (default) and 2.13b1 with gamma set to 1 (not the default).

[stgatilov]

3 hours ago, datiswous said:

It's a bit the effect of when you take a jpeg (not a raw image) and lower the contrast. You don't get more detail. Looks a bit washed out.

Yes, absolutely.

Displaying more range without clipping necessarily means lowering contrast. If lowering contrast is not an option, color range cannot be increased and must stay at LDR = [0..1] forever.

[datiswous]

I think that high contrast is better fitted for tdm aesthetic.

[snatcher]

@Taffingtaffer, @Baal, @Daft Mugi, @Frost_Salamander, @thebigh, @JackFarmer, @kingsal, @datiswous

On 1/15/2025 at 8:44 PM, snatcher said:

Do please compare 2.12 with gamma set to 1.2 (default) and 2.13b1 with gamma set to 1 (not the default).

What do you think?

I don't fully understand this change but I am sure there are good reasons behind it it and that the math checks. I am just trying to stay positive.

[Frost_Salamander]

A bunch of us have already expressed the opinion that we don't understand the benefit of this, and nobody has really come back with an answer.  Does it only help with certain scenes?  Certain FMs?  Do you need to have a particular hardware setup?

It kind of just seems like someone's science project at the moment.  I'm not trying to discourage innovation by any means, but maybe it just shouldn't be the default setting?  Is it meant to be?  Is it the kind of thing you would just toggle on if need be?

[nbohr1more]

I am no expert here but I think the motivation is to align TDM tonemap behavior to something closer to ACES standards.

The "default" mode should not use tonemap compression so this should only something done when advanced users want to tinker with tonemap curves. ( we should change the cvar to 0 )

The new change is that there is a non-linear response to over-bright scene items that reduces the likeliness of blowout. I think that overblown bloom lighting is seen as an antiquated light representation by some industry professionals.

To me it's a matter of personal taste.

My only wish is that postprocess_colorCurve was left available for tinkering but I haven't played with the other new settings enough to know if there is a way to approximate it or not.

I agree that if compression is enabled the base gamma value should be 1 or lower to improve contrast but ( again ) that is a personal preference.

I think ultimately, I would just want the option to reproduce the old "HDR-Lite" tonemapping from v1.03 so that older maps that were designed with that lighting style in mind would match the author's intention. If that can be achieved via tinkering with the current options that would be fine, but maybe we can have tonemap presets similar to the frob outline presets?

[snatcher]

1 hour ago, nbohr1more said:

[...] if compression is enabled the base gamma value should be 1 or lower to improve contrast but ( again ) that is a personal preference.

What I detect here is that with gamma set to 1  the game already looks a tad darker than before, but not too much to raise any alarm. I find this solution a good compromise if we are to embrace the new tone mapping. The Dark Mod shouldn't be shy about darkness anyway. By default, that is.

Edited January 17 by snatcher

[stgatilov]

1 hour ago, Frost_Salamander said:

A bunch of us have already expressed the opinion that we don't understand the benefit of this, and nobody has really come back with an answer.

Actually, I hoped @Arcturus would explain, or someone else who was so positive about it.

In my opinion, the only reason is to avoid hard clamping on over-bright colors.
This situation rarely happens on existing mission, because mappers usually avoid that much light. But if you look at golden plates with a candle nearby and enable lantern, or gather several candles at the same location, then it happens.

I can probably do something to fix the change in hue, but reduced contrast is totally inevitable I think.

[Frost_Salamander]

4 minutes ago, stgatilov said:

Actually, I hoped @Arcturus would explain, or someone else who was so positive about it.

In my opinion, the only reason is to avoid hard clamping on over-bright colors.
This situation rarely happens on existing mission, because mappers usually avoid that much light. But if you look at golden plates with a candle nearby and enable lantern, or gather several candles at the same location, then it happens.

I can probably do something to fix the change in hue, but reduced contrast is totally inevitable I think.

Thanks.  So it seems like it has some benefit for very specific situations, but at the expense of desaturated/washed out colours the rest of the time.

I think the main concern of mappers was that this would be the default setting.  Mappers don't generally like things that will change the presentation of their FMs. If it isn't default, I don't really see a problem with the feature.

[Daft Mugi]

How can an artist's visuals be preserved?

With the goal of artistic preservation in mind, here are two ideas for a path forward:

1. A graphics menu option for players: With TDM 2.12 tonemapper as default, have a graphics option for additional tonemappers, such as this TDM 2.13 tonemapper. This would respect artistic intent while still offering flexibility to players.
2. A worldspawn option for mission authors: With TDM 2.12 tonemapper as default, allow the tonemapper to be configured by a mission author. This would respect artistic intent. With this method, perhaps -- like @nbohr1more mentioned above -- tonemapping for missions made for TDM 1.03 could be restored.

Establishing the TDM 2.12 tonemapper as the default baseline moving forward—with optional tonemappers—would help ensure long-term visual stability. This strategy would honor the original artistic intent and maintain confidence among mission authors and asset artists.

[stgatilov]

15 minutes ago, Daft Mugi said:

How can an artist's visuals be preserved?

You make it too complicated.

I'll simply revert the defaults (except for r_tonemapOnlyGame3d maybe) and consider this new code as "delete whenever you want".
If the common opinion is that it looks worse, and mappers don't want their levels to look like this, then there is no point in wasting time and attention on it (I mean maintaining, testing missions against it, etc.).