Page MenuHome

OpenEXR layers from View Layers with names containing a period can't be read by Nuke
Closed, ArchivedPublic

Description

System Information
Operating system: Windows
Graphics card: GeForce RTX 2080 Ti

Blender Version
Broken: 2.82

Short description of error
OpenEXR file reading generally assumes a layer naming convention of layer.channel. If Blender's View Layer names contain periods, these names lead to problems within certain software. It's arguably said software's problem rather than Blender's (RV reports and displays everything just fine, Nuke doesn't) but given that Blender is not working per the convention, I think this might be fixed more easily on Blender's side than on other software's.

Exact steps for others to reproduce the error

  1. Have one View Layer with a period in its name, and one without. (e.g. Sets and Sets.Glass)
  2. Render and save a multi-layer OpenEXR file with both layers, and load it in Nuke.
  3. The Sets.Combined channel will load just fine (as Sets_Combined), but Sets.Glass.Combined will show up as Sets_Glass.Combined_R, _G, _B and _A. These names are not present in the file so no data is accessible.

This looks like some weird . and _ replacing on Nuke's part, which I agree seems very unnecessary, but could be avoided altogether if Blender would stick to the naming convention.

Event Timeline

Sam Van Hulle (sam_vh) updated the task description. (Show Details)
Sam Van Hulle (sam_vh) updated the task description. (Show Details)
Dalai Felinto (dfelinto) lowered the priority of this task from 90 to 30.Nov 14 2019, 9:46 PM

I don't get it. Why don't you simply NOT use . in your view layer names?

But I suppose we "could" replace . by _ when saving them. But to help moving this further, please:

There is no 2.82 release yet. Can you see if it happens with the official 2.80 and also 2.79 (we changed somethings after 2.7x)?

Also, as per our instructions lease attach a simple sample file reproducing the issue. And in this case a EXR would help too.

Sam Van Hulle (sam_vh) raised the priority of this task from 30 to 90.Nov 15 2019, 10:03 AM

I don't get it. Why don't you simply NOT use . in your view layer names?

That's obviously my workaround now. I'm simply pointing out that Blender isn't following a common convention, and its own convention is to use periods in *all* datablock naming, including view layers. Which I happen to prefer over anything else for a number of reasons.

I call this a bug because of both the convention and the fact that it confuses the hell out of people when a) they want to stick to Blender's datablock naming convention, but b) also want to read Blender EXRs in industry standard software. At first, I honestly thought I had reached some EXR layer count limit.

Can you see if it happens with the official 2.80 and also 2.79

I used a master build from a few days ago... maybe it still says 2.81, I didn't check. I can check 2.80 and 2.79 after the weekend, but I don't really see how that has more value than a recent build.

Also, as per our instructions lease attach a simple sample file reproducing the issue.

The instructions say sample file or default startup file, in this case the steps to reproduce are obviously based on the latter as I didn't see the point of uploading a blend file with one more view layer than by default. I can provide an EXR after the weekend, but honestly, it takes 10 seconds to make one.

Philipp Oeser (lichtwerk) lowered the priority of this task from 90 to 80.Nov 15 2019, 1:23 PM

Just putting out the relating information from OpenEXR itself:
https://www.openexr.com/documentation/ReadingAndWritingImageFiles.pdf

Under Layers we find:

In an image file with many channels it is sometimes useful to group the channels into layers, that is, into setsof channels that logically belong together.  Grouping channels into layers is done using a naming convention:channel C in layer L is called L.C.

For example, a computer-generated picture of a 3D scene may contain a separate set of R, G and B channels for the light that originated at each one of the light sources in the scene.  Every set of R, G, and B channels is in its own layer.  If the layers are called light1, light2, light3, etc., then the full names of the channels in this image are light1.R, light1.G, light1.B, light2.R, light2.G, light2.B, light3.R, and so on. 

Layers can be nested; for instance, light1.specular.R refers to the R channel in the specular sub-layer of layer light1.

Channel names that do not contain a ".", or that contain a "." only at the beginning or at the end are notconsidered to be part of any layer.

Class ChannelList has two member functions that support per-layer access to channels: layers() returns the names of all layers in a ChannelList, and channelsInLayer() converts a layer name into a pair ofiterators that allows iterating over the channels in the corresponding layer.

Without having a deeper look (I havent checked how the names are actually ending up when blender writes them), I am reading this as Sets.Glass.Combined would be a valid name for layer/sub-layer?
(Unless a deeper nesting is not allowed? Maybe there is no layer.sublayer.sublayer.channel allowed?)

note: looks like we are not using the above ChannelList.layers() + channelsInLayer() (OpenEXR documented) method, but cooking our own as well, see imb_exr_split_channel_name / imb_exr_split_token but this seems to come down to the same...

Adding an example file to the report description.
Output of exrheader of that file giving the channels as we write them [but that was also expected]:

file format version: 2, flags 0x400
BlenderMultiChannel (type string): "Blender V2.55.1 and newer"
Camera (type string): "Camera"
Date (type string): "2019/11/15 13:32:16"
File (type string): "/.../T71574/T71574.blend"
Frame (type string): "1"
RenderTime (type string): "00:02.54"
Scene (type string): "Scene"
Time (type string): "00:00:00:01"
channels (type chlist):
    Composite.Combined.A, 32-bit floating-point, sampling 1 1
    Composite.Combined.B, 32-bit floating-point, sampling 1 1
    Composite.Combined.G, 32-bit floating-point, sampling 1 1
    Composite.Combined.R, 32-bit floating-point, sampling 1 1
    Sets.Combined.A, 32-bit floating-point, sampling 1 1
    Sets.Combined.B, 32-bit floating-point, sampling 1 1
    Sets.Combined.G, 32-bit floating-point, sampling 1 1
    Sets.Combined.R, 32-bit floating-point, sampling 1 1
    Sets.Depth.Z, 32-bit floating-point, sampling 1 1
    Sets.Glass.Combined.A, 32-bit floating-point, sampling 1 1
    Sets.Glass.Combined.B, 32-bit floating-point, sampling 1 1
    Sets.Glass.Combined.G, 32-bit floating-point, sampling 1 1
    Sets.Glass.Combined.R, 32-bit floating-point, sampling 1 1
    Sets.Glass.Depth.Z, 32-bit floating-point, sampling 1 1
    Sets.Other.Combined.A, 32-bit floating-point, sampling 1 1
    Sets.Other.Combined.B, 32-bit floating-point, sampling 1 1
    Sets.Other.Combined.G, 32-bit floating-point, sampling 1 1
    Sets.Other.Combined.R, 32-bit floating-point, sampling 1 1
    Sets.Other.Depth.Z, 32-bit floating-point, sampling 1 1

The instructions say sample file or default startup file, in this case the steps to reproduce are obviously based on the latter as I didn't see the point of uploading a blend file with one more view layer than by default. I can provide an EXR after the weekend, but honestly, it takes 10 seconds to make one.

It's not about how much time is spent making them. It's about being 100% sure we're looking at the same thing as you are.

Without having a deeper look (I havent checked how the names are actually ending up when blender writes them), I am reading this as Sets.Glass.Combined would be a valid name for layer/sub-layer? (Unless a deeper nesting is not allowed? Maybe there is no layer.sublayer.sublayer.channel allowed?)

I haven't really found anything about sublayer.sublayer - this might very well be Nuke making an undocumented judgement call, making this bug perhaps better reported to them instead.

To me it looks like Blender adheres to the OpenEXR documentation, so from what I can see it's not a bug.

Brecht Van Lommel (brecht) changed the task status from Unknown Status to Unknown Status.Nov 21 2019, 2:54 PM
Brecht Van Lommel (brecht) claimed this task.

Blender was an early adopter of OpenEXR, and followed the specification. Other applications did not and now there is this incompatibility.

This is a known issue that we in the past we have not considered a bug.

It may be addressed as part of T68924: OpenEXR pipeline improvements.