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

[_progress_]

It seems the monkeys have been at the file formats again...!

Open an exr with an alpha in CS2 and the image displays normally and the alpha is retained.

Open an exr with an alpha in CS3 and the alpha channel is applied to the transparency and then lost... which is really STUPID considering you might apply 0 alpha values to parts of the image you retain visually, as you might just want to use the alpha to drive an effect and not just be myopic and think it's just for transparency.

So, can this be fixed? I can't see any info on it?

Will CS2 non intel plugin work on an intel system in CS3

If not, effectively PS is useless for exr work for us.

Or is this fixed in CS4?

[_Florian_Kainz_]

I find this discussion very confusing. Does anyone have an example,
say, an EXR file with alpha straight from a renderer and the same file
after it has gone through PS?

[_progress_]

I will post examples if i have time this week, if not next.

Chris, if you open a tiff with an alpha, it does not display transparency. It displays RGB and an Alpha. Even if you save it with an alpha, it opens back up with an alpha.

However, I can introduce transparency and save it as that as well as the alpha.

So what is different then? If alpha must equal transparency, why doesn't tiff behave the same. Moreover, why can we have a transparency and a different alpha in the same document, yet the two are apparently the same? That does not make sence in relation to your point of view.

Targa, as Adobe found out, was changed to be wrong. Adobe interpreted it in one way, and the rest of the digital world told Adobe why it was wrong. This is largely the same. It's broken/wrong.

[Chris Cox]

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.

[_Florian_Kainz_]

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.

[_progress_]

"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.

[Chris Cox]

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.

[_Krille_]

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?

[Chris Cox]

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.

[_Florian_Kainz_]

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.

[_Florian_Kainz_]

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

[_progress_]

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_]

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

[Chris Cox]

Progress - The extended and standard behavior is just a switch in the code, not different code. It just does slightly different assignments based on the host licensing.

And again-- Photoshop is not deleting any data. Your only problem here is that you want to edit the transparency/opacity data directly, and Photoshop does not let you do that easily. Opening the transparency as a layer mask adds some serious problems with roundtripping and compatibility with other file formats (because most of them do not support layer masks).

"A" in OpenEXR _is_ transparency. That is the way it is defined, that is what it must be. Using that channel for anything else breaks workflows (which is why I hate putting it in an alpha channel in standard).

[Chris Cox]

Note to self - go write a plugin to copy data out of transparency and into a layer mask. The reverse is already available with "apply layer mask".

[_progress_]

If the last post isn't sarcastic, then that would be a very useful solution to a number of scenarios where transparency is embedded and prevents RGB editing of data hidden by a transparency which is not editable.

I still maintain that A isn't transparency, but a representation of transparency... but i'm willing to drop the pedantry if it gets us somewhere.

[Chris Cox]

In OpenEXR "A" is defined as transparency/opacity. And OpenEXR is premultiplied - so anywhere you had "A" set to zero -- the matching color data is gone.

[_progress_]

But it isn't "gone"! Because if I open it up in CS2 it's there! Along with an intact A. That's my whole point. Arghhhhh! It's still transparency, because I can invoke that when I choose, without losing data...

It wasn't gone on save. It's not gone on open in anything else but CS3e. It's only gone because of the way just CS3e handles it. It's only "gone" because CS3e hides it, and it's effectively deleted as you can't unhide it. Actually, it's still very much there, except that CS3e stops you getting to it. You can even save it out and find it again in CS2!

It's not anywhere just where A=0, it's anywhere where A doesn't = 255 because it's pm'd the value will remove a proportion of the colour data based on it's 0-255 value.

Do you not see what the problem is?

Now, if you can reverse or "ungone" the info, then great...

Or is there a way to downgrade an install of CS3e to CS3 (to avoid hoop jumps elsewhere..?)

[Chris Cox]

Premultiplied color/alpha/transparency means file_color = color * opacity
Where the opacity was zero, the information is *gone* after it gets written into the file, not recoverable, pining for the fjords... (er, wrong sketch, sorry).

The problem is that you are trying to use a file format that doesn't support what you're trying to do, plus you're trying to edit transparency/opacity - which Photoshop doesn't let you do easily.

[_progress_]

i Where the opacity was zero, the information is *gone* after it gets written into the file

But it isn't ! If I open the original EXR up in CS2 it's there. Along with the alpha. IT HAS NOT BEEN REMOVED ! 😄

Only if i throw it into CS3 then out again and open it in CS2, is it removed. So that must mean? That must mean PS is changing the file... ta dah...! See the problem?

i which Photoshop doesn't let you do easily.

which should read ;

which Photoshop did let you do easily, but has been broken.

[_jonah_]

Just to chime in here and back up what progress is saying. CS3 and CS4 have ruined EXR Alpha functionality. We had to buy ProEXR from Fnord in order to keep the RGB values of the black Alpha pixels.

In the ProEXR installation instructions they have you rename the Adobe OpenEXR.8bi to OpenEXR.WTF

I think that says it all.

If this discussion were a tech support call, this is the point where I would give up and ask to speak to the manager.

[_DAVID_PARISI_]

Ditto to what progress and jonah have said...openEXR simply does not work in it's current implementation in CS3 (& CS4) for most workflows. I've read through the EXR description on ILM's site and I don't see anywhere that it requires the RGB to be made transparent due to the alpha. Yes, they do describe the pixel as being transparent, but this is in relation to performing any compositing actions, not opening it for editing.

Regardless, can you just add a tickbox option somewhere to allow photoshop to open OpenEXR's as RGBA rather than a transparent RGB?

[_jonah_]

Chris,

Please open an EXR in CS2, to see what we are talking about.

or After Effects, any version. go to Interpret Footage and choose ignore alpha.

In a 3d app like 3ds Max or any other, it is common to render an object against an environment or background image. By default the 3d geometry has a value of 1.0 in the Alpha channel and the environment 0.0. But this does not mean we ALWAYS want the environment to be transparent. Often we want to see the sky or keep the background color whatever it may be. Many other file formats retain the Alpha RGB values. As did EXR in Photoshop CS2. I'm sure you're aware of the Alpha present in Targa, Tiff, RLA, PNG, etc.

All we want is the option to keep the RGB of the Alpha. Just like it was in CS2 and is in After Effects, Combustion, Fusion, Nuke.... etc.

Small change to your plugin has a huge impact on our workflow.

[Chris Cox]

SIgh - just when I got the original folks to understand....

Please, go read the rest of the thread.

Here is the summary:
RGBA *is* RGB+transparency in the case of OpenEXR - the file format says that it must be that way. The file format does not allow you to use the A channel for anything other than transparency. And the file format says that the RGB values are premultiplied (that happens when you write the file) -- so if you have zero in the A channel, you must also have zero in the RGB channels.

Most likely you misunderstand something about the concepts involved, or you are just using the wrong file format for your work. But, as far as anyone has been able to determine, Photoshop CS3 and CS4 are working perfectly correctly for the OpenEXR file format.

[Chris Cox]

David - you're so unclear on the concepts I don't even know where to start.
That entire post is a non-starter.

[Chris Cox]

jonah - I have. I've also discussed it with the folks who wrote OpenEXR (the spec. and the code). Photoshop has it right.