Converting a floating point EXR image to 8-bit or 16-bit image creates artifacts

[Alex_M]

Hi,

I have a 3D rendered image saved as a floating point EXR. When I convert it to 8-bit or 16-bit in Affinity Photo, I get nasty image artifacts. Please check the screenshot below.

If you need it, I can send the EXR file to Affinity support staff privately.

[NotMyFault]

I would check for out of bounds values (RGBA channels), meaning above 1.0.

Use the histogram and set the max value higher than 1 (e.g. 2, 4, 10) to spot if those exists.

You can use a channels mixer filter to show them visually.

 

Another possible cause is HW acceleration. Please  try to deactivate OpenCL / Metal Compute

 

If you can share an example file (a sample cropped region would be enough, in RGB/32) i can probably provide some filters / adjustment to identify those areas, and correct them automatically. 
 

Of course, you can wait for moderators to provide an upload link, this might take a bit longer than help from users.

[Alex_M]

Thanks for the suggestions, @NotMyFault. I don't have hardware acceleration enabled. Please find attached a cropped version of the EXR. Please note that this issue appears with every 3D rendered EXR image that I've tested so far.

exr2_cropped.exr

[NotMyFault]

Thanks for the file. 

Unfortunately I can't reproduce the issue on my Mac or iPad. The file looks totally fine, all values are in the proper range for SDR images.

Can you share the exact steps you are doing to convert the images ? A screen recording would be best, or a few screenshots.

Please include some tools (view>studio) like

• 32 bit preview,
• info panel with a color sampler positioned to the problematic pixels,
• histogram,
• Your OCIO config (which OCIO version are you using? What parameters set in preferences for OCIO?)

Another difference: your screenshot shows RGBA combined, the file I opened shows them as separate layers. How did you transfer the A information to the RGBA layer? 

Update: I know have setup OCIO, this automatically combines the RGB+A to RGBA which answers my former question.

It makes a big difference if you do this step in RGB/32 (linear) or RGB/8 (gamma), as long as it stays a pixel layer it would undergo a gamma correction (which might be unwanted).

 

Edited April 2, 2022 by NotMyFault
switched to OCIO on my side to have better matching configuration

[NotMyFault]

I have seen you reporting other rendering issues before which where difficult to reproduce, e.g. https://forum.affinity.serif.com/index.php?/topic/133004-flattening-a-document-containing-specific-filters-causes-square-artifacts/&tab=comments#comment-733445

 

There is I chance that the issues are related to the actual hardware you are using. Do you have any chance to install Affinity on a different PC (without exotic hardware) to check if the issue occurs there, too?

A screenshot of Performance settings might help, too.

[NotMyFault]

I can confirm I get the same issues when directly exporting from RGB/32 to PNG in RGB/8 while OCIO is active.

The resulting document shows transparent pixels.

If I convert the document to RGB/8 and then export PNG (using same settings as before), exported file is ok.

 

[Alex_M]

I'm not able to record my screen currently, but I don't do anything out of the ordinary. I just open the EXR file and convert it to 8 or 16 bit. Please note that I have the following options enabled in settings (see below). Maybe try again with these turned on and you will see the bug. If you don't, it's probably because you're on a Mac and I'm on a Windows PC. The Windows and Mac versions of Affinity Photo are not exactly the same so it very well might be that the Mac version of Photo doesn't have this bug. I will try to record my screen when I have some free time.

[Alex_M]

10 minutes ago, NotMyFault said:

I can confirm I get the same issues when directly exporting from RGB/32 to PNG in RGB/8 while OCIO is active.

 

 

Interesting. So what do I need to do to not get this problem? Disable OCIO? How do I do that?

[NotMyFault]

The cause is a wrong value on alpha channel. It is larger than 1.

I use a PT filter ant take (A-1) which must be 0, and multiply it by powers of 2. 

Soon you start to see that A is a bit larger than 1.

To rectify the issue, you can use a pt filter with formula A=min(A,1) to correct the wrong values within the exr file.

The issue might be caused by using OCIO and (minimal but important) rounding issues.

Normally LUTs like OCIO should not impact alpha channel, and that they do is actually a bug in my perspective.

Never the less, it can be "healed" with that simple PT filter.

 

[NotMyFault]

Here the same file as above, with a corrective PT filter in the middle of the layer stack.

A channel is mapped to RGB to make the issue visible.

The PNG export is correct even when exported directly from RGB/32.

[Alex_M]

So I gather this is a bug, yes? Hopefully the Affinity technical team can chime in to confirm.

[NotMyFault]

5 minutes ago, Alex_M said:

So I gather this is a bug, yes? Hopefully the Affinity technical team can chime in to confirm.

+1.

Find the file with the corrective PT filter below for your convenience. You can save this as preset, or directly copy the layer into all other files until Affinity finds and fixes this bug in about 200 million years.

 

I wouldn't reject if you plan to give me a like or champ for volunteering to spend 1 hour investigating the issue, providing a simple and functional workaround, finding the root cause (which proves my initial assumption of out of bounds values).

One more example where Affinity stumbles with correct handling of the alpha channel.

exr2_cropped_bug_and_fix.afphoto

[NotMyFault]

Additional comment about what causes the bug:

the too high alpha value is present in you exr file, and not caused by Affinity. So the bug on Affinity is only inconsistent handling of out-of-bounds alpha values. When converting to RGB/8, there are capped at 1.0 automatically. Unfortunately, when exporting from RGB/32 to png (which must convert  RGB/8 or RGB/16 as PNG does not support higher bit depth) alpha is not handled properly and maybe causing an overflow, the values in PNG result in 0. This happens only if OCIO is active.

I cannot say if the OCIO version plays any role in this bug. 

I would rate this as minor bug, as it is totally easy to clip alpha with one filter. You should check the parameters of the tool producing the exr files, possibly there is an option to limit alpha channel to 1.0 which would avoid the issue directly on the source side.
 

 

 

[Dan C]

Hi @Alex_M &  @NotMyFault,

Apologies for the delayed response here - I can confirm I've logged this issue with our developers as a bug.

I hope this helps & many thanks for your report/further information provided