Re: [Algorithms] Gamma correction an HDR images?

[Stephen J B. <sj...@li...>]

Jon Watte wrote:

> Also, Stephen Baker wrote:
>  > Since the whole point of gamma correction is to allow for the
>  > non-linearity of the screen phosphors, doing any gamma correction
>  > *before* lighting is WRONG.
> 
> Actually, part of the reason to gamma correct is to get a better dynamic 
> range out of your fixed-resolution texels. With that interpretation of 
> gamma correction, it makes perfect sense to gamma adjust before 
> lighting, because it's just a function for compressing and restoring 
> dynamic range.

Yeah - I understand that using a non-linear representation within at
texture is useful as a compression mechanism, but I wouldn't describe
that as "gamma correction" - which is where this discussion started
(see 'Subject' field).

Let me clarify what I'm saying:

I absolutely agree that it's interesting/useful to compress larger
dynamic range textures into non-linear luminance spaces - and *perhaps*
it even makes sense to use the mathematical function known as 'gamma'
to do that (although I believe there are better choices).

But I maintain that attempting to do 'gamma correction' (as in
fixing the problem of non-linear display luminances) anywhere
near the MIPmapping process is a really bad idea.

-----------------------------------------------------------------------
The second law of Frisbee throwing states: "Never precede any maneuver
by a comment more predictive than "Watch this!"...it turns out that
this also applies to writing Fragment Shaders.
-----------------------------------------------------------------------
Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sj...@li...           http://www.link.com
Home: sjb...@ai...       http://www.sjbaker.org