Improved Render Compositor: Feedback and discussion

This nodesetup is working pretty nicely. Thanks for the tip on image node.

3 Likes

Hi. I have a question, can someone confirm if blender recognizes multilayer exr files since version 4.1? It doesn’t work for me.

It should work. Specifically in 4.1 or on latest main build as well?

I restarted my computer and tried again, now blender crashes every time I import that exr, except in blender 4.0 and before, it still recognizes both the exr and the layers. If you want to try this is the file:

In that case, can you open a bug report?

2 Likes

Ok.

The other thing I wanted to ask about is the cryptomatte. I render an image (other than the one I sent before), either exporting it as a multilayer exr as separate exr (using ZIP compression and Pxr24) and import it back into blender, then use a cryptomatte node to isolate a selection, but when I preview the output of pick, the cryptomatte only has two colors and despite being an object cryptomatte, it unites several others under the same color. Also, in the objects in which the selection with the picker works, a transparent border remains.

The issue could be in the render engine or the compositor. So it is also best to report a bug for this one.

2 Likes

It seems to have been a mistake on my part, sorry. I didn’t know that the input color space of the multilayer exr had to be set to Raw(None/Generic Data), only then the cryptomatte node recognizes its passes.

One more question, does the cryptomatte pass that is in the viewport as a preview belong to the compositor project or EEVEE?.

If you mean the display pass that you can select from the dropdown, then that belongs to EEVEE.

Ok, thanks. I’ll comment on that in its respective thread then.

There is one thing with cryptomate that is related to the compositor. I was testing how cryptomatte handles the different compression modes (if there was a difference) and I found that the node uses different descriptions for the masks depending on the compression mode, checking the metadata they all have the same information but node shows them differently. (Edit: This happens if I render in Cycles and mainly between two modes PXR24 and ZIP, one shows the name of the object and the other only numbers)


both setups are selecting the same objects

Could you share those two images? Or simpler ones that reproduce the issue.

Sure, I’ll upload them now.

These are the files: there is ZIP, PXR24 and DWAB
EDIT: I added EEVEE render version too Test_Cryptomatte - Google Drive

With EEVEE the situation is different, the cryptomatte node shows nothing but black, only the “cryptomatte node (legacy)” can display the pass correctly. When selecting an object, names will not appear as in the cycles exr, only the code of that pass.

The reason why PXR24 doesn’t show object names is because it is a lossy compression method, so the object identifiers stored in the pixels change due to compression and can no longer be associated with the names in the meta data manifest. For DWAB, this issue doesn’t happen because Blender disables compression for crypomatte. The reason why correct masks are shown is because PXR24 is a per-pixel compressor, so cryptomatte coverage values are stored as is, just with less bits.

I suspect we can solve this by updating the manifest to use 24 bit hashes cast to 32 bit, but I am not sure if this is up to standard or would be worth doing.

The EEVEE situation is known and reported as far as I know.

Oh, how interesting. This is something that could be added to the documentation if there are no plans to change the behavior in PXR24.

I checked the reports and there is no similar one. In this case the eevee exr does have the cryptomatte metadata but there is something that makes the node not recognize it unless it is done manually with the legacy node.


I just noticed that the EEVEE exr has one of the cryptomatte layer names duplicated in the node, it appears as “Grass.Grass”, instead in cyles is just “Grass” and the pass type. Would that be affecting the node so that it does not read the layers correctly?.

Yes, that’s the issue I am talking about. And it is already reported here:

Should be simple to fix, so I will submit a patch now.

Thanks. If that fixes it that would be great, although comparing the cases it is still different. I opened my exr with ExifGlass to see the metadata and there you can see the manifest and names, contrary to the other report where those were not exported.

Thank you again for your efforts in resolving this issue.

EDIT: Oh, I just saw the fix you posted and that will address the naming issue, sorry for not understanding clearly before.

It is not obvious that both issues are related, but they are. The report is about meta-data not getting exported specifically from the File Output node, and the reason for that is because the File Output node refuses to export invalid cryptomatte meta-data, which is your issue. So if we fix invalid meta-data, we also fix missing meta-data. :slight_smile:

1 Like