Why only one ID ? about openexrid HOT 7 CLOSED

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

from openexrid.

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

from openexrid.

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.

from openexrid.

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

from openexrid.

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..

from openexrid.

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

from openexrid.

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.

from openexrid.