openexr-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Openexr-devel] Interpreting Deep


From: Florian Kainz
Subject: Re: [Openexr-devel] Interpreting Deep
Date: Fri, 25 Oct 2013 13:19:07 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130626 Thunderbird/17.0.7

Hi Larry,

I have a new version of the document just about ready to release; it includes
a number of changes based on detailed feedback from several people.

Regarding your comments:

As Peter mentioned, the samples store local contributions, not cumulative
alpha and color.  I apologize for the misleading wording in my document;
you are not the only one who interpreted it as saying the samples store
cumulative values.

Neither the current nor the new version of says anything about flattening
the Z channels.  Since there is no "correct" method for doing this,
I think the best the document could do is list multiple possible methods:
flatten Z as if it was color, output the z value where the stack of samples
becomes opaque, or discard Z altogether.

The new version of the document describes a procedure for finding the alpha
channel that is associated with a given (non-alpha) channel.  The procedure
supports multiple sets of alpha channels.  Essentially, for the R channel
in some layer look first for AR then A in the same layer, then for AR or A
in the enclosing layer, and so on, all the way to the base layer.
This implies that the names are fixed; opacity.R would not be recognized as
an alpha channel.  Also, sample splitting, sample merging, and flattening
rely on alpha; this implies that every image must include at least one
alpha channel.

Florian



On 10/25/2013 12:12 AM, 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"?)


On Sep 24, 2013, at 3:10 PM, Florian Kainz wrote:


To the more mathematically inclined OpenEXR users and developers:

If you can spare the time, I would like you to read the attached
document and give me feedback on it.

The IlmImf library defines the file format for deep images and it
provides convenient methods for writing deep image files.  However,
the library and the existing documentation (as of September 2013)
do not explain in detail how deep images are meant to be interpreted.

The attached document attempts to describe what the deep data in a file
mean, and how compositing of deep images works.  The document also points
out numerical issues with the representation of volumetric samples, and
proposes an alternate volumetric sample representation that would address
those issues.

I believe that agreement on the interpretation of deep OpenEXR files
is desirable because it enables compatibility among different vendors'
image compositing applications.  In addition, anyone developing algorithms
such as lossy compression would be able to rely on a standardized
interpretation of a file's contents.

Florian
<Deep Image Data 09-24-13.pdf>_______________________________________________
Openexr-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/openexr-devel

--
Larry Gritz
address@hidden







reply via email to

[Prev in Thread] Current Thread [Next in Thread]