Jump to content
Sign in to follow this  

deep primid aov?

Recommended Posts

(Apologies for the repost, originally sent this to the sidefx list, thought folk here might have info too... )


Short version:
Outputting primid as a deep aov appears to be premultiplied by the alpha, is that expected? Unpremultiplying helps, but doesn't give clean primid's that could be used as selection mattes in comp.

Long version:
Say we had a complex spindly object like this motorcycle sculpture created from wires:

Comp would like to have control over grading each sub-object of this bike, but outputting each part (wheel, engine, seat etc) as a separate pass is too much work, even outputting rgb mattes would mean at least 7 or 8 aov's. Add to that the problems of the wires being thinner than a pixel, so standard rgb mattes get filtered away by opacity, not ideal.
Each part is a single curve, so in theory we'd output the primitive id as a deep aov. Hmmm....
Tested this; created a few poly grids, created a shader that passes getprimid -> parameter, write that out as an aov, and enable deep camera map output as an exr.
In nuke, I can get the deep aov, and use a deepsample node to query the values. To my surprise the primid isn't clean; in its default state there's multiple samples, the topmost sample is correct (eg, 5),  the values behind are nonsense fractions (3.2, 1.2, 0.7, 0.1 etc).
If I change the main sample filter on the rop to 'closest surface', I get a single sample per pixel which makes more sense, and sampling in the middle of the grids I get correct values. But if I look at anti-aliased edges, the values are still fractional.
What am I missing? My naive understanding of deep is it stores the samples prior to filtering; as such the deepsample picker values returned should be correct primid's without being filtered down by opacity or antialising.
As a further experiment I tried making the aov an rgba value, passed Of to the alpha, then in a deepExpression node unpremultiplied the alpha. It helps on edges, but if I then add another deepExpression node and try and isolate by an id (eg, 'primid == 6 ? 1 : 0'), I get single pixels appearing elsewhere, usually on unrelated edges of other polys.

Anyone tried this? I read an article recently were weta were talking about using deep id's to isolate bits of chimps, seems like a useful thing that we should be able to do in mantra.

Share this post

Link to post
Share on other sites

did you try turning on Sub-Pixel Output in Mantra?

Share this post

Link to post
Share on other sites

Yep, it triples the render dimensions so that it's one pixel per sample (I was testing with 3x3 samples), but that sorta defeats the purpose of deep, and didn't fix the problem anyway. :)

Share this post

Link to post
Share on other sites

I prototyped this last year, and got it working quite ok. I do remember having similar problems first, though.

I don't have Nuke right here at the moment so I can't verify these, but here are the files.


I used it for object ids, but it should of course work for prim ids as well. The shaders in the hip have a couple of methods for digging them out.


Here are simple test images, where I remove a motionblurred object from an image in post.







The exr was too bit to attach: https://dl.dropboxusercontent.com/u/40756545/deep_id/deep_id_test.exr



Share this post

Link to post
Share on other sites

Right, got this working, here's my example if anyone's interested. As Matt Ebb explained on the mailing list, Mantra exports a deep Of per sample, but Nuke puts this into other.RA, other.GA, other.BA.  Deep values themselves are always premultipied by their opacity by the looks of things, but if you divide by rgba.alpha, that seems to be the flattened alpha rather than the per-sample alpha.


The nuke script here takes the primid of a spinning pinwheel thing, and tries to hide an individual spoke in 2 ways:




-via a proper deep removal. works, but to do any other stuff means you're limited to the deep nodes, of which there aren't many.

-create a mask, flatten it, and use that to drive a regular grade node. It works fairly well in most cases, but here it doesn't completely remove the spoke, once the image is flattened we lose accuracy.


Hope this helps, thanks eetu and Matt Ebb for the tech details.



The cyan spoke has been magically removed! Tadaaaa!





  • Like 1

Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this