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
l...@larrygritz.com
_______________________________________________
Openexr-devel mailing list
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel
