ImageWriter: Issue with Nuke Style Multipart EXR

[jedypod]

Version: Gaffer 1.5.0.0-linux (e.g. 0.47.0.0-linux)

Description

At IE, we recently ran into a perplexing issue when trying to configure Gaffer to render Nuke style multipart EXRs for a client delivery including mattes. Unfortunately since the client is using Nuke to QC our work, we are forced to match the non-standard behavior of Nuke rather than the EXR spec.

We start with a multipart render from Nuke of a checkerboard and an extra layer named circle containing a channel named matte, rendered from a Nuke write node with the interleave knob set to channels in order to create a multipart exr.

If we load this into Gaffer, and render a multipart exr with the default settings (Layout = Par per Layer) to create a multipart matching the exr spec, we get something that mostly looks right in Nuke, except that the extra layer is named circle_circle.

If we render from Gaffer instead with Layout = Nuke/Interleave Channels, we get something that is even more messed up. rgba is renamed to rgba_main and circle is renamed to circle_main.

Comparing the file layout using exrheader of this last exr vs the original one from Nuke, we can see that they are identical except for the view (type string): "main" entry in each part in the exr from Nuke. Thanks to Daniel Dresser, we managed to figure out that if we add a CreateViews node in Gaffer before the ImageWriter, delete the left view, and set the first view to "main", the result comes out correctly with that extra view: main metadata populated, and it reads correctly in Nuke and everything matches.

This is a functional workaround, but it is rather obscure and might be a bit frustrating for others who run into the same behavior. So I figured it would be useful to make an issue about it here. My question is: since we are already renaming the layer name to <layerName>.main to be consistent with Nuke, is there a reason we couldn't also add that view: main entry so that the nuke multipart compatibility mode works out of the box?

Thanks for your help!

[johnhaddon]

My question is: since we are already renaming the layer name to .main to be consistent with Nuke, is there a reason we couldn't also add that view: main entry so that the nuke multipart compatibility mode works out of the box?

I think automatically adding the main entry would be completely consistent with our intentions around the Nuke modes - to do whatever weird off-spec stuff is necessary to interoperate well. @danieldresser, seems like this should be reasonably doable?

What do we want to do about backwards compatibility? Would we say this is a bugfix and call it good, or do we think someone could be relying on the current behaviour? Seems like we don't want to wait for 1.6 to fix this, so if we're concerned at all, maybe we could use an environment variable to allow people to opt-out for now.

[jedypod]

What do we want to do about backwards compatibility?

For us at IE, I don't think we would need to worry about preserving this behavior in older versions. Calling this a bugfix changing the behavior should be fine for us.