Comments on: Converting RGB to LogLuv in a fragment shaderhttp://realtimecollisiondetection.net/blog/?p=15
Coding wisdom and rants of Christer EricsonFri, 26 Feb 2016 07:46:15 +0000hourly1https://wordpress.org/?v=4.4.5By: Gamma correct and HDR rendering in a 32 bits buffer | Light is beautifulhttp://realtimecollisiondetection.net/blog/?p=15#comment-7537
Mon, 27 May 2013 06:42:44 +0000http://realtimecollisiondetection.net/blog/?p=15#comment-7537[…] Since we really want a wide range of light intensity, a different approach is to use a different color space. Several people mentioned LogLUV, which I hear gives good results, at the expense of a high instruction cost for both packing and unpacking. Here is a detailed explanation. […]
]]>By: Article: HDR Rendering with XNA « Sgt. Conkerhttp://realtimecollisiondetection.net/blog/?p=15#comment-3119
Fri, 01 Jan 2010 17:59:18 +0000http://realtimecollisiondetection.net/blog/?p=15#comment-3119[…] NOTE: credit for the optimized encoding function goes to Christer Ericcson, who posted it on his his blog. […]
]]>By: realtimecollisiondetection.net - the blog » Catching up (part 2)http://realtimecollisiondetection.net/blog/?p=15#comment-2780
Mon, 08 Jun 2009 08:51:51 +0000http://realtimecollisiondetection.net/blog/?p=15#comment-2780[…] Karis links to my LogLUV post while pointing out that there’s another kid in town: RGBM color encoding. In fact, we are […]
]]>By: XNA On The 360, Part 2: HDRhttp://realtimecollisiondetection.net/blog/?p=15#comment-2253
Thu, 14 Aug 2008 20:31:13 +0000http://realtimecollisiondetection.net/blog/?p=15#comment-2253[…] in many other PS3 games, as well. My actual shader implementation was helped along quite a bit by Christer Ericson's blog post, which described how to derive optimized shader code for encoding RGB into the LogLuv format. […]
]]>By: christerhttp://realtimecollisiondetection.net/blog/?p=15#comment-2139
Sat, 12 Jul 2008 07:25:04 +0000http://realtimecollisiondetection.net/blog/?p=15#comment-2139Just to round out the above blog post and its comments, I thought I’d mention that users MJP and remigius over at gamedev.net incorporated Marco’s packing code with my code snippet and also worked out the details of the matching LogLuv_Decode() function. So, for completeness, and with credits to MJP and remigus, here’s the full Encode/Decode pair (in HLSL):

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.

]]>By: Another day, another HDR rendering trick and some hope for the future. « Pixels, Too Many..http://realtimecollisiondetection.net/blog/?p=15#comment-2047
Sat, 05 Jul 2008 16:43:44 +0000http://realtimecollisiondetection.net/blog/?p=15#comment-2047[…] but even without re-introducing a floating point buffer (or some funky color space technique, see Christer Ericson’s blog entry about some of the work I did on Heavenly Sword and his very clever take on it) we can still […]
]]>By: realtimecollisiondetection.net - the blog » I like spilled beans!http://realtimecollisiondetection.net/blog/?p=15#comment-20
Mon, 03 Sep 2007 03:33:42 +0000http://realtimecollisiondetection.net/blog/?p=15#comment-20[…] the RGN values in the fragment shader. I guess it would also be possible to encode textures using LogLuv, although that seems a bit […]
]]>By: nAohttp://realtimecollisiondetection.net/blog/?p=15#comment-6
Sat, 14 Jul 2007 17:50:13 +0000http://realtimecollisiondetection.net/blog/?p=15#comment-6Hi Christer,

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 (!!):

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

Marco

]]>By: christerhttp://realtimecollisiondetection.net/blog/?p=15#comment-5
Sat, 14 Jul 2007 07:10:37 +0000http://realtimecollisiondetection.net/blog/?p=15#comment-5Hi Marco, good to see you here! Back when I looked at this I only worked out how to optimize the RGB->LogLuv code as per above, not the other way around, so I never looked into the precision issues but I did scribble in my notes that splitting the luminance value into two bytes could be an issue and that you might have to do something else. A possible option could be to write it this way:

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.

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!

]]>By: nAohttp://realtimecollisiondetection.net/blog/?p=15#comment-4
Sat, 14 Jul 2007 06:35:15 +0000http://realtimecollisiondetection.net/blog/?p=15#comment-4Well done Christer!
Your implementation is actually faster than mine as I did not fold the dot product into the matrix multiplication and I also had to split the log luminance in a more convoluted way as using the same transformation you used I was not being able to perfectly go back to a RGB colour without losing a tiny bit of intensity.
BTW..do you know any game that is making use of the same base technique?
The only one I’m aware of is Heavenly Sword..
]]>