Is the One True Accepted definition of the color and alpha channels that they are always the premultiplied, accumulated (that is, pre-composited?) values at the depth of each sample? So we never have to worry about deep images that have channels whose values are the "local" contributions (rather than the cumulative amounts)?
Only local contributions are supported, not cumulative amounts, so data can be stored behind solid objects. We decided not to support cumulative data at all, though the initial ODZ file spec did propose both as valid approaches, you don't really gain much for deep comp by having cumulative RGBA.
For the "flatten" operation, should the flattened Z be the depth at which alpha became opaque? That kind of makes sense, in that it would keep the Z paired with its alpha at that depth; but on the other hand, that means that a flattened deep file would in general not end up with a Z channel that would match, say, a traditional render Z output, which usually registers the closest hit regardless of opacity.
I guess the question comes down to why you'd want to flatten Z. The most likely reason would be to look at it for debugging purposes. Any processing operations requiring Z should be applied to the deep image.
My favoured approach would be to composite Z like any other channel (with appropriate unpremult/premult). This is the flattened depth channel of a sphere moving in front a card, with blurred/confused depths where the sphere appears transparent due to motion blur, created by compositing depth as a regular unpremultiplied channel:
If you only take the alpha=1 sample, you get this:
I think the first makes more sense for visualisation and should be the default image, though there are cases where you want the second (which is why we have a checkbox to make the second image instead of the first)
You also run into problems like a did making these pictures. Nuke's motion blurred rendering was giving me the sphere's opacity as 0.9999 until I fixed it. That meant the sphere didn't show up at all in the flattened depth channel.
Yes, it is should be taken literally: even if you have "opacity.R", the correct behaviour would be to composite the "R" channel with "A", not "opacity.R"On p. 2 of Florian's document, it says "Every deep OpenEXR image must contain either a single alpha channel, A, or three alpha channels RA, GA, BA." Are we to take this literally, that it is not considered valid to have a deep OpenEXR that doesn't contain alpha, or whose channels are not given these precise names? (Example, it will *always* be "RA", and *never* "opacity.R"?)
The library supports compositing deep images into regular ones, so you can use the regular InputFile API to read a deep image. For it to do this, the naming conventions must be enforced, otherwise the library won't flatten the image as intended.
We could say "if there's no alpha channel, assume 0 for all samples", since the API would give you that if you tried to read "A" from an image which didn't have one stored.
On 25/10/13 20:12, Larry Gritz wrote:
Very helpful document, Florian, thanks. I have some questions about the meanings of deep images (mostly from the point of view of writing software to manipulate them). Is the One True Accepted definition of the color and alpha channels that they are always the premultiplied, accumulated (that is, pre-composited?) values at the depth of each sample? So we never have to worry about deep images that have channels whose values are the "local" contributions (rather than the cumulative amounts)? If so, how can you represent samples "behind" an opaque object? Or can't you? Does the spirit of deep OpenEXR allow samples with a Z that is greater than the point where alpha == 1? For the "flatten" operation, should the flattened Z be the depth at which alpha became opaque? That kind of makes sense, in that it would keep the Z paired with its alpha at that depth; but on the other hand, that means that a flattened deep file would in general not end up with a Z channel that would match, say, a traditional render Z output, which usually registers the closest hit regardless of opacity. On p. 2 of Florian's document, it says "Every deep OpenEXR image must contain either a single alpha channel, A, or three alpha channels RA, GA, BA." Are we to take this literally, that it is not considered valid to have a deep OpenEXR that doesn't contain alpha, or whose channels are not given these precise names? (Example, it will *always* be "RA", and *never* "opacity.R"?)