Texture Tools Exporter Clamps HDR Data When Exporting BC6H

Gaming and Visualization Technologies General Topics and Other SDKs
1

If I import an HDR image into the Texture Tools Exporter (either as a .hdr file or a .exr file), then export with the BC6H format, the exported image is clamped such that the maximum value is 1.0

Is this a known issue?

Thanks!

2

Hello,

I don’t think the NVAPI is the correct forum for your issue. Can you please tell me what service or product this refers to? I can then move your topic to the best forum for one of our Mods to help answer.

Thanks,
Tom

3

I agree, but I don’t believe there is a subforum that matches my problem, and the forum made me choose one. The product that I’m having trouble with is the Texture Tools Exporter (https://developer.nvidia.com/nvidia-texture-tools-exporter)

4

Hi Aaron,

I am still looking for a better home for your topic. Thanks for your patience.

Tom

5

Hi Aaron,

I am going to move this topic over to the Gaming and Visualization section of the forums.

Best,
Tom

6

Thanks! I see that @nbickford has answered questions related to the Texture Tools Exporter in the past - Neil, is there any chance you could help me out?

7

Hi AaronJ! Thanks - this looks like a bug! I was able to reproduce this, and it looks like like HDR DDS files (e.g. BC6H and RGBA32F) get read and written correctly, but whenever we read from or write to an EXR or HDR file, the values get clamped to [0,1]. We use our own DDS reader/writer, but use FreeImage for EXR and HDR, so I’m guessing there’s a bug in how we’re handing images to FreeImage. Looking into this and will have another update shortly.

8

I’ve just submitted a fix for this, and it should be in the next Texture Tools Exporter maintenance release (fairly soon)! It turned out there were two issues:

  • When converting between linear and sRGB, we generally try to use an unclamped version of the sRGB transfer function (sort of like scRGB). However, the function this path was calling to convert to and from sRGB was using a function that clamped its inputs to [0,1]. Switching to the unclamped function fixes this. I think the DDS pipeline happened to avoid these functions, which is why it worked.
  • When loading an HDR file, we convert from floating-point RGB to floating-point RGBA using FreeImage_ConvertToRGBAF - and it turns out this also clamps to [0,1]. This has been noticed elsewhere (e.g. FreeImage 96bpp to 128bpp conversion clamps value · Issue #209 · NVIDIAGameWorks/Falcor · GitHub), and I think this is most likely unintended behavior in FreeImage (this does not happen when converting RGBAF to RGBAF, and the documentation doesn’t specify what should happen for 96-bit RGBF), so I’m hoping to submit a fix to the FreeImage project very soon.

Thanks again!

9

Hey Neil, thank you so much for the quick turnaround! I really appreciate it. Looking forward to the update!

10

Hey! What’s the expected time for the release?

11

Hi Aaron - apologies, this release has been taking longer than I initially thought! I can’t provide release date updates at the moment, but I’m working on it!

Thanks,

–Neil

12

Thanks for the info Neil, I appreciate your work and look forward to the next release!