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?

[_progress_]

well swapping the plugins doesn't work, the plugin wont load under cs3 intel

[Guest]

start CS3 in Rosetta and the plugin should work.

[Chris Cox]

CS2 did not support transparency in 32 bit/channel, thus could not show transparency in OpenEXR documents, and so opened the transparency channel into an alpha channel.

CS3 does support transparency in 32 bit/channel, uses the transparency data from OpenEXR documents, and opens the transparency channel as transparency.

This can only be fixed by adding UI to the OpenEXR plugin "Do you really understand that transparency is transparency?".

[_progress_]

Yes I do Chris, but alpha isn't transparency. It's an alpha channel. We're importing files with alpha channels, not transparency as generated in PS.

PS might use alpha channels to generate transparency, but it's a bit like saying an RGBA Jpeg should behave the same, yet we know it doesn't. We all know that tga was changed, then changed back again... it's the same thing.

The problem is that EXR is the only format we can convert to from our 3d images, and we like to render in one pass and use the alpha for an an alpha, not transparency. By losing this we now have to render in two passes, one for the RGB data, and another for the alpha, then recombine them afterwards.

CS3 can support both transparency and an alpha in 32 bit at the same time. So can we not have the choice before a file is shredded? At least if we have the alpha we can choose wether to apply it as transparency, or actually use it as a selection to drive an effect. The are a whole host of passes we use alphas for, only one is transparency.

Now it means we have to keep a legacy system around to open EXR's correctly, or render 2 passes. Which is a bit of a bind to say the least considering the size of the renders. Last night it was just the one 50k render. But it took ages to process the 6gb of data to where we need it because we had to chuck it around on old gear.

How much of a hoop is it to add that UI, and how much of a hope that it will happen?

[_Guido_Quaroni_]

This is a huge deal for us (Pixar) as well. We are trying to integrate (finally) OpneEXR into our pipeline and when I load OpenEXR files with alpha computed by the renderman, it gets lost in Photoshop CS3/CS4.
Now the option here is to either ask Adobe to fix this in CS4 and allow an option at the loader level or we have to write our own OpenEXR reader.
To better understand since I don't get the difference between transparency and alpha (for us, we just deal with alpha) how the OpenERX file should be structured so that we can retain the alpha/transparency from the file ? Maybe we can modify the renderman driver.

thanks,
guido

[_progress_]

Thanks Guido, it helps to know it's not just us little chaps having trouble.

Perhaps you can split your alphas off before PS get's to it?..

I'm not sure we can with our renderer... we might have to get it to render RGB, then again for the alpha. For standard alphas that's a hoop jump, but if we wan't shadow matte in the alpha for example, then thats a big pain as it effectively means we'll be getting close to doubling our rendering times... and we normally work on 8k+ renders, so that's a bit of a nause.

[_Florian_Kainz_]

Hi Chris,

with OpenEXR it is standard practice to interpret the "A"
channel as pre-multiplied alpha. Compositing a foreground
layer over a background layer is correctly done like this
(see http://www.openexr.com/TechnicalIntroduction.pdf, page 5):

composite = foreground + (1-alpha) * background

Programs that read and write OpenEXR files generally adhere
to this convention. I don't know how transparency works in
Photoshop; your message suggests that PS transparency is not
the same as alpha. This would imply that PS should not treat
OpenEXR's alpha channel as if it was transparency. Of course,
PS could add transparency channels as needed when it writes
OpenEXR files.

Florian

[_Mike_Ornellas_]

Great read. Thank you.

[_progress_]

For us, it's not that it doesn't behave the same, it's that you often dont want it to, and alpha isn't always transparency. We might use it as a matte or z-buffer.

It looks like with another hoop jump, we can strip out the alpha before PS gets its sticky mitts on it and assumes it's an alpha for transparency before we tell it wether it is or not.

[Chris Cox]

Florian - you are confusing the terms alpha (any extra channel) with transparency (what you called alpha). Photoshop reads and writes OpenEXR files exactly as you stated - with premultiplied transparency.

Apparently some users thought EXR supported general alpha channels and are now confused when those channels are treated as transparency (as the file format specifies).

[Chris Cox]

Alpha Channel - any extra channel beyond the color channels. This has nothing to do with transparency (except as a historical footnote). Anything can be stored in an alpha channel, it does not have to be related to the color channels at all. You can have many alpha channels in an image.

Transparency - a subset of extra channels, closely related to the color channels, with special meaning. Can also be called Opacity (transparency and opacity are the reverse of one another). You can only have one transparency channel in an image. This may be premultiplied with the color data, depending on the file format specification.

[Chris Cox]

Guido - Photoshop DOES preserve the transparency/opacity data from EXR files, exactly as specified by the file format spec. The only exception was in CS2 when Photoshop did not support 32 bit transparency, in CS2 we just read the transparency channel in as an alpha channel.

If you are trying to use the EXR "A" channel for something other than transparency - STOP. The file format does not allow that. You can add other named channels in EXR, but Photoshop doesn't yet support them.

[_progress_]

Chris, I think your wrong on this. I think that's backed up by TD's from Pixar and the originator from ILM posting as such. It's being interpreted in the wrong manner, ie assuming transparency = alpha.

Exr doesn't have transparency in it's spec. Its RGB+A. But PS is presuming that A = Transparency. Not only that, it's applying it and deleting it before the file is viewed, which means when it's used in pre-multiplied it's actually taking away image data that can't be put back.

It's not done with any other format, and it's not done with tga now it's been changed back. It's the very same thing.

PS is making irreversible changes to the document when it's opened. It doesn't matter even if later you define the alpha as the transparency, it's nuking the image that's the problem. Pre-multiplied means that for any pixel value except 0 in the alpha, the alpha will remove some of the image + the background it's "transparent" against.

If I have an alpha, I can choose to apply it to the image to make transparency as I wish.

It's impossible to rebuild an Exr back to what it was once PS has got hold of it, because by applying the alpha as transparency it has deleted RGB image data.

A 1/2 way house would be to have it as a layer mask... at least then both your transparency interpretation and the image data is retained and the user can have the choice.

[Chris Cox]

Progress - read Florian's statement and the EXR spec. again. His "A" is defined as transparency. The explanation is just confused by referring to it as alpha (which could be any additional channel, not just transparency). But the math, and the requirement for premultiplication means it must be transparency. That is the only interpretation available, and the interpretation that Photoshop uses.

Yes, premultiplied transparency does lose image data -- but that is the way the EXR format is defined. Your "nuking" happened when you saved the EXR file, because it has to be premultiplied (transparent areas go to zero in the color channels).

The only change Photoshop makes is to un-multiply the data, because Photoshop does not work with premultiplied data. The data is re-multiplied when you save the file, resulting in no net change to the file data. Transparent EXR files round trip just fine through Photoshop, as far as I can test with files from ILM, or those that I have created.

If you wish to have an arbitrary alpha channel (one not treated as transparency) in the EXR format, you will need a third party plugin. EXR does allow for extra channels, but the Photoshop EXR plugin does not support them yet.

[_Florian_Kainz_]

Chris, and Progress,
I guess I don't understand what Photoshop does with OpenEXR's A channel.
When you open an EXR image with RGB and A channels in PS, and then
immediately save the image, will the new file not be identical to the original?

[Chris Cox]

The color channels may be altered slightly due to un-multiplying and re-multiplying (remember: Photoshop does not use premultiplication, so we have to un-multiply to use the image). So, the least significant bits may change.

[_Florian_Kainz_]

Chris,

In an EXR image it is legal to have pixels with non-zero RGB values
and a zero or nearly zero A value. Such a pixel represents an object
that emits light but is otherwise transparent, for example, a candle
flame. (If you place a candle between a bright light source and a
screen, the flame casts no shadow.) In this case un-premultiplying
leads to infinite or very large RGB values.

Chris, I agree with you, the A channel should be used for alpha (in
the transparency sense). I don't see how PS could possibly guess that
A is in some files really a depth channel. That's why EXR supports
arbitrary channels, and why the specification recommends using Z for
depth. On the other hand, this would be less of an issue if PS
guaranteed that RGBA data pass through unaltered unless the user
explicitly modifies the image.

[_progress_]

Slightly?

No Chris.

Pre-multiplying is done at the render. It's not something the Exr 'does'.

You cannot un-multiply a render... you have to render it in a different manner completely. It is impossible to un-multiply the image because a pre-multiplied image always contains background data as a % related to the alpha strength. The A is not a by-product of the render's opacity, it is merely a single channel representation.

Photoshop does not just alter "slightly" the files. In your example, if you have a very bright but transparent object, the effect that PS has is to almost entirely remove that image data and the alpha. You cannot get that image data back.

Florian, what PS now does is to take the A and use those values as to generate a selection, and delete from the RGB channels. So if you A value is black, areas are entirely deleted, if the value is 50%, 50% is deleted and so forth. And it does this automatically, and so the image is destroyed, and the alpha is lost.

i On the other hand, this would be less of an issue if PS
guaranteed that RGBA data pass through unaltered unless the user
explicitly modifies the image.

Exactly correct.

If people are having trouble seeing what the problem is, let me know and i'll post some examples tonight.

[Chris Cox]

Progress - yes, you can un-multiply (aka divide with appropriate handling for zeros)! You have to in order to bring a premultiplied image into an app that doesn't work with premultiplied data. We do it all the time with file format that specify premultiplied data (like TIFF). Premultiplication does not necessarily happen at the render stage - it may, depending on the renderer, but in many cases it is an explicit step since some file formats want premultiplied data and others do not.

And your description of what Photoshop does with the transparency channel of EXR files is very, very wrong. The transparency is not lost in any way (assuming you are using CS3 or CS4 extended, since the standard version does not support 32 bit transparency/layers/compositing).

Photoshop cannot "pass through unaltered" because the file format is premultiplied and Photoshop doesn't work with premultiplied data. We have to undo the multiplication. Then the file format requires that it be multiplied before saving.

[Chris Cox]

And it looks like Guido's problem was some people using extended, and other people using standard (who could not see the transparency correctly, because standard does not support 32 bit/channel transparency).

[_progress_]

What Exr is doing is applying the A into the image and not making it editable...althought the transparency is applied, the transparency is effectively "lost" because it cannot be got at.

Another point that you might not be aware of is that the RGB data is built from the RGB of the object against the background. The background might often contributes nothing to the alpha, but does to the RGB... so when the alpha removes the area it removes RGB data. Obviously this is exagerated when using pre-multiplied values of not 0 or 255, because it removes a proportion of the RGB (including the background) related to the A value.

Because of the way PS can't handle pm, it is the exact reason why it shouldn't assume alpha isn't transparency.

If I render an object with no transparency with the values 128,128,128 and A=0 then render it with 50% opacity, the image is 128,128,128 and A=128. The problem is that although the pixel values are stil 128 in the RGB, the image is transparent! You can't get that "solid" 128 RGB data out because PS ties it's transparency in with it... you can't unhook the two apart from each other. There's no layer mask to lose, or alpha, it's 'baked' the transparency into the image...

It's not so much that the transparency is lost, it's that the image is irrevocably broken... I can re-generate an alpha from the transparency... i can't see how i get those pixels back to full opacity though.

perhaps there is a way of doing it... how do I get a that image back solid? The pixel values haven't changed, they're still 128, 128,128... the alpha is gone, there is no layer mask, the layer is 100% opaque... yet there is a transparency value attached to each pixel that I can't get at.

The only way I know how is to put the exact colour in the background that was used in the renderer... but it might not be a colour used as the background, it might be an image... it might be a background plate which normally carry no alpha contribution... that's the problem.

You don't arbitrarily apply transparency in 8 or 16 bit to other formats before they are opened... why do it in 32 all of a sudden? They all support transparency once in PS (well its PS that supports it, not the format)... same as Exr.

In fact, it was this exact problem that prompted the backstep on alpha. I can't see why you can't see this as the same thing, because from our end it is.

If you want Chris, I can send you the exact files. A simple transparent box floating over a background, rendered. Normal alpha generated from the opacity straight from the file. All standard stuff, straight from a standard renderer. Your challenge is to tell me what was in the background. Your 2nd one will be to re-create it. With the CS2 you can... with CS3 you can't.

It's broken.

But does this mean we can load the CS3 non extended plugin in, or does the app do the damage? Could that be perhaps made available if it solves the problem?

[Chris Cox]

Progress - no, it is not broken, it is working exactly as intended, exactly as the file format spec. says it should.

In the openEXR file format, the "A" channel is defined as transparency/opacity, and the color data must be premultiplied with that transparency/opacity channel.

If you render an image with transparency/opacity into OpenEXR, Photoshop will open that image with transparency/opacity - exactly as the file format spec. says it should.

Many file formats include transparency/opacity and are premultiplied (like TIFF), and we have been handling them exactly the same way since Photoshop 3.0. There has been no change - we have to treat transparency/opacity as transparency/opacity.

With CS2, it was broken - because 32 bit/channel did not support transparency or layers (they are connected). So, in CS2 (and Photoshop standard) you get the same result as if you'd opened a transparent TIFF back in Photoshop 2.5 -- the color data, with transparency stored in an alpha channel (because we had no way to display or use the transparency).

Your description is very confused, so I'm not really sure what you are trying to accomplish. But the OpenEXR support is working exactly as it must work.

[_progress_]

Chris, it's not. It's really simple.

If I open a tiff with a premultiplied alpha it stays as RGB and A. No transparency is seen.

If I open a targa with a premultiplied alpha it stays as RGB and A. No transparency is seen.

If I open a jpeg with a premultiplied alpha it stays as RGB and A. No transparency is seen.

Yet if I open an EXR with a premultiplied alpha it removes A and applies it to the RGB. It doesn't alter the RGB values but it adds a transparency value that PS understands but is not editable.

Thus with PS's handling of transparency, I now end up with transparency embedded into the file which cannot be edited.

It must work another way because CS3 Standard and CS2 previous work another way. Just because 32 bit in CS3e supports transparency does not mean the A should be applied to the image to produce it. Just like it doesn't for every other format in 8 & 16 bit, which also support transparency.

I'll make it clear... PS deletes RGB image data based on alpha values. That is not correct. No other format does this. And this is why Targa had to be changed back. Because it was an incorrect interpretation of what an alpha is. An alpha is not transparency, it's a greyscale representation of transparency. There is nothing in the EXR or other format that says it has to be applied to the RGB image, and since other formats dont behave the same way I don't see why Exr should either.

It's so VERY VERY broken. Do you think I would bother posting here if there was no effect on the image?

Or am I missing something fundamental that allows me to retrieve RGB data from the file which has been made transparent, even though there is no layer mask or alpha?

Is the plugin different on CS3 standard? Or is it the code in the extended application that adopts a different interpretation.

[Chris Cox]

Progress - it really is that simple.

If you open a TIFF with transparency, Photoshop shows transparency - otherwise the TIFF file was written incorrectly (something certain 3D apps mess up from time to time) or you wrote the extra channel as an arbitrary alpha channel. TIFF does support transparency/opacity and arbitrary alpha channels.

TGA should support transparency, but we backed off because so many people were misusing the file format. We still have people who want to open it one way and save it another (meaning we should prompt for how to handle the fourth channel at open and save).

JPEG does not support transparency at all.

The transparency/opacity in an EXR file is not lost - it's right there as transparency/opacity. Where it is supposed to be. Nothing is removed. Nothing is deleted. Oother file formats that support transparency/opacity work the same way. Other file formats that are premultiplied work exactly the same way.

CS2 was just broken with regard to 32 bit transparency. CS3 standard tries to follow the CS2 path because it also does not support 32 bit transparency. But CS3 (and CS4) extended are working exactly as they must work.

Look: transparency/opacity is transparency/opacity and must stay transparency/opacity. If you want to use that extra channel for something other than transparency/opacity - use another file format that supports that concept. Right now you are either hopelessly confused about the concept, or just using the wrong file format to do what you are trying to do.