// M matrix, for encoding
const static float3x3 M = float3x3(
    0.2209, 0.3390, 0.4184,
    0.1138, 0.6780, 0.7319,
    0.0102, 0.1130, 0.2969);

// Inverse M matrix, for decoding
const static float3x3 InverseM = float3x3(
    6.0014, -2.7008, -1.7996,
   -1.3320,  3.1029, -5.7721,
    0.3008, -1.0882,  5.6268);

float4 LogLuvEncode(in float3 vRGB)  {
    float4 vResult;
    float3 Xp_Y_XYZp = mul(vRGB, M);
    Xp_Y_XYZp = max(Xp_Y_XYZp, float3(1e-6, 1e-6, 1e-6));
    vResult.xy = Xp_Y_XYZp.xy / Xp_Y_XYZp.z;
    float Le = 2 * log2(Xp_Y_XYZp.y) + 127;
    vResult.w = frac(Le);
    vResult.z = (Le - (floor(vResult.w*255.0f))/255.0f)/255.0f;
    return vResult;
}

float3 LogLuvDecode(in float4 vLogLuv) {
    float Le = vLogLuv.z * 255 + vLogLuv.w;
    float3 Xp_Y_XYZp;
    Xp_Y_XYZp.y = exp2((Le - 127) / 2);
    Xp_Y_XYZp.z = Xp_Y_XYZp.y / vLogLuv.y;
    Xp_Y_XYZp.x = vLogLuv.x * Xp_Y_XYZp.z;
    float3 vRGB = mul(Xp_Y_XYZp, InverseM);
    return max(vRGB, 0);
}

I hope people who visit this post (and according to the stats, its a fairly popular post) will find this info useful. Make sure to visit the gamedev.net thread too (as linked above). Rim van Wersch (remigus) also posted a simple test project that you might want to check out.

You’re right, there are many different options when it comes down to render HDR images.
Since we can’t really do alpha blending using this color space, if a game really needs to blend in a HDR color space then this technique only make sense only if used in conjunction with multisampling, writing a custom AA resolve filter that downsample a LogLuv image to a FP16 image where we can do HDR blending
(Though I think that HDR blending is overrated, we can live without it just blending on a RGBA8 render target, tone mapping in our alpha blending pass pixel shaders, even better if we do it using exposure computed in the previous frame read back with the CPU so that we can avoid a texture read in our pxel shaders and set exposure as a pixel shader constant.)
It’s also worth to notice that the vast majority of games probably don’t fully use the full FP16 range bur rather a narrower range, in this case we can drop the logarithm and just store a linear luminance scaled to just fit the luminance range we want to support, even in this case I doubt we can tell the difference, can we? :)
BTW..the code I used to encode luminance is really ugly but I did not have much time to spend on it and it was the only code that did the job (perfect LogLuv -> RGB/FP64 conversion) as when I (sneakily!) introduced it the game already had a ton of content developed using FP16 and I did not want the artists/art director to scream in pain cause our images were slighty darker (!!):

// pack the luminance into 2 channels..
float Le_LSBs = frac(Le);
float Le_MSBs = (Le - (floor(Le_LSBs*255.0f))/255.0f)/255.0f;

// unpack log luminance
float Le = Le_MSBs + Le_LSBs / 255.0f;

Thanks for your compliments Christer, I’m looking forward to what you and your team can do on PS3!

Marco

float4 res;
float3 v = mul(rgb, m);
v = max(v, float3(1e-6, 1e-6, 1e-6));
float k = 2*log2(v.y) + 128;
res.xy = unpack_4ubyte(k).xy;
res.zw = v.xy / v.z;
return res;

Although this might not work so well either; I can’t remember if the pack/unpack instructions were hosed or not. (I’m not the one doing the shader coding.) I recall the unpack approach produced worse code too, but this was with a pretty old Cg compiler, so who knows.

Feel free to steal the dot product folding trick! (If you haven’t already.)

I don’t know of any other games using LogLuv at this point. I considered it for our engine based on your posts about your approach, but we haven’t committed to how to deal with HDR yet so the ball is still in the air. (As you know quite well, there are several possible options and which is best depends a lot on what other choices you’ve made - and we haven’t made all our choices yet.)

BTW, I don’t think it’s a secret to mention publicly that I’ve seen builds of Heavenly Sword and the graphics are absolutely gorgeous. Kudos to you and the team!