Is there any info/documentation on what the Blender Cryptomatte compositor node expects when using an image as a source? For some reason, when we use the node with the cryptomatte output from our render engine, it comes out blank.
I don’t think it’s a problem with the EXR’s themselves, as they work as expected with Nuke and AfterEffects.
We renamed our AOVs this way, which seemed to make them work with blender’s compositor node: RPRBLND-1984: Add New Cryptomatte workflow support. (#443) (#512) · GPUOpen-LibrariesAndSDKs/RadeonProRenderBlenderAddon@d0ba8fe · GitHub
Thanks, Brian. I’ll try renaming the channels in the EXR file and see if that works.
Yes I see,
We should perhaps parse the available meta data in stead of relying on the names. If someone can send me a file from a different source I can see how we can improve this. The upcoming month we do want to do some small changes around cryptomatte. Mostly adding support for Eevee-next.
Jeroen
Hi Jeroen,
Let me know if this google drive link doesn’t work for you. It’s a zip file that includes the cryptomatte EXR and the beauty.
https://drive.google.com/drive/folders/10F-U8a5gHoU-MGsAQJ-1H-8PJb9KA3Gt?usp=sharing
Thanks,
Ian
I had no issue using the OpenEXR file with the Cryptomatte node.
It reads the meta data from the image. There might be some difference when it is stored as a
render result (@bsavery) If that is the case we should use the metadata as well for external
render engines.
The challenge for render results is that the cryptomatte layers are only known after the first render. Hence for render results it is fixed to CryptoObject/Material/Asset.
Thanks, @Jeroen-Bakker
It looks like something got fixed in 3.2, as I’m now getting the right matte when I upgraded
. However, when I plug the image to the Image socket, it doesn’t seem to line up. I’m guessing the node is not correctly reading the dataWindow/displayWindow in the exr file(s)?
It should have worked since the initial release.
And yes Blender doesn’t support those yet.
