Original Post
Hi, I was just thinking about a color compression scheme that allows me to compress HDR data into 8-bit per channel render targets. LogLuv seems to be a winner. u and v is normalized to 0..1 and L can be much higher than this. I looked up the paper "Overcoming Gamut and Dynamic Range Limitations in Digital Images". I looked into the source ... and hmmm it is hard to understand, so I started with the equations. The intersting part here is the 32-bit encoding, it allows to store the luminance part in 16-bit == two 8-bit channels. The luminance part is encoded like this Le = 256(log2 L + 64) equation 4a As far as I understand the text, L is CIE Luv. The 256 is to normalize the value range to 0..1 I guess and the +64 is probably removing the sign. If all these assumptions are right, then I should end up in a pixel shader with Le = log2(Y) The eqaution for decoding Le is L = exp2((Le + 0.5)/ 256 - 64) eqaution 4b Without the 256 and 64, decoding this luminance value would than be done with L = exp2(Le) I do not know exactly what +0.5 is for ... I guess it is to work around rounding errors. To encode the u and v part we might use ue = 410 u' equation 5a and ve = 410 v' equation 5b The number 410 is used to convert those values into the 0,255 range. They seem to be in the range 0..0.62. In a pixel shader we want a value range of 0..1, so it would make sense to convert these values with something like * 1 / 0.62. That assumes that the values that are used in u' and v' are in the right value range. So I end up with ue = 1/0.62 * u' ve = 1/0.62 * v' u' and v' can be found in equation 2a and 2b u' = 4x / (-2x+12y+3) v' = 9y / (-2x+12y+3) The x and y are from CIE Luv as well?. Decoding the stuff is done with u' = (ue + 0.5) / 410 equation 5c v' = (ve + 0.5) / 410 equation 5d This should translate to the following equation with a 0..1 range u' = (ue) * 0.62 v' = (ve) * 0.62 Does that look right to you? - Wolf [Edited by - wolf on January 3, 2007 5:56:51 PM]