Compositor decodes DWAA/DWAB OpenEXR files improperly. #102963

New Issue

Cassidy Graces Incandela · 2022-12-05T22:33:00+01:00

2022-12-05 22:33:00 +01:00

System Information
Operating system: Windows-10-10.0.19044-SP0
Graphics card: AMD Radeon(TM) R5 Graphics 4.5.14831 Core Profile Context 21.5.2 27.20.21003.8013

Blender Version
Broken: 3.3.1, branch: master, commit date: 2022-10-04 18:35, hash: b292cfe5a9, type: release
Worked: 3.1.2, branch: master, commit date: 2022-03-31 17:40, hash: cc66d1020c, type: release

Short description of error
Opening OpenEXR encoded with DWAA/DWAB images in the compositor and connecting them to either Composite or Viewer node improperly decodes certain pixels with very-high float values as infinite. As a result these pixels are not displayed correctly and breaks the final composite.

Exact steps for others to reproduce the error
Example file:
infiniteFloatProblem.blend

Open the attached .blend file,
Render and save the image as either OpenEXR or OpenEXR Multilayer and set DWAA/DWAB as the codec,
Go to the Compositing tab,
Drag and drop the rendered image and connect it into the Image socket of the Composite node,
Either hit render and go to Rendering tab or use Viewer node to view it directly in the compositor,
Observe certain pixels with one of either R, G, B, or all of them as infinite.

Example of error (this is from the project where I encountered this problem).
This is the sun from the Nishita sky texture. Stretched because of motion blur (expected). Max RGB values was around 65000 (expected).
Pay attention to the RGB values informed below the render.

Example of how it breaks the final composite.
This was a result of the broken pixels being processed through various compositing nodes, which includes Add and Glare nodes.
Pay attention to the RGB values informed below the render.

Notes
There is a temporary fix (or rather, a workaround) to this, which is to clamp the float values to whatever the highest float value in the image were, which in my case was around 65000.
This is how I do it.

I actually encountered this error back in 2021, in both Video Sequencer and Compositor (I apologize for not reporting it), but when I encountered it again today, I tried to reproduce the error in Video Sequencer but the image seems to have been properly displayed.

Thanks in advance!

**System Information** Operating system: Windows-10-10.0.19044-SP0 Graphics card: AMD Radeon(TM) R5 Graphics 4.5.14831 Core Profile Context 21.5.2 27.20.21003.8013 **Blender Version** Broken: 3.3.1, branch: master, commit date: 2022-10-04 18:35, hash: b292cfe5a936, type: release Worked: 3.1.2, branch: master, commit date: 2022-03-31 17:40, hash: cc66d1020c3b, type: release **Short description of error** Opening OpenEXR encoded with DWAA/DWAB images in the compositor and connecting them to either Composite or Viewer node improperly decodes certain pixels with very-high float values as infinite. As a result these pixels are not displayed correctly and breaks the final composite. **Exact steps for others to reproduce the error** Example file: [infiniteFloatProblem.blend](https://archive.blender.org/developer/F13998576/infiniteFloatProblem.blend) - Open the attached .blend file, - Render and save the image as either OpenEXR or OpenEXR Multilayer and set DWAA/DWAB as the codec, - Go to the Compositing tab, - Drag and drop the rendered image and connect it into the Image socket of the Composite node, - Either hit render and go to Rendering tab or use Viewer node to view it directly in the compositor, - Observe certain pixels with one of either R, G, B, or all of them as infinite. Example of error (this is from the project where I encountered this problem). This is the sun from the Nishita sky texture. Stretched because of motion blur (expected). Max RGB values was around 65000 (expected). Pay attention to the RGB values informed below the render. ![Screenshot (1).png](https://archive.blender.org/developer/F13998452/Screenshot__1_.png) Example of how it breaks the final composite. This was a result of the broken pixels being processed through various compositing nodes, which includes Add and Glare nodes. Pay attention to the RGB values informed below the render. ![Screenshot (2).png](https://archive.blender.org/developer/F13998471/Screenshot__2_.png) **Notes** There is a temporary fix (or rather, a workaround) to this, which is to clamp the float values to whatever the highest float value in the image were, which in my case was around 65000. This is how I do it. ![Screenshot (3).png](https://archive.blender.org/developer/F13998536/Screenshot__3_.png) I actually encountered this error back in 2021, in both Video Sequencer and Compositor (I apologize for not reporting it), but when I encountered it again today, I tried to reproduce the error in Video Sequencer but the image seems to have been properly displayed. Thanks in advance!

Cassidy Graces Incandela commented

2022-12-05 22:33:00 +01:00

Added subscriber: @cassidy

Richard Antalik commented

2022-12-06 04:13:42 +01:00

Added subscriber: @iss

Richard Antalik commented

2022-12-06 04:13:42 +01:00

Changed status from 'Needs Triage' to: 'Needs User Info'

Richard Antalik commented

2022-12-06 04:13:42 +01:00

I can reproduce this issue with version 3.3.0, but 3.5 alpha sems to work correctly. Please check latest alpha build from https://builder.blender.org/download/daily/.

Cassidy Graces Incandela commented

2022-12-06 04:28:49 +01:00

Thanks for the news! I apologize for not testing it there first before reporting this problem.
The problem is solved in Blender 3.5.0 Alpha, hash: 9cb061f4f0.

Thanks for the news! I apologize for not testing it there first before reporting this problem. The problem is solved in Blender 3.5.0 Alpha, hash: `9cb061f4f0`.

Cassidy Graces Incandela commented

2022-12-06 04:49:53 +01:00

I apologize for the inconvenience but I have an update: it is not entirely solved!

The compositor correctly displays those pixels but after going through various nodes, the problem persists.

These nodes include Add and Glare nodes.

I apologize for the inconvenience but I have an update: it is not entirely solved! The compositor correctly displays those pixels but after going through various nodes, the problem persists. ![Screenshot (4).png](https://archive.blender.org/developer/F13999607/Screenshot__4_.png) These nodes include Add and Glare nodes.

Richard Antalik commented

2022-12-07 06:18:03 +01:00

I have checked the values fed into exr writer and raw values going out of loader. To me it seems, that a value is converted to infinity within OpenEXR library and rather randomly. Such values are supported by EXR file format, so I would say these should be supported further down the pipeline, Unless there are performance downsides, in which case limiting values explicitly by nodes may be necessary.

Can you explain how this affects your work? If you can share .blend file where this causes problems with compositing I can check that.

I have checked the values fed into exr writer and raw values going out of loader. To me it seems, that a value is converted to infinity within OpenEXR library and rather randomly. Such values are supported by EXR file format, so I would say these should be supported further down the pipeline, Unless there are performance downsides, in which case limiting values explicitly by nodes may be necessary. Can you explain how this affects your work? If you can share .blend file where this causes problems with compositing I can check that.

Cassidy Graces Incandela commented

2022-12-07 07:13:53 +01:00

So this isn't a DWAA/DWAB thing? Because this isn't happening with any other encoders, even Pixar24, the other built-in lossy encoder. And it's surely isn't happening with any of the lossless encoders.

In #102963#1456073, @iss wrote:
Can you explain how this affects your work? If you can share .blend file where this causes problems with compositing I can check that.

As I have stated later in the task description, these broken pixels can't be processed properly throughout various nodes.

It creates this corrupted region, filled with pixels with indefinite RGB values. I just learned that "-nan(ind)" is what you'd get when you do forbidden math operations, e.g., dividing zero by zero.

And of course, this affects my work. This "hole" is pretty noticeable and renders my final composite unusable.
Also yes! I can share my composition .blend. This is my attempt at utilizing Glare nodes to create procedural lens flare effects.
{F14005765}
You can unmute "infFloatFix" to see how the final composite are pretty much supposed to look like.

So this isn't a DWAA/DWAB thing? Because this isn't happening with any other encoders, even Pixar24, the other built-in lossy encoder. And it's surely isn't happening with any of the lossless encoders. > In #102963#1456073, @iss wrote: > Can you explain how this affects your work? If you can share .blend file where this causes problems with compositing I can check that. As I have stated later in the task description, these broken pixels can't be processed properly throughout various nodes. ![Screenshot (2).png](https://archive.blender.org/developer/F13998471/Screenshot__2_.png) It creates this corrupted region, filled with pixels with indefinite RGB values. I just learned that "-nan(ind)" is what you'd get when you do forbidden math operations, e.g., dividing zero by zero. And of course, this affects my work. This "hole" is pretty noticeable and renders my final composite unusable. Also yes! I can share my composition .blend. This is my attempt at utilizing Glare nodes to create procedural lens flare effects. {F14005765} You can unmute "infFloatFix" to see how the final composite are pretty much supposed to look like.

Richard Antalik commented

2022-12-07 13:49:53 +01:00

Changed status from 'Needs User Info' to: 'Archived'

Richard Antalik closed this issue

2022-12-07 13:49:53 +01:00

Richard Antalik commented

2022-12-07 13:49:53 +01:00

In #102963#1456107, @cassidy wrote:
So this isn't a DWAA/DWAB thing? Because this isn't happening with any other encoders, even Pixar24, the other built-in lossy encoder. And it's surely isn't happening with any of the lossless encoders.

It seems to be DWAA/DWAB issue only, and so it's probably not great idea to sanitize input on each node. Since you can use different codec to prevent this behavior, and issue is on OpenEXR side, I can only suggest to report this to their tracker, but it may be, that this is normal behavior. I don't see anything wrong in our code, so will close this report. Thanks for reporting though, and if you have any more info, feel free to comment.

> In #102963#1456107, @cassidy wrote: > So this isn't a DWAA/DWAB thing? Because this isn't happening with any other encoders, even Pixar24, the other built-in lossy encoder. And it's surely isn't happening with any of the lossless encoders. It seems to be DWAA/DWAB issue only, and so it's probably not great idea to sanitize input on each node. Since you can use different codec to prevent this behavior, and issue is on OpenEXR side, I can only suggest to report this to their tracker, but it may be, that this is normal behavior. I don't see anything wrong in our code, so will close this report. Thanks for reporting though, and if you have any more info, feel free to comment.

Cassidy Graces Incandela commented

2022-12-08 12:57:51 +01:00

Hi there. I apologize for the inconvenience but I have another update.

Something seems to have changed in 3.4.0, because instead of converting to infinity, it's just "-nan(ind)" instead, which kind of makes the problem worse, because unlike infinity, non-number can't be mapped with Map Range, so the fix I provided in the task description doesn't work anymore. For now I have to stay in 3.3.1 because of this.

The weird thing is, in 3.4.0, the compositor seems to be working as expected, or to be precise, the Viewer Node. Things are different when rendered. I really have no knowledge about this but, the Viewer Node is doing something right that the Composite Node doesn't.

Viewer Node:

Composite Node:

I really apologize for bumping up archived tasks, but I thought this is an worthy info.

EDIT:
It's not just the Viewer Node that is working right. Exporting using the File Output node also works. No corrupted results.

Yes I acknowledge that this is an OpenEXR issue, but Blender is handling it both properly and improperly somehow.

EDIT:
Apparently this doesn't work for OpenEXR outputs, even if using ZIP codec. I apologize again for the inconvenience.

EDIT:
I found out anything about Viewer Node and File Output is just a nothing burger, it works as intended and has nothing to do with any of this. The only thing not working as expected is just that, the encoding converting values into -nan(ind) instead of inf. I deeply apologize.

Hi there. I apologize for the inconvenience but I have another update. Something seems to have changed in 3.4.0, because instead of converting to infinity, it's just "-nan(ind)" instead, which kind of makes the problem worse, because unlike infinity, non-number can't be mapped with Map Range, so the fix I provided in the task description doesn't work anymore. For now I have to stay in 3.3.1 because of this. The weird thing is, in 3.4.0, the compositor seems to be working as expected, or to be precise, the Viewer Node. Things are different when rendered. I really have no knowledge about this but, the Viewer Node is doing something right that the Composite Node doesn't. Viewer Node: ![Screenshot (9).png](https://archive.blender.org/developer/F14044691/Screenshot__9_.png) Composite Node: ![Screenshot (10).png](https://archive.blender.org/developer/F14044693/Screenshot__10_.png) I really apologize for bumping up archived tasks, but I thought this is an worthy info. **EDIT:** It's not just the Viewer Node that is working right. Exporting using the File Output node also works. No corrupted results. ![Image0037.png](https://archive.blender.org/developer/F14044731/Image0037.png) ![Image0037.exr](https://archive.blender.org/developer/F14044730/Image0037.exr) Yes I acknowledge that this is an OpenEXR issue, but Blender is handling it both properly and improperly somehow. **EDIT:** Apparently this doesn't work for OpenEXR outputs, even if using ZIP codec. I apologize again for the inconvenience. **EDIT:** I found out anything about Viewer Node and File Output is just a nothing burger, it works as intended and has nothing to do with any of this. The only thing not working as expected is just that, the encoding converting values into -nan(ind) instead of inf. I deeply apologize.

Richard Antalik commented

2022-12-08 14:37:45 +01:00

In #102963#1456743, @cassidy wrote:
Something seems to have changed in 3.4.0, because instead of converting to infinity, it's just "-nan(ind)" instead, which kind of makes the problem worse, because unlike infinity, non-number can't be mapped with Map Range, so the fix I provided in the task description doesn't work anymore. For now I have to stay in 3.3.1 because of this.

I can't reproduce this, if I use Lens Distortion on same EXR image, I get same result in 3.3 as I do int 3.4

> In #102963#1456743, @cassidy wrote: > Something seems to have changed in 3.4.0, because instead of converting to infinity, it's just "-nan(ind)" instead, which kind of makes the problem worse, because unlike infinity, non-number can't be mapped with Map Range, so the fix I provided in the task description doesn't work anymore. For now I have to stay in 3.3.1 because of this. I can't reproduce this, if I use Lens Distortion on same EXR image, I get same result in 3.3 as I do int 3.4

Cassidy Graces Incandela commented

2022-12-08 15:36:39 +01:00

I got a bunch new information.

Since 3.4.0, Blender seems to ignore infinite values in the compositor. When I open an OpenEXR file containing infinite values in the Image Editor, it says "inf" and when I open it from the compositor and connect it right to the Composite Node, it says "-nan(ind)".
I was able to workaround this by mapping each RGB values like before, and run it through Anti-aliasing node.

I can now work with 3.4.0 with this new fix, so I'll leave it at that and this report as closed.

In #102963#1456837, @iss wrote:
I can't reproduce this, if I use Lens Distortion on same EXR image, I get same result in 3.3 as I do int 3.4

I apologize for the confusion. I wrote that comment before I found out why it was behaving that way, and I now have updated my workaround.
I have reported this to OpenEXR's tracker so I'll wait for that and comment here with any update, if I'll get one.

I got a bunch new information. Since 3.4.0, Blender seems to ignore infinite values in the compositor. When I open an OpenEXR file containing infinite values in the Image Editor, it says "inf" and when I open it from the compositor and connect it right to the Composite Node, it says "-nan(ind)". I was able to workaround this by mapping each RGB values like before, and run it through Anti-aliasing node. ![image.png](https://archive.blender.org/developer/F14044890/image.png) I can now work with 3.4.0 with this new fix, so I'll leave it at that and this report as closed. > In #102963#1456837, @iss wrote: > I can't reproduce this, if I use Lens Distortion on same EXR image, I get same result in 3.3 as I do int 3.4 I apologize for the confusion. I wrote that comment before I found out why it was behaving that way, and I now have updated my workaround. I have reported this to OpenEXR's tracker so I'll wait for that and comment here with any update, if I'll get one.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Compositor decodes DWAA/DWAB OpenEXR files improperly. #102963