Fix for OpenEXR erroneous semi-transparent pixels
AbandonedPublic

Authored by dkazakov on Feb 4 2019, 4:18 PM.

Details

Reviewers
rempt
jhoolmans
Group Reviewers
Krita
Summary

When loading an .exr file with very low alpha channels, these alpha pixels seem to turn fully opaque.
Currently we raise the alpha values in a loop to prevent buffer overflows, and the resulting alpha can become 1.0 in some cases.
This happened more frequently with 16-bit float images.

Diff Detail

Repository
R37 Krita
Lint
Lint Skipped
Unit
Unit Tests Skipped
jhoolmans created this revision.Feb 4 2019, 4:18 PM
Restricted Application added a reviewer: Krita. ยท View Herald TranscriptFeb 4 2019, 4:18 PM
jhoolmans requested review of this revision.Feb 4 2019, 4:18 PM
rempt added a subscriber: rempt.Feb 6 2019, 10:49 AM

This patch not only removes a hack, it also loads the CandleGlass.exr file from the openexr website more correctly. Left is 4.1.7, right is master with this patch applied:

rempt accepted this revision.Feb 6 2019, 10:49 AM
dkazakov requested changes to this revision.Feb 7 2019, 4:43 PM

The patch restores the bug that this "unmultiplication" was fixing. To test the issue, CandleGlass.exr image should be viewed on black background.

Before the patch:

After the patch:

The problem is that EXR supports pixels that "emit light". They have no own alpha and do not take part in normal blending, but they add exposure to the image.

I don't know why these black artifacts on transparent background appear. They were not present when this workaround was implemented, so the problem might be in some other place.

This revision now requires changes to proceed.Feb 7 2019, 4:43 PM
rempt added a comment.Feb 7 2019, 5:02 PM

Um... Shouldn't Krita load the image, as it is, correctly in the first place? Which we don't do, right now, without this patch.

  1. EXR images are not supposed to be viewed on transparent background. They are "light source"
  2. With this patch we load it incorrectly anyways. See blue artifacts on the flame.

I agree that there is some regression with these black stuff in the image. But I don't think it is related to the unmultiplication code. It should be fixed in some other way (needs investigation, in which one)

Just to make it clear, when the unmultiplication code was initially written, there were no these artifacts on the transparent background. It is some regression in another place.

The problem is this commit 5f02b6cf33b5bb87889d40e2bad4115f4575e357

For some reason abs is nto defined for half type.

dkazakov commandeered this revision.Feb 7 2019, 6:34 PM
dkazakov edited reviewers, added: jhoolmans; removed: dkazakov.
dkazakov requested review of this revision.Feb 7 2019, 6:35 PM
dkazakov abandoned this revision.

The blue part is a bug in the alpha value becoming zero. I have to double check.
With the current master there is still the issue of modified alpha values which is noticeable with soft shadows and shouldn't happen.
I agree that EXR are some sort of light emission, it's also raw data that should not be modified in any way.
What the patch is doing here is basically a max(epsilon, alpha) as mentioned in here http://www.openexr.com/documentation/TechnicalIntroduction.pdf

Even though it's hard to see, you can see clipping in those areas. Left one is master, right one is with this patch.

32-bit version of the CandleGlass exr.