Page MenuHome

Add option to write Nuke-compatible metadata
AbandonedPublic

Authored by Rainer Trummer (aliasguru) on Jul 11 2019, 5:21 PM.

Details

Summary

As discussed on this thread on DevTalk, the external compositing application Nuke internally renames the various layers of an OpenEXR image on import, removing characters like spaces and dots. Nuke does this because it interprets anything after dots as channels.

This patch adds an option to the Preferences, which - if set to 'Nuke Compatible' - replaces such characters in the metadata channel names only. I tried doing the same for layer names, but soon figured that Blenders image editor doesn't appreciate that. In fact, it either does not recognize what was a View Layer and what was a Pass before, or even crashes when loading / displaying such an image. Since this is technically not even necessary (the metadata names only need to match layer names in case of Cryptomattes as far as I am aware), I stuck with only adapting the metadata and nothing else.

Access the Metadata generation mode from the Preferences:

You can verify the output in the Image Editor after rendering:

The default is of course Blender.

Diff Detail

Event Timeline

From my understanding, there exists a fix for this issue in Cryptomatte Nuke plugin:
https://github.com/Psyop/Cryptomatte/issues/104

Is this still needed for the latest version of that plugin?

If it is, can you explain how this issue is different?

What I was thinking of in devtalk was configuration to change not just the metadata, but also the names of the layers themselves.

Otherwise it's writing out EXR files that have inconsistent names for layers and their metadata, which is basically writing an invalid file to compensate for an issue in Nuke or the Cryptomatte plugin.

So I'd really prefer to avoid doing that if possible.

What I was thinking of in devtalk was configuration to change not just the metadata, but also the names of the layers themselves.
Otherwise it's writing out EXR files that have inconsistent names for layers and their metadata, which is basically writing an invalid file to compensate for an issue in Nuke or the Cryptomatte plugin.
So I'd really prefer to avoid doing that if possible.

I would have preferred that too, but as mentioned above, when trying that, I cause more trouble in handling such EXR files in Blender itself if I change the Layer names (Image Editor crashing). However, I was not aware of the Plugin update, we will test that next week when my Nuke user is back at work. If that resolves the problem, then this patch can happily be abandoned. I'll report back next week with the test results.

From my understanding, there exists a fix for this issue in Cryptomatte Nuke plugin:
https://github.com/Psyop/Cryptomatte/issues/104
Is this still needed for the latest version of that plugin?
If it is, can you explain how this issue is different?

On my side the latest cryptomatte nuke plugin version 1.2.4 is working for Blender exr's.

@Bintang Senja Pratama (bintang) The updated plugin half-fixes the problem. However, a more complete fix could be done by updating the plugin following the suggestion here. Currently the metadata matching will still fail, because a View Layer name like "View Layer" (which is the default) will turn into "View_Layer" in Nuke. The plugin at the moment does not compensate that. However, bottom line is, there is no real need to change Blender itself for this, so the revision here can be closed / abandoned. I will update it once today just to provide the exact same fix as I suggested for the plugin, just for completeness sake.

updated revision to replace any non-alpha-numeric input

Abandoning revision then.