Interesting!

Nuke actually has two related nodes: DeepHoldout outputs a flat image only, as 
you said. But also DeepMerge has a "holdout" MODE, and will output a deep 
image. It's not entirely clear from the documentation why there is this 
distinction/duplication or how they differ (other than the fact that DH forces 
a flattening).

So, looking at your pseudocode, I *think* that it differs from mine only in the 
last line -- you seem to *reset* the holdout_alpha tally every time you 
encounter a source fragment. That's very interesting. So I think what that 
means is that holdout samples only "hide" the next source sample, not all the 
samples all the way back. Is this what you're getting at?

Let me run  hypothetical by you, Ramon. Suppose the source image has TWO opaque 
samples (don't ask how it got that way, let's just run with it for now). And 
the holdout image has a sample with A=1.0, in front of the source samples. 
Schematic:

        holdout         source          source
        A=1                     A=1                     A=1        ----> 
increasing Z --->

What is the output? I mean, what is the full alpha of the deep_holdout result, 
if you flatten it?

Is the output EMPTY because a holdout A=1 in front of everything else should 
make a hole in the image, no matter what follows? (That's sensible, I guess?)

Or is the output OPAQUE because the holdout "eats" the first source sample, but 
then resets and allows the second source sample to come through unscathed 
(because in your pseudocode you reset holdout_alpha=0 after processing the 
first sample)?

Variant #2: Same setup, but that holdout sample has A=0.9. Is the output an 
A=0.1 sample followed by an A=1.0 sample, as your algorithm describes (giving a 
overall opacity still of 1.0)? Or is the output an A=0.1 followed by another 
A=0.1 (that was my algorithms' first stab at it), yielding an overall opacity 
of 0.19? Note that neither of those match the intuitive answer that the final 
pixel should have a total opacity of A=0.1 because a 90% holdout in front of 
opaque stuff (whatever that opaque stuff might be) should yield a remaining 
alpha of 0.9?

This stuff hurts my head. I'll try your algorithm and see if it matches what 
Nuke is doing.

        -- lg


> On Jun 29, 2017, at 6:23 PM, Ramon Montoya Vozmediano <[email protected]> 
> wrote:
> 
> The Nuke node (DeepHoldout) works with deep images but outputs only flat 
> images. looks like it merges and flattens A and B together, ignoring RGB 
> channels for B.
> 
> Does it make sense for a holdout sample to affect all subsequent samples in 
> the stack?
> 
> It should affect the accumulated opacity along the stack, but because its 
> opacity should be imputed to the next source sample (that sample might be far 
> away, but lets keep things simple)
> 
> And since we know how to comp one or more holdout samples on top of a source 
> sample:
> 
>     holdout_alpha = 0    // accumulated holdout-ness
>     walking near to far in the combined set of source and holdout samples:
>         S = next closest sample
>         if S from holdout:
>             holdout_alpha += (1 - holdout_alpha) * S.alpha
>         else :  // S is from source image
>             S'.rgb   =             0 + (1 - holdout_alpha) * S.rgb
>             S'.alpha = holdout_alpha + (1 - holdout_alpha) * S.alpha
>             copy S' to result image
>             holdout_alpha = 0
> 
> I think that will work,
> 
> r
> 
> On Thu, Jun 29, 2017 at 6:25 PM, Larry Gritz <[email protected] 
> <mailto:[email protected]>> wrote:
> For regular 2D images, the "holdout" operation (or just "out" in Porter/Duff 
> speak) is the compositing operation where (A out B) is that B blocks A by B's 
> alpha amount, but it doesn't contribute any color or opacity of its own. That 
> is, A with a B-shaped hole cut in it. If B has alpha=1, the resulting pixel 
> will be completely transparent. If B has alpha=0.75, the result will have A, 
> but with its color and opacity multiplied by 0.25.
> 
> We're on the same page, yes?
> 
> OK, so my real question is what the "deep holdout" operation actually does. 
> If A is the "source" image, and B is the "holdout" image, we have the 
> intuition that B's samples should block any farther samples of A, but without 
> contributing samples itself.  But I'm having real trouble figuring out the 
> correct behavior for a stack of interleaved A and B samples. Nuke supports a 
> deep holdout operation, but the docs aren't specific about exactly what it 
> does.
> 
> I've tried walking front to back, keeping an accumulated holdout alpha and 
> multiplying by that as we copy source to result. Here's the sketch:
> 
>     holdout_alpha = 0    // accumulated holdout-ness
>     walking near to far in the combined set of source and holdout samples:
>         S = next closest sample
>         if S from holdout:
>             holdout_alpha += (1-holdout_alpha)*S.alpha
>         else :  // S is from source image
>             S' = S * (1-holdout_alpha)
>             copy S' to result image
> 
> For a "flat-equivalent" image of one holdout sample closer than one source 
> sample, it matches what I expect for the 2D flat holdout operation. But it 
> doesn't seem to give me what I'm looking for in many circumstances involving 
> multiple depth samples of the source.
> 
> Can somebody bail me out here and spell out what the correct behavior of a 
> deep holdout operation ought to be?
> 
> --
> Larry Gritz
> [email protected] <mailto:[email protected]>
> 
> 
> _______________________________________________
> Oiio-dev mailing list
> [email protected] <mailto:[email protected]>
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org 
> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
> 
> _______________________________________________
> Oiio-dev mailing list
> [email protected]
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

--
Larry Gritz
[email protected]


_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

Reply via email to