RE: [Algorithms] Gamma correction an HDR images?

[Jay S. <Ja...@va...>]

> So the steps are:
> 1. Convert from 2.2 to 1.0 gamma (You do this by raising the=20
> pixels to the
> 2.2 power).
> 2. Generate mips.
> 3. Convert from 1.0 gamma to 2.2 gamma (Do this by raising=20
> the pixels to the 1.0/2.2 power).
>=20
> Correct?  Or did I invert the 2.2 vs. 1.0/2.2 bit?  I think=20
> someone already said this, but I want to be sure.

This is all fine, but realize that you can't store a texture as RGB888
in gamma 1.0 without losing a lot of information.  So at Valve, we do
this by expanding to float[3] for the gamma 1.0 textures and generate
mips on floats, then we quantize back down to 8-bits when we convert
back to gamma 2.2.

> Now, how do you deal with an environment where you have=20
> diffuse textures stored in LDR 2.2 gamma space and HDR cube=20
> maps stored in 1.0 gamma
> (linear) space?  Obviously, combining texels from both=20
> sources with any math is going to be incorrect.  So, I had this idea:

This is what the sRGB stuff is for in the pixel shaders.  You want to
convert on texture sample (ideally before billinear filtering, but that
doesn't always happen) to linear (gamma 1.0 is linear) format.  Then all
of your pixel math is in linear (with float per component again) until
you write to the framebuffer and convert back to 2.2.  Usually in HDR
renderers you'll want the framebuffer to use more precision than RGB888
as well and not convert back on write, but it may not be necessary
unless you need to do multi-pass or deferred rendering.

> 1. Convert LDR images from 2.2 to 1.0 gamma space and generate mips.
> 2. *Leave* them in 1.0 gamma on disk.  That way they are in=20
> the same space as your HDR textures.
> 3. All your pixel shading / blending / whatever takes place=20
> in linear space.
> 4. In your last full screen pixel shader pass, raise every=20
> pixel to the
> 1.0/2.2 power to go back to gamma space.
>=20
> Will this work?  Or will I get nasty banding or other junk going on?

Sure, except now they are float per channel.  Or you'll get lots of ugly
quantization errors like extreme color banding in the darker colors.

> Also, what gamma should artists calibrate their monitors to? =20
> 2.2 or 1.0?=20

2.2 we assume our textures are authored at a 2.2 gamma (which is
unfortunate for artists with LCD monitors since they are typically gamma
1.7 - 1.9)

> It kinda seems like if they worked in gamma 1.0 that=20
> everything would be rosy, but I don't think the hardware is=20
> set up that way and you have to calibrate to something around=20
> 2.2.  Right?

Sure, except for 1.0 you'd need more than 8-bits per component to get
reasonable image quality at the expected dynamic range of the monitor.
Gamma is there to fix this problem.  An intuitive way to think of it is
like perceptual compression/encoding.  The reason monitors are not at
gamma 1.0 is because the human visual system isn't either.  It's really
hard to tell the difference between incrementally brighter pixels at the
bright end of the spectrum, but pretty easy at the dark end, so gamma
2.2 lets you use more bits at the dark end.

Jay