Soft r_gamma

[duzenko]

Are there other opinions on the problem?

 

I guess trying to avoid color banding was the reason to tweak ambient light.

Such tweak itself may be OK, but I think it cannot replace gamma correction.

IMHO users only use gamma correction when there is no other way to crank the lower-range colors up. So they wouldn't care how exactly we brighten up the darker surfaces.

[stgatilov]

IMHO users only use gamma correction when there is no other way to crank the lower-range colors up. So they wouldn't care how exactly we brighten up the darker surfaces.

It does not explain why there are both gamma and brightness in settings.

If no one cares how image is brightened, one of them would be enough.

[Springheel]

If no one cares how image is brightened, one of them would be enough.

 

 

Gamma increases contrast, not brightness. That's why I don't understand replacing it with a different system that seems to be another type of brightness. If there's no way to increase contrast, scenes will just get washed out.

[duzenko]

 

Gamma increases contrast, not brightness. That's why I don't understand replacing it with a different system that seems to be another type of brightness. If there's no way to increase contrast, scenes will just get washed out.

I disagree. What is the gamma formula and how does it relate to contrast?

[Springheel]

I don't mean that it works exactly like contrast, but that the effect is to create a greater range of value in dark areas so that there is greater contrast between a dark object and a somewhat dark object. High brightness washes out scenes. High gamma maintains contrast between light and darks. I don't understand how this new 'gamma' can do that if it's just brightening ambient lights on a linear scale.

 

[New Horizon]

Also, if it's literally brightening the ambient lights, then that is going to affect gameplay.

[Springheel]

Also, if it's literally brightening the ambient lights, then that is going to affect gameplay.

 

 

I think that part has been dealt with already: http://forums.thedarkmod.com/topic/19239-soft-r-gamma/?p=416478

[duzenko]

I don't mean that it works exactly like contrast, but that the effect is to create a greater range of value in dark areas so that there is greater contrast between a dark object and a somewhat dark object. High brightness washes out scenes. High gamma maintains contrast between light and darks. I don't understand how this new 'gamma' can do that if it's just brightening ambient lights on a linear scale.

 

Right. No, I think the current ambient tweak does exactly what you described, even if it only does it to ambient and does not use a pow() or a lookup table.

It makes dark stuff less dark, without bleaching out the light stuff. And, it does not affect other open windows or cause color banding.

 

@stgatilov

I'm afraid doing this in a postprocessing stage will cause some color banding to return. It's best done before precision loss, i.e. before writing pixels to framebuffer.

[stgatilov]

@stgatilov

I'm afraid doing this in a postprocessing stage will cause some color banding to return. It's best done before precision loss, i.e. before writing pixels to framebuffer.

Yes, if we use 8-bit colors, then banding is inevitable when gamma correction is used.

But hacks around ambient shaders cannot replace gamma correction.

[peter_spy]

Technically, gamma doesn't increase contrast. Increasing contrast equals stretching the histogram, so the darks get darker, lights are lighter, and colors get more saturated. Don't remember how gamma worked in 2.05, but in 2.07/beta VBO update 10, r_gamma works similar to output levels black point.

 

[stgatilov]

Technically, gamma doesn't increase contrast. Increasing contrast equals stretching the histogram, so the darks get darker, lights are lighter, and colors get more saturated. Don't remember how gamma worked in 2.05, but in 2.07/beta VBO update 10, r_gamma works similar to output levels black point.

The current "gamma correction" does not influence interactions.

 

Note that in a proper rendering engine lighting is computed in linear space, and gamma correction is done as the last step. This gamma correction converts the colors from linear space into gamma space. Then the physical monitor has the built in gamma transformation (left over from CRT times), so it transforms colors back from gamma space into linear space, and shows linear intensities. As the result, light sources with quadratic falloff look on the monitor as they look in the real world.

Now with TDM I have no idea what convention is followed. But since all the math is done in additive way (i.e. impacts of lights are added), the whole thing can only be correct if all the colors are in linear space during rendering. It means that someone has to convert them to gamma space at the very end, otherwise monitor will apply gamma transformation to gamma space, and the picture will be over-contracted. As the result, light sources with quadratic falloff will look unrealistically concentrated (since they will actually have falloff with power 4.5): they light close things too bright, but have too small effect on things farther away.

 

The new way gives absolutely no way to correct gamma curve of the actual light sources, while the old way did.

Moreover, the old way was right on the conceptual level, although this correctness gives no benefit if everyone tweaks media using gamma = 1.2.

The serious problem with the old way is that color banding appears on dark colors, because all intermediate rendering results (in linear space) are stored with 8-bit precision. And the common way of fixing it is simply using more precision, e.g. 16-bit floats for colors. This approach is called "High Dynamic Range", and it is necessarily used for physically correct lighting.

[peter_spy]

I made my textures and materials with default settings, so with gamma 1.2. Not sure what to do now. Better lighting precision would be very welcome, since e.g. light textures on flat surfaces (without or with mild normalmaps) look like they're from Thief 2.

 

Also, while looking at misc r_ variables, I noticed that default for r_lightscale is not 1 but 2. Was that deliberate, and if so, why?

[duzenko]

I made my textures and materials with default settings, so with gamma 1.2. Not sure what to do now. Better lighting precision would be very welcome, since e.g. light textures on flat surfaces (without or with mild normalmaps) look like they're from Thief 2.

 

Also, while looking at misc r_ variables, I noticed that default for r_lightscale is not 1 but 2. Was that deliberate, and if so, why?

It's just an arbitrary value that someone chose at some point in the past. All materials, lights and maps after that were designed against it. No idea who and why, probably just to brighten up the inherently dark materials like wood.

[duzenko]

The current "gamma correction" does not influence interactions.

 

Note that in a proper rendering engine lighting is computed in linear space, and gamma correction is done as the last step. This gamma correction converts the colors from linear space into gamma space. Then the physical monitor has the built in gamma transformation (left over from CRT times), so it transforms colors back from gamma space into linear space, and shows linear intensities. As the result, light sources with quadratic falloff look on the monitor as they look in the real world.

Now with TDM I have no idea what convention is followed. But since all the math is done in additive way (i.e. impacts of lights are added), the whole thing can only be correct if all the colors are in linear space during rendering. It means that someone has to convert them to gamma space at the very end, otherwise monitor will apply gamma transformation to gamma space, and the picture will be over-contracted. As the result, light sources with quadratic falloff will look unrealistically concentrated (since they will actually have falloff with power 4.5): they light close things too bright, but have too small effect on things farther away.

 

The new way gives absolutely no way to correct gamma curve of the actual light sources, while the old way did.

Moreover, the old way was right on the conceptual level, although this correctness gives no benefit if everyone tweaks media using gamma = 1.2.

The serious problem with the old way is that color banding appears on dark colors, because all intermediate rendering results (in linear space) are stored with 8-bit precision. And the common way of fixing it is simply using more precision, e.g. 16-bit floats for colors. This approach is called "High Dynamic Range", and it is necessarily used for physically correct lighting.

Wow that's deep. Personally I doubt the gamma table was used for anything other than brightening the picture.

[Springheel]

I think the most useful thing would be to see some comparison screenshots like Judith did above, showing what the original gamma correction did to a particular scene, and what the new one does. Otherwise all of this is rather abstract. It may turn out that the new system is different, but in a way people prefer.

[peter_spy]

It's just an arbitrary value that someone chose at some point in the past. All materials, lights and maps after that were designed against it. No idea who and why, probably just to brighten up the inherently dark materials like wood.

 

It also helps with postprocess settings and getting that burned highlights. But I'm not sure that was a good idea, it seems like one of the core values that shouldn't be changed, as it affects everything else. Kind of too late for that.

[duzenko]

Wow that's deep. Personally I doubt the gamma table was used for anything other than brightening the picture.

By "brightening" I mean adding "contrast" to the low-range colors only, I guess it's what that post was about http://forums.thedarkmod.com/topic/19239-soft-r-gamma/page-3?do=findComment&comment=426872

[duzenko]

I made my textures and materials with default settings, so with gamma 1.2. Not sure what to do now. Better lighting precision would be very welcome, since e.g. light textures on flat surfaces (without or with mild normalmaps) look like they're from Thief 2.

 

Also, while looking at misc r_ variables, I noticed that default for r_lightscale is not 1 but 2. Was that deliberate, and if so, why?

BTW the new multi-light shader WIP is not using light textures at all.

[peter_spy]

That would be interesting. Although the only problem with current light textures is that the engine renders them poorly. Using all 256 gradient steps and less color banding would be a great improvement.

[duzenko]

Switched to two gamma modes: exponential (1.0 - 3.0) and hyperbolic (0.1-1.0)

The cvar value inherited from 2.06 should result in more or less the same look after update.

I assume nobody actually used r_gamma<1 or else they are for a surprise LOL

Attached are screenshots with soft r_gamma 2.0 and 0.2 for comparison.

[peter_spy]

Exponential is the effect you see in games most often IMO, but I like how hyperbolic maintains contrast.

[duzenko]

Exponential is the effect you see in games most often IMO, but I like how hyperbolic maintains contrast.

Which is why I'll be using it myself. @stgatilov is the one who wants exponential (but in a different place)

[Springheel]

I assume nobody actually used r_gamma<1 or else they are for a surprise LOL

 

 

What does this mean? My gamma has traditionally been set to .9. What kind of a "surprise" am I in for?

[duzenko]

 

What does this mean? My gamma has traditionally been set to .9. What kind of a "surprise" am I in for?

Ambient would have been brighter for you.

Why so low? Are you trying to add contrast this way? Can you see the ambient at all?

[peter_spy]

IMO you need that initial lack of contrast in your scenes to account for many monitor setups and configurations players may have. If you want to bump contrast a little bit, you can turn postprocessing on and off to see how it looks like (it adds some contrast, apart from the bloom effect).

Edited September 15, 2018 by Judith