Change in EXR open from CS2 to CS3 can this be fixed?

Brendan,
>the ProEXR plug-in for After Effects is an AE-specific plug-in.

Thanks for the clarification. I suspected that was the case.

Neil

What "premultiplied" means, in fact what any word means, depends on
who uses it. That's why technical documents generally try to define
important terms before using them.

Since the OpenEXR documentation is ambiguous enough to allow the
present discussion to take place, I will augment the documentation.
On about page 5 the "Technical Introduction" states:

[The A channel represents] "alpha/opacity: 0.0 means the pixel
is transparent; 1.0 means the pixel is opaque. By convention,
all color channels are premultiplied by alpha, so that
"foreground + (1-alpha) × background" performs a correct "over"
operation.

I will add following (or something close to it):

Note: describing the color channels as "premultiplied" is a
shorthand for describing a correct "over" operation. With
un-premultiplied color channels, "over" operations would require
computing "alpha × foreground + (1-alpha) × background."

"Premultiplied" does not mean that pixels with zero alpha and
non-zero color channels are illegal. Such a pixel represents an
object that emits light even though it is completely transparent,
for example a candle flame.

Since pixels with zero alpha and non-zero color can and do occur
in OpenEXR images, application software must avoid discarding the
color information in pixels with zero alpha. This can be a problem
for applications that internally use an image representation where the
color channels have not been premultiplied by alpha. After reading
an OpenEXR image, such an application must undo the premultiplication
by dividing the color channels by alpha. This division fails when
alpha is zero. The application software could set all color channels
to zero wherever the alpha channel is zero, but this can alter the
image in an irreversible way. For example, the flame on top of a
candle would simply disappear and could not be recovered.

If the internal un-premultiplied image representation uses 32-bit
floating-point numbers then one way around this problem might be to
set alpha to max(h,alpha) before dividing, where h is a very small
but positive value (h should be a power of two and less than the
smallest positive 16-bit floating-point value). The result of the
division becomes well-defined, and the division can be undone later,
when the image is saved in a new OpenEXR file. Depending on the
application software, there may be other ways to preserve color
information in pixels with zero alpha.

Florian - partly I'm going from what you wrote in the spec., and partly from previous conversations (email, phone, and at your office).

There is no notion of "self luminous but completely transparent" in straight color -- you must have some opacity for any color to appear. That concept of color without opacity only works in a premultiplied pipeline (but still breaks some filtering stages).

There are 2 requests here so far:

1) to treat the color in EXR as straight color, not premultiplied (or at least open it that way and let them do other work on the data)
2) to open the A channel as an arbitrary alpha channel, not opacity

Both of those go against the spec. as written and break interoperability for EXR files. If you intended for those to be allowed, then it was not communicated in the EXR spec. And I strongly feel that allowing them will create more confusion around the interpretation of EXR files. What is written into the file should have one, clear, unambiguous meaning. Having multiple potentially valid interpretations of the same file data leads to big messes (even bigger than we're dealing with here).

Sigh. I guess I need to write a tutorial on what premultiplied and non-premultiplied color mean and how they relate in different applications and contexts. (and probably document why straight color works better for editing)

From the viewpoint of an application that works with straight color, premultiplied does mean that you multiply the color values with the opacity channel (same as compositing over black while leaving the opacity channel intact).

From the viewpoint of an application that works entirely in premultiplied color, you could have non-zero color values even if the opacity is zero. Whether those values are useful or garbage is debatable (since if you just add them you suddenly have changes where you claimed to have no opacity).

But you can't get from the straight color system to the premultiplied system without multiplying the color values by the opacity values. Wherever the opacity was zero, the premultiplied color values become zero.

When going from premultiplied color to straight color, you have a clamped division operation. And what color is the result of a non-zero color value divided by zero opacity? Unfortunately, it is undefined (infinity is an easy answer, but that kinda breaks later processing).

Chris,

since you claim to know exactly what I mean, without actually
discussing this with me outside this rather bizarre thread, I
would like to clarify that I, as the original author of OpenEXR,
completely agree with Zap Andersson's post earlier today.

"Premultiplied alpha" describes how the "over" compositing
operator is supposed to work. Premultiplication does not mean
that A == 0 forces R, G and B to be zero. As I mentioned earlier
in this thread, zero A with non-zero R, G and B is a perfectly
legal combination. It represents a self-luminous but completely
transparent object, not an abuse of the OpenEXR file format.

Photoshop is an outlier in how it treats OpenEXR's A channel;
Nuke, After Effects, and many other programs handle A differently.
The OpenEXR specification does not say that Photoshop is right and
everyone else is wrong.

I agree that Photoshop's implementation can be considered "correct"
(except for the A == 0 case, which started this whole thread in the
first place). However, there are other correct - and more useful -
ways to handle the A channel.

Frankly, I don't understand why OpenEXR is "the wrong file format
for what [some Photoshop users] are trying to do." Plenty of other
applications let users do what they want to do. Personally, I'd
say this is strong evidence that the file format isn't really the
culprit, but Chris, I'm sure you'll find a way to refute that.

Florian

Neil, the ProEXR plug-in for After Effects is an AE-specific plug-in. It uses the existing 3D channel API to send those extra passes through. The AE plug-ins are free, open source, and ship in CS4. It doesn't do anything special to the alpha channel because AE already has settings to deal with that.

For Photoshop, it's a totally different plug-in (Photoshop API), doing a totally different thing (making layers), anderumit's not free.

Brendan

Chris,
>For those of you who need support for non-conforming OpenEXR files in PS CS4, Brendan Bolles sells the ProEXR plugin. AE CS4 actually ships with his OpenEXR plugin for AE.

Please correct me if I'm wrong, but the solution is as easy as cloning and installing the same ProEXR plug-in in Photoshop CS4 as is included with After Effects CS4? Or is there a specific version for Photoshop?

Neil

Chris,
>For those of you who need support for non-conforming OpenEXR files in PS CS4, Brendan Bolles sells the ProEXR plugin. AE CS4 actually ships with his OpenEXR plugin for AE.

Please correct me if I'm wrong, but the solution is as easy as cloning and installing the same ProEXR plug-in in Photoshop CS4 as is included with After Effects?

Neil

> To summarize this whole thread in my own words:
> The spec is very clear that OpenEXR images are
> linear data and premul with their alpha data.

But, as I said many times before, to say this is to *fundamentally misunderstand* what "premultiplied alpha" means.

All it *really* means is DO NOT MULTIPLY in your "over" operator.

I.e. do NOT do

r = fg * fg.alpha + bg * (1 - fg.alpha)

but do

r = fg + bg * (1 - fg.alpha)

That is ALL it means. Which, if you actually read the technical document, to OpenEXR as Florian himself (part of the team writing it!!!) posted above, *actually says*.

http://www.openexr.com/TechnicalIntroduction.pdf

Yes. It *explicitly says* that the format of the RGBA data is such that the "over" operation should be

r = fg + bg * (1 - bg.alpha)

To draw from this the conclusion that a color with zero alpha and nonzero RGB is "illegal" and can be thrown away is quite an unfounded extrapolation to make!!

And also note that the spec says that this is *by convention*. Not rule, nor law, but by *convention*. I.e. "the most common case".

> What Photoshop CS4 extended is doing is technically
> correct and following the standard.

So not using the channel labeled "alpha" as an alpha channel is tecnically correct? To throw away fully legal RGB data just because Alpha is zero is correct?

/Z

Hi folks,

A number of people have written to bring this thread to my attention. I haven't had time to read through all 120+ posts (!), but I'll try to do so shortly (isn't that what weekends are for?).

At the end of the day, we have to do what's useful to you, and we will.

Thanks for your passion & patience,
John Nack
http://blogs.adobe.com/jnack