Re: [Openexr-devel] Interpreting Deep

[Larry Gritz]

Thanks so much for the clarification.  Sure, that makes more sense.  Local 
values it is!

        -- lg



On Oct 25, 2013, at 1:21 AM, Peter Hillman wrote:

> My two cents from NZ ($0.0166 US):
> 
>> 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:
> 
> <edcifdhi.png>
> 
> If you only take the alpha=1 sample, you get this:
> 
> <fbgeaffh.png>
> 
> 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.
> 
> 
> 
> 
>> 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"?)
> 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"
> 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"?)
>> 
>> 
> 

--
Larry Gritz
address@hidden