split cryptomattes to 32bits!

[houourin]

Now when activating the new option save cryptomattes in a separate file it seems to use the same bit rate as the main pass. for instance if the main pass is set to 16bit float it will save the cryptomatte to 16bit float.
But from what I understand Cryptomatte should be used only with 32bit float.

Seems, from what i've heard, Arnold saves always the cryptomatte in 32bit regardless the main ouptut setting, could we have also that?

Of course I could save just everything to 32bit float, but that is not the point, because we don't wanna use that heavy EXR for the main pass.
Thank you!

[hermit.crab]

Just checked this and it seems when exporting 16-bit EXRs, only the first of the four channels is saved as 16-bit, the other three are 32-bit. I'm not sure if this is correct, so I'll ask the develepoers.

[houourin]

Just to make sure we are looking at the same way of exporting them separatedly here is a screenshot of the option.
Thank you!

[Joelaff]

What was the workflow purpose of the split cryptomatte option again? If you use lossy compression in your multi channel exr will the split version always use ZIPS?

Sure would be nice if this was all in one place like VrayOptionRE. Perfect world would give the option to write specific channels at specific bit depths and compressions. Sometimes we want Z depth at 32bit as well.

My understanding is that a multi part exr can have different bit depths and compressions per part. Is that correct?

Ideally we would have a channel lister like the light lister that with let us choose which channels and set their bit depths and compression types per channel. It could also give the option to export individual channels as separate files, or include them in the monolithic EXR.

[houourin]

For me is a super wanted feature.
I can use exr 2.0 multipart with DWA compression for all the elements, but keep the cryptomatte in EXR 1.0 ZIP in a separate file.
Fusion19 cant work with the cryptomattes if in 2.0 so this is the only way to have everything! Best of both worlds.

the difference in speed comping is huge.

like you said would be awesome to have more control over what Vray saves though.

[piotrus3333]

Multipart exr via VRayOptionRE was saving everything in the correct compression - lossy or lossless depending on the data stored in the part. at least I've never had issues with it.

same here - it is Fusion or rather Cryptomatte plugin for Fusion that is problematic. I was using Gaffer to split cryptomattes into separate single-part exrs.

edit: the way Arnold manages aovs would be nice to have in VRay.

[Joelaff]

Oh, so it already saves the utility passes as lossless compression when using DWAA? Nice! Does it use 32bit for the cryptomattes and Z depth?

What is the easiest way to see the specs of the individual channels? Are you just using exrheader command line, or some other tool.

Nuke seems to have no problem with the multi part EXRs as is. Never used cryptomatte with fusion (though I have used fusion for decades).

[hermit.crab]

Just to make sure we are looking at the same way of exporting them separatedly here is a screenshot of the option.
Thank you!

Yes, we are looking at the same thing. Here's what I found out: There's nothing to worry about - it is expected for the first of the four Cryptomattes to be 16-bit, when outputting 16-bit EXRs. The other three will always be 32-bit, since they will not work otherwise.

[piotrus3333]

Joelaff
mrv2 is showing bit depths but still is not able to acctually display other parts of exr. mrv is displaying all the parts ok but bit depth is shown from the first part. those two are exr viewers that i use most of the time.

[houourin]

Yes, we are looking at the same thing. Here's what I found out: There's nothing to worry about - it is expected for the first of the four Cryptomattes to be 16-bit, when outputting 16-bit EXRs. The other three will always be 32-bit, since they will not work otherwise.

Thank you!
I see, the cryptomatte was working as expected so that is why i was confused about it, thank you!