Cryptomatte false colors on overlapping geometry - not usable

[amaurer]

Hi there,

In VRED 2020 and 2021 the cryptomatte implementation is not usable as it produces mixed colors between two objects/materials. Please have a look at the screenshots.

- beauty pass (top left)

- cryptomatte00 (top right) where you can see the false blueish color between the objects 

- cryptomatte01 (bottom left) where you can see the false color only object

- bottom right: i used two grade nodes to grade object a and b separately to black and what is left is the false part between the two.

I also attache the vred file and my  test exr from 2020.2

Can anybody confirm this ?

Thanks,

Andy

[michael_nikelsky]

There have been a couple of issues with cryptomatte in the past but they should be fixed in the current 2021.3. I don´t quite understand what you mean by mixed colors. For each pixel the cryptomatte passes contain a hash-value and a weight for an object/material that contribute to the pixel. Up to 6 objects and 6 materials per pixel can be separated by this information (in 6 cryptomatte images with 4 channels each). There are no colors in a cryptomatte pass, the compositing tool is responsible for correctly separating the values based on this information. 

[amaurer]

Hi Michael,

i checked 2021.3 and the output is still the same. If you have a chance please check the files with nuke

[amaurer]

For comparison, this is how a correct crypto from vray looks like. No "third" color between objects!

[michael_nikelsky]

I don´t have access to Nuke but tried it out in Natron. The raw values in the cryptomatte pass are correct. There are two entries other than 0 and their respective weights sum up to 1. I am not sure why the separation doesn´t work as expected.

[michael_nikelsky · Accepted solution]

I think I understand what "false" colors you mean but they are not false. The cryptomatte passes are not designed to be looked at in an image viewer. As I have already written: Each pixel encodes a hash value, a 32bit unsigned int value that is stored as a float value in the image. It is not a color value. This for example is a totally valid cryptomatte image:

 

The color values are from a pixel between those two objects. The red channel is the hash value of the first object, the green channel is its weight. The blue channel is the hash value of the second object and the alpha channel is the corresponding weight for that. At one point however these are flipped, the second object´s hash and weight will be in the red/green channels and the first objects will be in the blue/alpha channels. I assume this is what you interpret as third color showing up but this isn´t the case. It is just the sorting of weights instead of sorting by id´s. The specification does not require any sorting however so any implementation supporting cryptomatte should be able to correctly separate the values accordingly, no matter what order they are in. 

I am not sure how exactly the Nuke Plugin for cryptomatte works. A full implementation should just give you a list of object/material names to choose from and give you the correct mask for it. Photoshop doesn´t have this but using the EXR-IO Plugin you at least get a layer with a proper mask for each Object (don´t turn on the transparency option for it though, looks like photoshop is still not able to handle alpha masks correctly). If you do that and check all the values at the region in question you will see that the sum of the mask values for a pixel will be one where multiple objects overlap.

[matthias.richter]

I tested the attached OpenEXR in Fusion and can confirm that the cryptomatte works fine. No edges between objects neither when using cryptoObject nor cryptoMaterial layer. Grading works as it's supposed to work.

Matthias

[amaurer]

Thanks all for the clarification and help! I think i was mislead to this with some wrong assumptions indeed by looking at the raw cryptomatte !

Thanks for your time!