So I am a bit confused on this. In the editor there is a button that lets you take high res screenshots, and there are options in there to enable Visualization Buffers, and an option to save said buffers as HDR. All of this is also doable via the HighResShot console command, and the HDR option can be enabled with the r.BufferVisualizationDumpFramesAsHDR setting.
We want to leverage this heavily in our workflow however it turns out that despite setting the HDR option, the EXR files that are output are not actually HDR images, or at least not proper HDR images. They are in fact 32bit EXR files, but its a wasted 3dbits because despite the bit depth, the images don’t actually have any dynamic range in them!. Super whites still clip at 1, which means if you have bright lights and expose down, they just go grey which is not what they should do in a proper HDR image.
Has anyone run into this and found a way to make it work properly, or is this a bug in the engine?
That actually depends on what target you are talking about. Many buffers like basecolor, specular and roughness are intentionally clamped from 0-1. Other buffers such as scenecolor or scene depth will actually make full use of the float range. I have tested that before by re-creating fog using depth inside nuke etc. The scenecolor one will only be HDR if the lighting is bright enough to push it that way, or there is HDR emissive etc.
If that isn’t working, try r.gbufferformat 5 as that switches the gbuffer to be floatRGBA internally. It is possible some code change occurred that I am unaware of that may cause scenecolor to not be HDR unless you do that.
So I checked the current value of r.gbufferformat and it was 1. I changed it to 5, and dumped out SceneColor again, but it was still clamped at 1.0 and showed no range in Nuke when stopping down.
Maybe I am just doing something wrong? Eventually the plan is to use the console command, but for testing I am just using the High Resolution Screenshot button in the viewport. I enable both the option to dump buffers and to use HDR. I get 32bit EXRs saved out, but they are all clipped at 1.0, even SceneColor. I have tried this both with and without ToneMapping turned on in the viewport. As best I can tell what gets saved out matches exactly what I see in the viewport - IE it is saved out AFTER it has already been clamped into a monitor capable LDR image. I say this because if I turn tonemapping on or off, I get different results in the saved image, where in theory I should not.
I can submit something more complete if you want? In any case if someone finds the bug and a fix, would it be possible to communicate the code changes required? We are in a bit of an odd situation where we are working from the 4.9.1 source, and don’t have the easy ability to update to a newer version, so we would need to incorporate the fix ourselves.
I tried to find it, but the jira bug I entered was marked as a duplicate and the person who did that put in a different duplicate as the number… I cannot find the one that actually has the changelist, sorry. I have pinged the qa person who did the editing since normally the actual correct bug should be listed when there is a duplicate but it wasn’t.
