Why only one ID ?

[aghiles]

Hello There,

This is Aghiles, from the 3Delight team. Questions:

1) Why do we just have one ID per EXR file ? It is interesting to have different IDs (materials, namespaces, etc ...) in one file (Like in CrytoMatte). Maybe I missing somethings ? 2) Why not consider any uint32 slice as an ID deep space ? Or jut list the deep slices in metadata. This will fix problem 1 above.

Let me know.

-- Aghiles

[hulud75]

Hi Aghiles,

Good questions, you could have multiple Id slices in a deep file and let the plug-in choose the one to use. Or, you can store multiple informations in each Id meta data, like ID1="/path/to/shape;material;instance_id".

At last Siggraph Matte/ID BOF, I have present a study that demonstrates that using a single ID channel with multivariate metadata should be smaller on most projects.

Plus, it is trivial for the Nuke plug-in to reconstruct the image using multivariate pattern like "/foret/*;leave" to select all the objects in the "/forest" group with the "leave" shader.

Best,

Cyril

[hulud75]

To get multiple id per file, we will have to modify the plug-ins to let the user chooses the Id channel to use.

[aghiles]

Hello There,

In most usages, grouping using different IDs is much more important than having names. For example: 1- One ID layer that has materials ID 2- One ID layer that has objects ID 3- One ID layer that has Instance IDs 4- One ID layer that has namespace IDs ..

The artist doesn't really care what object is which, she/he switches between the different groupings, selects regions and apply modifications/corrections to the particular region. I feel you guys are very close to a solution that is as sound mathematically as OpenEXR/ID and as flexible and useful as CryptoMatte.

Design suggestion:

• One meta data per file listing the name of uint32 (say, "exrid_aovs") deep slice that the plug-in should consider as IDs. In reality, any uint32 deep-slice can be considered as an ID.
• You can maintain backward compatibility easily by checking for the additional "Id" pass. Listing the "Id" pass in the the "exrid_aovs" meta-data

You don't have to implement this, but having the specs allowing it will lead to implementation. (We would be ready to implement it on the export side)

Note that I have no experience with file sizes so I can't comment on that. I am just trying to understand why is there a limitation that is really a detriment to the otherwise nice idea.

[aghiles]

Hello Cyril,

Or, you can store multiple informations in each Id meta data, like ID1="/path/to/shape;material;instance_id".

I am not sure how I can encode two different things at the moment using OpenEXR/Id : how can I have an ID that groups per-material and another one that groups per-object. I am certainly missing something.

-- Aghiles

[hulud75]

Each id comes with its metadata, a string in our design. The reconstruction of the image doesn't use the id, but regexps matching the strings.

Let's say the metadata have the following format : "path;material" If we have 2 taxi cars with wheels and body

id1 = "/taxi1/wheels;plastic" id2 = "/taxi1/body;carpaint" id3 = "/taxi2/wheels;plastic" id4 = "/taxi2/body;carpaint"

Then using regexps you can reconstruct all kind of images: "/taxi." : all the taxis "/taxi1;." : the first taxi ".*;carpaint" : all the carpaint shaders

It's up to you to put whatever you want in the metadata, path, shader, namespace, instance id..

[aghiles]

OK. All clear now ! It's heavily regex based which I didn't catch immediately. We will start playing with the plug-in.

[hulud75]

You have to know it has been decided at Siggraph 2017 that the metadata description should be normalized in the OpenEXR library. It will be done with a proper C++ API and The Foundry is supposed to work on the plug-ins. We'll move to the standard when it is ready, in the meantime we continue to support this format.