@joe_vfx, I tried to rename the metadata as suggested. Doesn’t work. Mine says View Layer.CryptoObject (with a space between View and Layer, which is strange) instead of RenderLayer.CryptoObject. I tried with and without a space. I tried to use RenderLayer instead of View Layer. Nothing.!
I updated the cryptomatte plugins to the latest version (2020!) and it still doesn’t work even though it was supposed to fix the Blender cryptomatte issue.
Any suggestions?
Which settings do you have in blender? Can you send me a screenshot of them (especially the layernames). With the new version of the cryptomatte plugin in Nuke it should work even without the Metadata node…
So I think that there is something wrong with you Layer names in Blender.
Can you please re-download the plug-in from PsyOp? They merged a fix I provided yesterday. Then try again in Nuke if that fixes it. If not, please consider to provide a simple blend file for testing the problem.
Have you tried renaming “View Layer” to something different? (Without a space in the name)
Whooho! We have a winner! I updated to the latest version of Cryptomatte and it’s working. I also tried with a space in the layer name but it made no difference. Nuke adds the “_” automatically. Now I only need two more things to make me switch completely form Maya to Blender: Proper UDIMs and support for VDB caches. The more I use Blender the more I like it. Thank you all for the help!
sorry, U updated what?
I updated the cryptomatte plugin. https://github.com/Psyop/Cryptomatte
Just for reference:
On the most recent Cryptomatte version 1.2.5 on Fusion here and still no luck getting Cryptomatte to work reliably.
I have only looked at the implementation of Cryptomattes in Nuke when submitting that patch. Could you please provide a sample image and a screenshot in fusion to see how you try to pull the mattes?
Hi there,
Not sure if this has been answered already, but I’m having the same issue with Blender 2.93.5 and Fusion.
When I export the Crypto Matte pass as Open EXR Float (Full) and import the file in Fusion I get this error in Fusion console:
[Cryptomatte][Cryptomatte1][ERROR] no cryptomatte metadata found
I’m using the latest Cryptomatte plugin 1.4 for Fusion.
Just to understand what I need to investigate, has the missing metadata been fixed in Blender?
Blender still produces the same metadata as before. They follow the industry standard specification, as Brecht once pointed out.
Check if your view layer name contains special characters. Especially spaces throw off the metadata reading for Nuke. Try with a simple name, like “AAA”, and check if the metadata is then found by Nuke.
I suspect with Fusion it might be similar. If I have some time this week I can check
I’ve made two changes in Blender 3.0 to try to improve the situation here, avoiding usage of dots and spaces in view layer names (by default) and AOV names (always).
It’s not entirely foolproof, but I prefer not to add too many restrictions on these names just because other software has bugs or arbitrary restrictions. Hopefully in time they will catch up.
I don’t have any problems with Blender 3.0.0 master and Cryptomatte 1.4.0 in Fusion (installed via Reactor).
But Nuke Cryptomatte currently refuses to accept even the most simple multilayer EXR from the same Blender version. Even if the View Layer and AOV names contain only the most simple characters.
Can anyone here try e.g. this EXR in Nuke?
@SteffenD I just tried your EXR.
It doesn’t work out of the box but you can replace the dots in the names with an underscore to make it work.
With Brechts latest change this shouldn’t be needed anymore I hope.
Wow… thanks for the quick help. Who would’ve thought a simple point made such a difference 
P.S.: I totally agree with @brecht on that it’s not Blender’s job to help “crippled” other software by limiting Blender, but in this case Nuke has a huge market share and many users might think that it’s Blender’s fault if Cryptomatte isn’t working out of the box, which might shine a bad light on Blender.
They might think “Nuke is an industry standard and therefore sets the standards” (which is totally not my opinion, just look at the state of OpenEXR in Adobe’s product range, ugh!).
So maybe it’s OK to avoid/replace points until Nuke’s Cryptomatte finally supports them?
Wait, my change does not remove the dot between the layer and pass name. It merely tries to make sure there is none in the layer or pass name.
Maybe Nuke just doesn’t deal well with the layer/pass distinction at all, and it would be better to have an option to write each view layer to a separate EXR file?
The Cryptomatte issue I think is clearly a bug in Nuke, where the parsing of the OpenEXR channels and the OpenEXR metadata are inconsistent. It would be nice if we had a simple way to work around that bug, but it’s not really clear to me now.
Obviously the simple “fix” @ManuelGrad just posted helps to make Nuke happy. Or am I missing something?
BTW today I noticed that Redshift forcibly outputs a separate EXR when outputting Cryptomatte AOVs, even when it’s set to output a multilayer EXR. Maybe this comes from the same limitation in “industry standard” compositing software?
Forcibly outputting a separate Cryptomatte sequence can make a lot of sense.
This enables you to write out your cryptomatte pass as 32bit and your beauty + all other passes as 16bit exrs. But as far as I remember thats a huge hassle to set up in Blender to get a separate cryptomatte pass that works, maybe that has changed by now, dont know.
