openEXRid : OpenEXR files able to isolate any object of a CG image with a perfect AA

[vanished]

Hi,

Remember Psyop's Cryptomatte?

I found this thread on BMD Fusion Forum: http://www.steakunderwater.com/wesuc....php?f=8&t=739

This is what it does: https://www.youtube.com/watch?v=W_ltvSMrwnQ

OpenEXRid can be found here (opensource): https://github.com/MercenariesEngineering/openexrid

Developers thread on OpenEXRid: http://guerillarender.com/forum/viewtopic.php?id=906

Doesn't need a lot of imagination to see the advantages of having this working for Vray as well?

Cheers,
Tim

[vlado]

I don't know yet what would be involved to support this. One of our developers is looking into whether this is feasible or we would have to develop our own approach.

As for CryptoMatte, we probably won't support it.

Best regards,
Vlado

[joconnell]

Isn't it partially on the nuke side too though? Admittedly you'd need a coverage map like in combustion to save the edge weighting of anti aliased pixels but a lot of it would be nuke having better options to unmultiply images by the colours of the objects behind them rather than just black?

[vlado]

Yes, we will probably need a Nuke plugin... But it's really standard deep OpenEXR 2 functionality; you can extract antialiased masks based on object/render IDs even now without any special tools. You just don't have the names and selection by name.

Best regards,
Vlado

[instinct]

...which you could get using the renderid element's xml. They probably write it in the header. I can see havoc with big scenes though?

Everything else as noted elsewhere please better support deep instead so we can eventually converge towards a common standard

[re:FORM]

Sounds like something I developed at a previous studio.
It worked really well; from the nuke side of things you simply picked a pixel and you had a matte for the asset, model, or material that the pixel was associated with.
The main hurdle I had was the numeric limit of the objectID channel. My workaround would have been to pipe custom attributes through a vrayUserScalar map rendered out to seperate extraTex maps (eg for assetID, objectID, instanceID, etc) but as this wasn't integer, it wasn't going to be ideal. I put a request in to Chaos to allow us to add unlimited objectID render elements that could pull any integer custom attribute from an object, not just its objectID which would do the job, but I'm not sure if that's been implemented yet.

[Dave_Wortley]

Sounds like something I developed at a previous studio.
It worked really well; from the nuke side of things you simply picked a pixel and you had a matte for the asset, model, or material that the pixel was associated with.
The main hurdle I had was the numeric limit of the objectID channel. My workaround would have been to pipe custom attributes through a vrayUserScalar map rendered out to seperate extraTex maps (eg for assetID, objectID, instanceID, etc) but as this wasn't integer, it wasn't going to be ideal. I put a request in to Chaos to allow us to add unlimited objectID render elements that could pull any integer custom attribute from an object, not just its objectID which would do the job, but I'm not sure if that's been implemented yet.

There's a limit on objectIDs?

[vlado]

I put a request in to Chaos to allow us to add unlimited objectID render elements that could pull any integer custom attribute from an object, not just its objectID which would do the job, but I'm not sure if that's been implemented yet.

Yes, it is there - add a VRaySamplerInfo render element and set its mode to "Integer ID from node user attribute"; you can then add a node user attribute to the objects with the value that you want to see in that element.

Best regards,
Vlado

[instinct]

Sounds like something I developed at a previous studio.
It worked really well; from the nuke side of things you simply picked a pixel and you had a matte for the asset, model, or material that the pixel was associated with.
The main hurdle I had was the numeric limit of the objectID channel. My workaround would have been to pipe custom attributes through a vrayUserScalar map rendered out to seperate extraTex maps (eg for assetID, objectID, instanceID, etc) but as this wasn't integer, it wasn't going to be ideal. I put a request in to Chaos to allow us to add unlimited objectID render elements that could pull any integer custom attribute from an object, not just its objectID which would do the job, but I'm not sure if that's been implemented yet.

It is implemented but we do not really need it here. If you want all objects you can use RenderID, if you need groups only then it should fit within limits. You can also combine with MateriaIDs of course.
With the SamplerInfo + IntegerIDs there is hardly any limit to the amount of complexity you can add. To sum some feats for Deep:

- You save IDs to a single channel. So within a single channel you can have max_integer IDs. It reads quick and it changes and combines a LOT quicker than shitloads of multimatte. Let alone scales very very well.
- Pulling IDs from deep are not pixel-perfect but sample perfect. No more edges/fringing etc
- All data channels all of a sudden work sample perfect too. So when using normals, point passes or alike all of a sudden no more aliasing, edges etc. (e.g. i did a point pass based 3d noise that is now also antialiased)

Plus a lot more that i don't want to go into right now. Currently there are still some issues on the vray side (mostly things i would like to get more control over and some behaviour i would like to see changed). There is a lot to be desired on the Nuke side of things. Had to implement quite a lot of nodes before making things really really usable. You could probably use DeepExpression and get quite far already though.

Cheers,
Thorsten

[RE:FORM_STUDIOS]

Hi Dave,
Yes, I think I hit the upper limit at some point as I was building an ID from multiple parts eg;

The id was of the form : 12345678 or AAAIIPPP where A = AssetID, I = InstanceID and P = PartID. Of course this also had limits on the number of each ID type, but it was enough to allow us to select masks in Nuke by asset, instance or part.
With the scene xml it meant you could pretty much build a layer/scene explorer in nuke to matte objects by-name... although I think this would only be much use for lighters, as the compers I spoke to didn't see the point; they just want to point and shoot... as it were.

Vlado : Aha. great! I had a feeling that would have been implemented. Thanks for that!

[RE:FORM_STUDIOS]

It is implemented but we do not really need it here. If you want all objects you can use RenderID, if you need groups only then it should fit within limits. You can also combine with MateriaIDs of course.
With the SamplerInfo + IntegerIDs there is hardly any limit to the amount of complexity you can add. To sum some feats for Deep:

- You save IDs to a single channel. So within a single channel you can have max_integer IDs. It reads quick and it changes and combines a LOT quicker than shitloads of multimatte. Let alone scales very very well.
- Pulling IDs from deep are not pixel-perfect but sample perfect. No more edges/fringing etc
- All data channels all of a sudden work sample perfect too. So when using normals, point passes or alike all of a sudden no more aliasing, edges etc. (e.g. i did a point pass based 3d noise that is now also antialiased)

Plus a lot more that i don't want to go into right now. Currently there are still some issues on the vray side (mostly things i would like to get more control over and some behaviour i would like to see changed). There is a lot to be desired on the Nuke side of things. Had to implement quite a lot of nodes before making things really really usable. You could probably use DeepExpression and get quite far already though.

Cheers,
Thorsten

Hey Thorsten, I totally agree.

The only thing to add would be the reason we went with the objectID approach was the, perhaps uneccesary, desire to allow compers to copy nodes between shots. With renderID, if I am not mistaken, the values would be different in each scene?

I also wanted to allow overlapping ID sets (something impossible with objectIDs on their own); eg if a comper needed a specific selection as a matte, I would simply add them to a selection-set in Maya which would get picked up at render-time to create a new extratex(or mutlimatte, I forget) on the fly. These would then appear in my nuke node matte-selector along with the assets, layers and materialIDs.
The end game here is to pretty much have all the meta data of layers and selection sets available in comp. DEATH TO MATTES!

The deepExpression nodes are a bit of a pain (limited expression length), but once you stick them in a gizmo and rewrite the expressions using python on the fly, we found you could implement some handy tools too.

[instinct]

Overlapping ID groups and stying consistent makes total sense! As said we typically have groups large enough not to go near numerical limits as we do not encode information in the IDs.

As for DeepExpression i also agree. All the new Deep tools i did are native plugins. For both speed and feature reasons. e.g. neat picking and selections in viewports and more complex operations.

Cheers,
Thorsten

Hey Thorsten, I totally agree.

The only thing to add would be the reason we went with the objectID approach was the, perhaps uneccesary, desire to allow compers to copy nodes between shots. With renderID, if I am not mistaken, the values would be different in each scene?

I also wanted to allow overlapping ID sets (something impossible with objectIDs on their own); eg if a comper needed a specific selection as a matte, I would simply add them to a selection-set in Maya which would get picked up at render-time to create a new extratex(or mutlimatte, I forget) on the fly. These would then appear in my nuke node matte-selector along with the assets, layers and materialIDs.
The end game here is to pretty much have all the meta data of layers and selection sets available in comp. DEATH TO MATTES!

The deepExpression nodes are a bit of a pain (limited expression length), but once you stick them in a gizmo and rewrite the expressions using python on the fly, we found you could implement some handy tools too.

[joconnell]

Thorsten what type of penalty to you guys see in render times / processing times using exr 2? I'm wondering is it worth it for smaller setups like ourselves.

[instinct]

Thorsten what type of penalty to you guys see in render times / processing times using exr 2? I'm wondering is it worth it for smaller setups like ourselves.

The only difference in render times is when saving out the final deep exr. Rendering itself is not affected. You need more storage for the same amount of pixels * channels. The difference differs a LOT (let me repeat: a LOT) depending on the type of short, the contents of the frame and the type of sample merging you do.

Now of course bigger files, which in this case also means more samples = more pixels, are both slower to load and process. On the other hand you save potentially on MMREs being a single channel.

So there is no easy answer to this. For the type of stuff we do it is well worth it. If you are doing fx shots you may restrict it for shots/elements involving volumetrics and matted volumentrics. Tough to judge really.

Cheers,
Thorsten