Vray 3.6 cryptomatte does not work with DWA compression

[sharktacos]

So I have the Nightlies installed from vray_adv_36004_maya2017_x64_27950. Is this the correct one?

Assuming it is, I'm wondering if perhaps the Nuke Cryptomatte gizmo needs to be updated to work with these new Vray rendered EXR images?
If I render out a multi-channel EXR with a Cryptomatte RE in Maya, and connect it to a Cryptomatte node in Nuke, I do not get the expected mattes as I did previously, but rather get the beauty with green tint over it. So clearly something is wrong.

The Nuke Cryptomatte node works fine with other renders, including the sample image from the Cryptomatte Github page.

[vasil.minkov]

So I have the Nightlies installed from vray_adv_36004_maya2017_x64_27950. Is this the correct one?

Assuming it is, I'm wondering if perhaps the Nuke Cryptomatte gizmo needs to be updated to work with these new Vray rendered EXR images?
If I render out a multi-channel EXR with a Cryptomatte RE in Maya, and connect it to a Cryptomatte node in Nuke, I do not get the expected mattes as I did previously, but rather get the beauty with green tint over it. So clearly something is wrong.

The Nuke Cryptomatte node works fine with other renders, including the sample image from the Cryptomatte Github page.

Could you sens us DWA and ZIP compressed EXR files for investigation? A Nuke script and Maya scene could also be helpful.

Best Regards,
Vasil

[sharktacos]

Okay I got it working. The two problems I was having were:

1) Cryptomatte only works in batch render. Saving a multi-channel EXR from the VFB does not work. This was causing the "green tint" in the Cryptomatte Nuke node that I described above.

2) Cryptomatte does not work with DWAB if "write multi-part EXR" is ON in the Vray Output Image Options. Turn it off and it works fine.

It might be good to mention these in the docs, perhaps along with the comment that is currently there about the need for bucket rendering with Cryptomatte.

[vasil.minkov]

Okay I got it working. The two problems I was having were:

1) Cryptomatte only works in batch render. Saving a multi-channel EXR from the VFB does not work. This was causing the "green tint" in the Cryptomatte Nuke node that I described above.

2) Cryptomatte does not work with DWAB if "write multi-part EXR" is ON in the Vray Output Image Options. Turn it off and it works fine.

It might be good to mention these in the docs, perhaps along with the comment that is currently there about the need for bucket rendering with Cryptomatte.

Thank you for the pointers! It will be even better if we fix these issues.

Best Regards,
Vasil

[Jimmi]

2) Cryptomatte does not work with DWAB if "write multi-part EXR" is ON in the Vray Output Image Options. Turn it off and it works fine.

Anybody know if this has been fixed or will be?
Would be lovely to be able to use multipart when having to use multi-channel.
(as a side question, can anybody confirm weather or not the Denoiser element works with DWA and Multi-Part Exr files?)

Jimmi

[sharktacos]

I'm observing that an EXR file using DWA compression is significantly larger than one without Cryptomattes. This is somewhat expected since the Cryptomatte RE needs to be saved with ZIP compression rather than JPG in order to preserve the matte lines. So I get why it's larger (around twice the size).

At the same time, having several Multimatte REs does not seem to bump up the file size drastically, and I would expect that they would also need to have quality matte lines too. So I'm wondering if there was a way to do to the Cryptomattes whatever voodo was done to the multimattes so that we could have functional Cryptomattes AND also the small file size of DWA compression?

I'm not quite sure what's going on with the Multimattes that allow them to work and still be compressed small. But I'm hoping that the brainiacs at Chaos might have some ideas.

[vasil.minkov]

Unfortunately OpenEXR does not support ZIP compressed channels in DWA files. It only supports lossy DCT and lossless RLE compression. Cryptomattes in DWA files are stored using RLE compression scheme.

[sharktacos]

Understood, thanks for the reply.

[sharktacos]

In regards to reducing the file size of an EXR with Cryptomatte REs, Jonah (the developer of Cryptomatte at Psyop) was saying that in the new version for Arnold (ALshaders) they drop the deprecated "crypto_object" preview channels, which are not needed, and only keep "crypto_object00", "crypto_object01", etc. The latter, with numbers on the end, contribute to the matte, the others were used for preview by the decoders in past versions but are no longer needed. Those preview channels are not used at all, all they do is take up disk space. https://groups.google.com/forum/#!to...rs/lyZRFbA77LY

See the notes for beta3:

• False (default): Omit preview channels when EXR drivers are being used
• True: Keep behavior as usual

https://github.com/anderslanglands/alShaders2/releases


Perhaps removing the equivalent preview channels from V-Ray's implementation of the Cryptomatte RE would also help reduce the large file size? Just wanted to make sure this was on your radar.

[sharktacos]

Unfortunately OpenEXR does not support ZIP compressed channels in DWA files. It only supports lossy DCT and lossless RLE compression. Cryptomattes in DWA files are stored using RLE compression scheme.

FWIW, this is from the notes for OpenEXR on github specifically in regards to DWA compression: (https://github.com/openexr/openexr/b...ressor.cpp#L39)

// First, we try and figure out what compression strategy to take

// based in channel name. For RGB channels, we want a lossy method

// described below. But, if we have alpha, we should do something

// different (and probably using RLE). If we have depth, or velocity,

// or something else, just fall back to ZIP.

From this it would appear that ZIP compression is supported for DWA files.

Using ZIP compression on Cryptomattes would result in smaller file sizes than RLE. When I render an EXR with ZIP scanline half-float (not DWA) currently in V-Ray the Cryptomatte RE seems to work fine in Nuke, so it would be worth a shot to see if using ZIP compression with DWA for Cryptomatte (as is done for depth or velocity) would work too.

[dougWilkinson]

Using ZIP compression on Cryptomattes would result in smaller file sizes than RLE. When I render an EXR with ZIP scanline half-float (not DWA) currently in V-Ray the Cryptomatte RE seems to work fine in Nuke, so it would be worth a shot to see if using ZIP compression with DWA for Cryptomatte (as is done for depth or velocity) would work too.

seems to work in vraynext beta 3

[sharktacos]

Neat. I’ll take a look, thanks.