Alternate colormap falloffs

[Fredrik]

http://fredrikj.net/doom/doom3.wad

[printz]

I wonder if ZDoom supports this awesome capability…

[scifista42]

ZDoom - yes, of course. Just not GZDoom and other ports with OpenGL rendering.

[Jonathan]

Linguica said:

Yeah, I'm not sure why that happened - I assume it's a side effect of the fact that I converted RGB to HSV, and the grays were probably not "perfectly" gray once they got converted and so raising the saturation magnified that small error.

I'm guessing you had something like this:

hsv = (hsv[0], hsv[1] + ((1 - hsv[1]) * (1 - factor)), hsv[2])

The problem is that grayscales have a saturation of zero by definition. If you add anything to the S value, they're no longer grays, they're a grayish tint of whatever their hue is. Since grayscale hues are normally also zero (although it can be anything, since it has no effect), it turns them into desaturated reds, which then get mapped to light brown in the Doom palette. The simplest fix is just to only apply the saturation scaling if the saturation value is non-zero. In which case you get this:



http://brillskills.com/games/doom/saturate.zip (sorry it's a zip, I'm having MIME-type troubles with my hosting)

[Linguica]

Marnetmar said:

I think the saturation colormap could actually look quite good if the effect was a bit more subtle.

Here's one with the saturation bump half as strong:



http://www.doomworld.com/linguica/colormaps/sat50.wad

[scifista42]

Linguica said:

http://www.doomworld.com/linguica/colormaps/sat50.wad

Looks mostly good to me, even though green fades to toxic green, brown fades to a single-shade shit, and vivid reds and blues are almost unaffected. Screenshots:

LEFT - sat50.wad, RIGHT - Doom2.wad

[Linguica]

All of this screwing around made me realize I should do one fixing the most obvious error in Doom's colormap.

So here's the normal colormap. Thinking about the function of it, the top is meant to show stuff in 100% bright light. The bottom is to show stuff in 0% light (well, about 3% light really). And in between is varying percentages in between. The original colormap generator just did this in linear levels, which makes sense - colormap level 0 is 32/32 or 100% illumination, colormap 1 is 31/32 or about 97% illumination, etc.



So thinking about this, that suggests that that colormap 16 should be 16/32 or 50% illumination. In the Doom universe, anything at this colormap can be thought of as having half as many photons bouncing off of it as at full-intensity lighting. But there's an issue. Let's look at another graphic showing off light levels:



This is an example of your standard gamma calibration chart. To put it simply, in the middle you have alternating pixels of pure black and pure white. If you squint, that means the center strip should have precisely 50% illumination, because it's half black and half white. The idea is that if your monitor is properly calibrated, the grayscale around the center strip will blend in to the strip at right around the middle of the image. (You can try right now if you like - most people's displays aren't properly calibrated, for what that's worth.)

Anyways, if you look at the image in an image editor, you'll notice something: the gray at the middle of the image, the gray that is supposed to be displayed on your screen as exactly half of full brightness, is not halfway between 0 and 255 as you might expect; it's 187.



There's a lot of science and shit behind this (http://www.4p8.com/eric.brasseur/gamma.html is a good start), but suffice to say, RGB 187 shows up on a properly calibrated monitor as halfway between black and white, not RGB 127. And what's the gray at 50% intensity in Doom's colormap? Why, it's 127!

So this means that the "half bright" colormap in Doom is way, way too dark; in fact, all of them are too dark. So here's a colormap generated using the proper values for a SRGB colorspace:





http://www.doomworld.com/linguica/colormaps/gamma.wad

Using this colormap, Doom light levels show up the way they are "supposed" to show up; a sector brightness of 128 appears visually is half as bright as one of brightness 255. It also pretty much looks like ass, because Doom was never designed to look like that, but there you go.



Note that this is because eyeballs/brains have a nonlinear response to light, so SRGB was specifically designed to mirror this - so that RGB 127 "appears" to be 50% gray, even though it's more like a 20% gray. So you can't say that the lighting model is "wrong" and changing it like this makes it "right."

[Linguica]

Also I tried making an omgifol script to "rebalance" a level's sector light levels for the proper-gamma colormap. My reasoning was that since people made a map to look right as it normally is, if I am using a linear -> SRGB colormap, then if I changed all the light levels using the reverse SRGB -> linear formula, it should balance out, right??

Spoiler

from sys import argv
from omg import *
from omg.mapedit import *
import math

def relight(map):
    ed = MapEditor(map)
    for s in ed.sectors:
    	if (s.light / 255.0 <= 0.04045):
    		s.light = int(s.light / 12.92)
    	else:
    		s.light = int(255 * (((s.light/255.0) + 0.055) / 1.055)**2.4)
    
    return ed.to_lumps()

def main(args):
    if (len(args) < 2):
        print "    Omgifol script: change light levels\n"
        print "    Usage:"
        print "    light.py input.wad output.wad [pattern]\n"
        print "    Relight all maps or those whose name match the given pattern"
        print "    (eg E?M4 or MAP*)."
    else:
        print "Loading %s..." % args[0]
        inwad = WAD()
        outwad = WAD()
        inwad.from_file(args[0])
        pattern = "*"
        if (len(args) == 3):
            pattern = args[2]
        for name in inwad.maps.find(pattern):
            print "Relighting %s" % name
            outwad.maps[name] = relight(inwad.maps[name])
        print "Saving %s..." % args[1]
        outwad.to_file(args[1])

if __name__ == "__main__": main(argv[1:])

Turns out, uhh, not really.

[Blastfrog]

Linguica said:

Turns out, uhh, not really.

Might want to do additional steps. Perhaps use some ramp that's meant to approximate what the "flat" equivalent to a given Doom light level as a reference? Might want to look at a few GL renderers to see what they do with the light level if they don't use the raw value.

[Rayziik]

Actually, "gamma" works nearly perfectly for my current project. And probably any other map I've made, because I've always assumed that 128 is half as bright as 255, which apparently isn't true in regular doom.

I can use it right? :D

[raymoohawk]

does it look to cartoony or crappy if you only use a single color in each range? like red only degrades to red for example, just curious

[scifista42]

Linguica said:

http://www.doomworld.com/linguica/colormaps/gamma.wad

I wouldn't want Doom to use this palette, because it totally screws contrast and fails to make darkness. Here are pictures of 2 of the very darkest areas in Doom 2, both having light level 0, in "gamma.wad" and "Doom2.wad" respectively. These areas might not be the best examples to show off how the "gamma" palette sucks, because both areas have poorly basic lighting whatsoever - but as a mapper, I prefer to have the possibility to create an actual, full or nearly-full darkness where I want it to be.

[Rayziik]

If I am interpreting the 'gamma' function correctly, that last bit drops down to 0 very fast, and in a logarithmic way. Perhaps if it could be adjusted to drop down to 0 linearly it might fix the lack or true dark and low contrast?

[Linguica]

Rayzik said:

If I am interpreting the 'gamma' function correctly, that last bit drops down to 0 very fast, and in a logarithmic way. Perhaps if it could be adjusted to drop down to 0 linearly it might fix the lack or true dark and low contrast?

Yes, of course things could be adjusted - I was just showing a colormap generated using a scientifically accurate method.

The problem is that the darkest colormap is not 0% light level, it is 1/32 or about 3.1% light level - and in SRGB color space, 3.1% illumination of a white surface is a LOT brighter than black. It works out to RGB 46 (!) or thereabouts.

[Jonathan]

Linguica said:

This is an example of your standard gamma calibration chart. To put it simply, in the middle you have alternating pixels of pure black and pure white. If you squint, that means the center strip should have precisely 50% illumination, because it's half black and half white. The idea is that if your monitor is properly calibrated, the grayscale around the center strip will blend in to the strip at right around the middle of the image. (You can try right now if you like - most people's displays aren't properly calibrated, for what that's worth.)

At least in OS X, every browser I've tried performs some kind of gamma adjustment on this image, and similar gamma calibration images I've found, so I wouldn't rely on them as a measure of display calibration without downloading them and viewing them in some external program. Even then, different images seem to disagree over whether my screen is calibrated properly, and to what gamma level.

[Wraith777]

Interesting info in this thread..

What about constantly changing psycho-colormap glitch when taking a negative damage (from healing imp fireball, for example :)) ?

[Da Werecat]

That would be psycho-palette. Screen flash on damage is a PLAYPAL effect.

By the way, the HUD face on the bottom left image is priceless.

[Wraith777]

Well, maybe yes, considering that it may be "healed" with berserk (screen tinted red, all colors are normal).

However, after some time when tinting effect wears off, "bad trip" comes back, only this time psycho-pallets are changing slowly.