Problem with exr files

[Claude_ch]

Hi,

So when I render with DAZ Studio Pro and save that file as an exr file and then open it in Affinity Photo, it's all white. I need to add an exposure adjustment to see the image. The image is an RGB/32 bit format, now when I want to convert this image to RGB/16 or RGB/8, the image becomes all black.

The turn around solution is, I need rasterise the image with the exposure adjustment included and then convert in RGB/16 or RGB/8 and that works.

 

PS I added the file, if you need the exr file,tell me ;)

Victoria.afphoto

[Chris B]

Hey Claude_ch,

The afphoto file opens up in the Windows Photo beta and looks correct to me. The file is still in RGB/32 - or is this the file with the exposure adjustment already baked into it? I can look at the .exr if you upload it here - https://www.dropbox.com/request/f0oiWhIP63xqAddPpKgU

[James Ritson]

1 hour ago, Claude_ch said:

Hi,

So when I render with DAZ Studio Pro and save that file as an exr file and then open it in Affinity Photo, it's all white. I need to add an exposure adjustment to see the image. The image is an RGB/32 bit format, now when I want to convert this image to RGB/16 or RGB/8, the image becomes all black.

The turn around solution is, I need rasterise the image with the exposure adjustment included and then convert in RGB/16 or RGB/8 and that works.

 

PS I added the file, if you need the exr file,tell me

Victoria.afphoto 29.49 MB · 2 downloads

Hey Claude,

This could actually be by design—I haven't used DAZ, but could relate using blender. There's more of a focus on physically correct lighting nowadays, and many of blender's environment/sky lighting plugins (such as True Sky, Physical Starlight and Atmosphere etc) will use incredibly bright values that then require the Exposure to be reduced significantly, usually by 3 to 6 stops.

This is fine when you are writing out gamma-corrected bitmap files such as TIFF and JPEG, but when saving to EXR this tone mapping isn't applied to the pixel values—instead, you're getting the unmodified pixel values in linear gamma. This is by design, as software shouldn't really be writing any kind of gamma encoded values to EXR.

If you colour pick one of the white values when you first import your EXR, I imagine the value would be greater than 1. What are your tone mapping/view settings in DAZ? It may be you're using some kind of lighting that requires the Exposure value to be reduced, and you would then have to match that in Affinity Photo with an Exposure adjustment layer.

Your solution is sound in practice, but I would be wary of clipped or 'harsh' highlight details because you may also need to apply some kind of tone mapping to give highlights a roll-off effect. This should be done in 32-bit before merging/flattening and converting to 16-bit or 8-bit, which are bounded gamma corrected formats.

This video might be of help: 

 

 

Hope the above helps!

[Claude_ch]

3 hours ago, Chris B said:

Hey Claude_ch,

The afphoto file opens up in the Windows Photo beta and looks correct to me. The file is still in RGB/32 - or is this the file with the exposure adjustment already baked into it? I can look at the .exr if you upload it here - https://www.dropbox.com/request/f0oiWhIP63xqAddPpKgU

it's in RGB/32 and I added the expo for seeing the image. Now when you go in the menu document -> Convert Format/ICC Profile.. and chose for example RGB/8 the result is a black picture now.

But if you rasterise before the image with the exposure adjustment and the convert in RGB/8, the image is correct.

I send you the .exr file.

[Claude_ch]

4 hours ago, James Ritson said:

Hey Claude,

This could actually be by design—I haven't used DAZ, but could relate using blender. There's more of a focus on physically correct lighting nowadays, and many of blender's environment/sky lighting plugins (such as True Sky, Physical Starlight and Atmosphere etc) will use incredibly bright values that then require the Exposure to be reduced significantly, usually by 3 to 6 stops.

This is fine when you are writing out gamma-corrected bitmap files such as TIFF and JPEG, but when saving to EXR this tone mapping isn't applied to the pixel values—instead, you're getting the unmodified pixel values in linear gamma. This is by design, as software shouldn't really be writing any kind of gamma encoded values to EXR.

If you colour pick one of the white values when you first import your EXR, I imagine the value would be greater than 1. What are your tone mapping/view settings in DAZ? It may be you're using some kind of lighting that requires the Exposure value to be reduced, and you would then have to match that in Affinity Photo with an Exposure adjustment layer.

Your solution is sound in practice, but I would be wary of clipped or 'harsh' highlight details because you may also need to apply some kind of tone mapping to give highlights a roll-off effect. This should be done in 32-bit before merging/flattening and converting to 16-bit or 8-bit, which are bounded gamma corrected formats.

This video might be of help: 

 

 

Hope the above helps!

Hi,

the Tone Mapping was by default.

When I open the .exr (RGB/32) it's all white. Then I add a live exposure adjustment for bring back the picture. And when I convert in RGB/16 or RGB/8 I lose all data and the picture is black. Maybe the value from DAZ for .exr are out of the ordinary and when Affinity Photo try to converts it's going wrong. I send the .exr file on dropbox

And for your Live Procedural Texture, works better as with the exposure adjustment, the color are less saturated. I need juste a crazy number for the compression Scale... 13'000 for example. It's very close with the 8bits png version what DAZ save a the same time.

[James Ritson]

2 hours ago, Claude_ch said:

Hi,

the Tone Mapping was by default.

When I open the .exr (RGB/32) it's all white. Then I add a live exposure adjustment for bring back the picture. And when I convert in RGB/16 or RGB/8 I lose all data and the picture is black. Maybe the value from DAZ for .exr are out of the ordinary and when Affinity Photo try to converts it's going wrong. I send the .exr file on dropbox

And for your Live Procedural Texture, works better as with the exposure adjustment, the color are less saturated. I need juste a crazy number for the compression Scale... 13'000 for example. It's very close with the 8bits png version what DAZ save a the same time.

The picture going black will be because:

• Your original EXR document contains pixel values greater than 1
• Unless you merge down the Exposure adjustment before converting to RGB/16 or RGB/8, you will then lose (clip) those >1 values
• This is because the Exposure adjustment is then being applied to the bounded range of pixel values, so it is taking the maximum value (255 in 8-bit, 65535 in 16-bit) and reducing it down to 0.

The solution is either to merge the Exposure adjustment before converting, or to simply stay in RGB/32 and use a tone mapping method after the Exposure adjustment (e.g. procedural texture, or Levels adjustment followed by other adjustments).

Hope that helps!

[Claude_ch]

13 hours ago, James Ritson said:

The picture going black will be because:

• Your original EXR document contains pixel values greater than 1
• Unless you merge down the Exposure adjustment before converting to RGB/16 or RGB/8, you will then lose (clip) those >1 values
• This is because the Exposure adjustment is then being applied to the bounded range of pixel values, so it is taking the maximum value (255 in 8-bit, 65535 in 16-bit) and reducing it down to 0.

The solution is either to merge the Exposure adjustment before converting, or to simply stay in RGB/32 and use a tone mapping method after the Exposure adjustment (e.g. procedural texture, or Levels adjustment followed by other adjustments).

Hope that helps!

Ok, I go with this solution to merge with your Tone Mapping (Live Procedural Texture) method, works better Vs Exposure adjustment.

Thank you for your help