[DIrectX 10] HDR rendering render target formats

Started by
4 comments, last by MJP 13 years, 1 month ago
Hi,
Im wondering which render target formats should I use in my HDR rendering pipeline...

For the first render target, that is used to render the scene into, following the HDRFormat10 example I was thinking about using R9G9B9E5, but why cant I simply use a DXGI_FORMAT_R16G16B16A16_FLOAT or DXGI_FORMAT_R32G32B32A32_FLOAT? Is the only difference the amount of memory needed?

To calculate luminance do I also need a render target that stores values outside the [0;1] range? So what format should I use?

For the bright pass, I guess I can use a DXGI_FORMAT_R8G8B8A8_UNORM render target... Is that right?
Advertisement
[color="#1C2837"]Is the only difference the amount of memory needed?[/quote]Them being 32, 64 and 128bpp means storage sizes are quite different, but besides taking up more memory, it's also slower to read/write the larger formats (because more data has to be sent around). Obviously you get something for that price, namely higher precision with the larger formats ;)
Generally you want to use the smallest formats that give you the desired precision (e.g. 16-bit float is probably more than enough precision, meaning you shouldn't have to use 32-bit float).
- I was reading the HDRFormats10 sample and when it creates the render targets instead of using R9G9B9E5_SHAREDEXP format, it uses the DXGI_FORMAT_R16G16B16A16_FLOAT format... Why cant it use R9G9B9E5_SHAREDEXP format?

- Which render target formats convert from gamma 2.2 to gamma 1.0 automatically for free?

- Do I have to apply any gamma correction when I sample diffuse maps?

- I was reading the HDRFormats10 sample and when it creates the render targets instead of using R9G9B9E5_SHAREDEXP format, it uses the DXGI_FORMAT_R16G16B16A16_FLOAT format... Why cant it use R9G9B9E5_SHAREDEXP format?

- Which render target formats convert from gamma 2.2 to gamma 1.0 automatically for free?

- Do I have to apply any gamma correction when I sample diffuse maps?


-I'm guessing it's because that sample supports D3D9, where that format isn't available. You should be able to use it yourself with no problems, as long as it provides adequate precision for your needs.

-Any format that end with the _SRGB suffix will automatically be converted from sRGB to linear when sampled, and vice versa when written to by a pixel shader.

-Usually you do...it depends on how the texture was authored. In most cases a diffuse map will be authored in an image editing program like Photoshop or GIMP, in which case they are authored in sRGB space and saved that way. In that case you want to load those images using an sRGB format, so that they get gamma corrected when sampled. There can be a few exceptions to this case, so it's always nice to be able to easily select sRGB or linear on a per-texture basis.
Thanks for your answers


-I'm guessing it's because that sample supports D3D9, where that format isn't available. You should be able to use it yourself with no problems, as long as it provides adequate precision for your needs.

Well reading the DirectX Documentation I found out that the R9G9B9E5_SHAREDEXP format cant be used as a render target...


-Any format that end with the _SRGB suffix will automatically be converted from sRGB to linear when sampled, and vice versa when written to by a pixel shader.

That was what I read in "Programming Vertex, Geometry, and Pixel Shaders"... So, since HDRFormats10 use DXGI_FORMAT_R16G16B16A16_FLOAT it should convert gamma when it samples and writes to render targets right? But I cannot find any gamma correction code... So I guess I'm missing something...

So, since HDRFormats10 use DXGI_FORMAT_R16G16B16A16_FLOAT it should convert gamma when it samples and writes to render targets right? But I cannot find any gamma correction code... So I guess I'm missing something...


No, you don't want to convert to sRGB when rendering HDR values to a floating point surface. This is because

A) sRGB only works for [0, 1] values

and

B) Floating point formats have sufficient precision for accurately storing linear color values

This topic is closed to new replies.

Advertisement