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

Chris, does the difference of how transparency is handled between extended and normal PS mean the plugins are different?

Thanks for the link Florian.

I've probably complicated the conversation by the suggestion that A be used for something else. The ability to use A as non transparent information is a bonus, but even the ability either edit A or simply for A not to be directtly translated into transparency would be great.

The simple problem is that elements such as background info might be specified quite normally as black in the alpha, then these are lost when opened. PS is deleting data created. I know it's only applying transparency, but it's not editable. I can't get to the data before PS deletes it.

PS treats data that is 100% transparent as 100% redundant. It isn't. I might want to get to that data.

Could it be done so it opens as a layer mask instead? Then both camps would be happy then.

(I guess there are work arounds, but I can't help thinking there's no good reason that A should automatically be converted into transparency)

Progress and Krille, this Photoshop plugin may be just what you need: http://www.fnordware.com/ProEXR/

Chris, I guess we have established that Photoshop does
The Right Thing (TM) when opening an OpenEXR file with
an A channel or an equivalent TIFF file. On the other
hand, the request for an option to open the EXR A channel
as a PS alpha channel for independent editing sounds
entirely reasonable. I guess progress is requesting a
new feature.

Progress, if you use the OpenEXR A channel to store
information other than how transparent a pixel is, then
how is software such as Photoshop supposed to know when
the A channel really is an A channel and when it is, say,
depth by another name? If you are storing depth in the
file, you should probably call the depth channel Z as the
EXR documentation recommends.

You can ask Renderman to split the output of a single
render pass into multiple files if packing all the output
channels into a single file is inconvenient. You can,
for example, have Renderman write two EXR files, one
with the R, G and B channels and one that contains only Z.
This way you can edit the RGB image in Photoshop without
altering or even loading the Z channel.

Yes, if you specify transparency/opacity in the file, Photoshop will open that file with transparency/opacity. That's what it is supposed to do. The channel is not removed or applied - it is right there in front of you!

The OpenEXR plugin was changed in CS3 because CS3 was the first version to support 32 bit/channel transparency. Photoshop CS2 supported OpenEXR and 32 bit images, but not transparency. That means that OpenEXR support was broken in CS2, and was fixed with CS3.

In short - it did not work in previous versions, and your problem (wanting to edit transparency data directly) has little to do with the file format. You relied on a bug (or lack of a feature) to do something unnatural for that file format.

Progress: I so agree with you. I sit on OpenEXR images that are currently useless right now. I don´t care if the alpha channel is transparency or not - I just want the possibility to edit that channel. Now I can´t!

OpenEXR is the right file format for me as it supports high dynamic range and is (was) great for renderings. I could choose TIFF too but it´s the same problem there. The alpha is applied and the channel removed. My previous workflow was smooth when I could include the alpha directly into the file instead of render two files for every image.

It worked in the previous Photoshop versions so why change the plugin now?

I think what progress wants is for the "A" channel to open as an arbitrary alpha channel so he can edit it directly.

But OpenEXR defines "A" as transparency/opacity - and you can't easily edit transparency/opacity data in Photoshop without editing the color data as well.

And because OpenEXR is premultiplied, there may not be anything to work with in the transparent areas anyway.

Again, he's using the wrong file format for what he's trying to do.

"As far as I can tell Chris is right, PS handles OpenEXR's A channel
correctly. What am I missing? "

Depends on what you open it back up in. Open it after saving out in PS Extended again and you'll see that the A channel has gone, and the opaque areas are now holes (perhaps how you left it) So you can no longer edit the A channel except destructively, by adding even more transparency. You cannot reduce the transparency.

After saving the image with holes, open it back up again in PS and try and paint back in opacity on the A channel, without affecting RGB at all. I could do this before because I had direct access to the alpha. With the alpha seperated as before I can adjust the A without affecting the image's RGB. Not only that, I don't lose areas set to black on the alpha from RGB when it opened. I now do. They are removed, as per holes.

Before, if i received an image with a background that would be removed by alpha when applied, I didn't need to know what that background was... now I do because it's removed before I can see it.

I will post links later this week hopefully when I have time.

There is a fundamental difference between the two behaviours. The latter removes functionality in a very big way.

I loaded the Blobbies.exr file from the OpenEXR sample image collection
into Photoshop CS3. The file has an A channel (the kind that PS calls
"transparency" and most other people call "alpha").

I used the paintbrush tool to paint onto both transparent and opaque
areas of the image, and I used the eraser tool to create holes in the
opaque areas. Then I saved the result in another EXR file and looked
at the file's R, G, B and A channels with exrdisplay. The data in the
file were what I expected: the paintbrush had moved the A values closer
to 1.0 and the eraser had moved the A values closer to 0.0. The RGB
values seemed to have been properly premultiplied with A. Compositing
the painted-on image on top of another image in PS also produced the
expected results.

As far as I can tell Chris is right, PS handles OpenEXR's A channel
correctly. What am I missing?

The case where A is zero and R, G and B are not zero means something
inherently different in PS and EXR. PS could probably do a pretty good
approximation of the EXR semantics by clamping EXR's A to the range
[1e-9, 1] before un-premultiplying. For all practical purposes an A
value of 1e-9 is zero, but it would allow PS to preserve non-zero
RGB values and to un-un-premultiply on save.

alpha != transparency -- they are not the same and the terms have not meant the same thing in over 20 years.

Progress - remember, alpha can have multiple meanings (arbitrary alpha channel, or transparency/opacity). Please be clear about which meaning you are using. If you mean transparency or opacity, say so. If you mean some extra channel that has no relation to the color channels (alpha channel), say so.

TIFF can contain transparency/opacity AND/OR arbitrary alpha channels. If you have a TIFF with transparency/opacity, then the TIFF will open with transparency. Some 3D packages have bugs in their TIFF support where they fail to mark the transparency channel as transparency, so it opens as an alpha channel instead.

OpenEXR does not support arbitrary alpha channels, only transparency/opacity.

LOL! TGA was changed to follow the spec. Some users were using it incorrectly. So we changed it back to NOT following the spec. It's still maybe 60/40 on the usage of TGA, and we get complaints from both sides.

OpenEXR is implemented correctly in Photoshop, exactly as the spec. says it has to be implemented.