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..?)
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.
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?
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.
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.
Whatever Chris. I'm not an engineer/programmer but I don't see why you still can't have an option when opening exr's to open them using the CS2 convention of RGBA rather than transparent RGB. Is it that hard?
I second everything progress, jonah and David Parisi are saying.
How can discarding the A channel possibly be the correct way of opening an EXR file? And if discarding the A channel is correct according to ILM, then AE, Combustion, Nuke, Fusion are all wrong?
And in a file format that allows one to save multiple channels as described by David Parisi, how does discarding the A channel make any sense? If the proEXR plugin allows one to access multiple additional channels, including the alpha channel, are the proEXR guys doing it wrong as well?
AE has now adopted portions of the proEXR plugin which allow access to additional channels in the EXR format. Why would Photoshop refuse to accomodate such added functionality? What if Photoshop adds multiple channel access in future releases? Will they still discard the alpha channel?
David - we can't have the option, because the file format does not allow the option, and the specifics of the file format make the option pointless in the first place.
PLEASE go read the existing thread. We've been over this. Your questions have already been answered, multiple times, in excruciating detail.
And no, we haven't implemented all features of the OpenEXR file format yet. Most people aren't demanding all the extras, some of the extras don't fit in Photoshop, and they're adding more niche stuff all the time.
Cliffton - Photoshop does not discard anything. We read the transparency channel just like the file format says we are supposed to. The A/tranparency/opacity channel is right there in your document, doing what it is supposed to do.
Yes, ProEXR is wrong for allowing you to open the A channel as anything other than transparency (especially if they fail to handle the premultiplication).
It sounds like you really don't understand the terms and technologies involved, and you also need to go read the existing posts in this topic.
Chris-Why doesn't the file format allow for the option? It seems like you did it in CS2 and CS3 Standard so why won't it work in CS3 Extended. Isn't the file format the same in both? It seems the only thing different is the import code, not the file format.
Where's the other "existing" thread where you explained it all? Do you mean the rest of this one?
WOW. Too many hours a day coding Chris? Not enough sleep? Right about the time that Guido Quaroni from !!!!PIXAR!!!! chimed in, I would start listening buddy!
If I were on the phone to tech support, this is the point in the conversation where I would ask to speak to the manager! :D
I have read all of this discussion. I understand the math: color * opacity. But many other apps give you the option to ignore the Alpha thus keeping the RGB.
I've made an EXR in 3ds Max http://www.jonahhawk.com/EXR/Alpha.exr
Ok, to help illustrate our point further, please open it in After Effects. Right click on the EXR footage and choose Interpret Footage. Choose Ignore under Alpha Channel. Viola! the RGB data is intact!
If this doesn't help you understand where we are coming from maybe you could have someone else discuss the issue with us. I can tell you are getting frustrated.
Jonah - Guido and I go back a ways. And Guido's problem turned out to be someone not understanding the difference between Photoshop and Photoshop Extended (different people had different versions, leading to increased confusion). I believe he's got it straightened out now.
OpenEXR is a format where you can't just ignore the A/transparency/opacity channel - because the format defines that channel to be one thing and one thing only, and ties it closely to the color (by making it always premultiplied). If you want flexibility, you may need to use a different file format.
Ignoring the file format spec. leads to workflow problems, interoperability problems, etc. And it seems a few people have already started OpenEXR down the road to ruin by either not understanding the file format (or even the terms involved), or trying to make it do things it is not intended to do. I know it might be expedient -- but nobody is going to be happy if you keep using that screwdriver like a hammer.
TIFF can store extra channels, and more standard metadata than EXR.
TIFF can have transparency and unassociated alpha channels.
TIFF will also be premultiplied if you include a channel as transparency, or not if you save the channel as an unassociated alpha channel.
You might want to learn more about the file formats you use.
An option that goes against the design of the file format, breaks interoperability, and still won't do what you think it will do -- is just pointless. It's like asking for a "read it backwards while standing on one foot" option -- silly, and won't really help you accomplish your task.
And just because someone else included a bad option in their application does not mean that other applications should make the same mistake. ("hey kids, let's all jump off a bridge!")
If OpenEXR changes their file format specification, we'll reconsider. But right now the file format as specified means that implementing your request would be both damaging and misleading. (and the fact that you don't understand the damage makes it scary misleading...)
Um, I write the file format code, I write the compositing code, work with the standards groups, work with the visual effects industry, and I use everything that I write. I probably do more compositing before lunch than you will do all year.
Chris, I can fix that typo, if you wish, but -- it IS good for a laugh, you must admit!
I used to do promotions work for one of the major sports publications. Can't tell you how often I came close to inserting an extra "e" in "Super Bow_l" -- and that @#$% spell checker would have just sat there, clueless!
Ill agree with those here in the industry who are asking for this functionality. We need options, albeit with the reasonable defaults Chris is talking about.
We use unpremultiplied imagery like this often in certain circumstances, and we know we are not the only ones. Nuke and Shake and Fusion all do not force you to be premultiplied or unpremultiplied, making you have to handle all this yourself. Being able to be smart about how we make our file import interpretations allows flexibility. If you want to paint a mattepainting for reprojection onto cg, you may want to start with the painting first, and then start to hack away(make transparent in the final render) parts while you go through the iterative development process. If you eat in too much by painting black on the alpha and you have saved it, you want the ability to go back and "undelete" that area. The alternative now is to have a psd master file with a layer mask, and then bake down an rgba version every time you make an edit, this adds an additional file and management to something which could be simplified by adding this import/saving behavior option. If AE has it why can't photoshop have it?
Even tho I have the feeling that this discussion won't get to any conclusion, I have to say that I find that the way PS is dealing with EXR Alpha channels is just plain wrong.
Baking the contents of the Alpha channel into the RGB transparency makes it impossible to work with un-premultiplied RGBA images, especially output them from PS.
If you render a TIFF with RGBA channels and you open it in PS you get a "Background" and "Alpha 1", both untouched as it should be since I can add (or not) the transparency to the RGB channels at any point in PS as I please. This is the right way since PS isn't guessing if my RGB channels are pre-multiplied or not, nor if I need transparency or not. It leaves that decision to me, which is a smart thing to do since I'm the one who can judge what I'm seeing and what are my exact needs.
But if you render the very same file in EXR format with the very same set of channels of the TIFF (RGBA), when you open it in PS you get "Layer 0" and no Alpha channel.
This is just plain wrong since PS is assuming that the RGB was premultiplied by A, and that the RGB transparency is required (desired) by the user. Something that it shouldn't do no matter what the files specs say or don't say. That's an action that should be taken by the user since as far as I know computers don't actually have a visual awareness of the images they are processing nor are aware of the context where they will be used.
Alpha which as far as I know is usually used as a RGB matte channel is indeed intended to be a "transparency channel" but that doesn't mean that a application (PS in this case) has the right to trash my RGB data just because it "makes sense".
Photoshop as image editing (retouching app) should keep it's premise of being able to open - edit - and output an image with no data being lost or being drastically changed from input to output, period.
Being able to retain data as it is throughout the process is a must and a basic necessity in any digital workflow that I know of.
Chris, I'm a bit surprised by all the confusion in this thread. I'm not sure that it's intended, but you're coming across as the kind of Adobe engineer who we've always been frustrated by in the past. When it comes to EXR, Adobe is in no position to be redefining established workflows. Please look at how it is used in Nuke, which probably has the deepest implementation in the industry, with millions of frames processed. Many of us are sick and tired of the contortions we've had to go through in order to make Photoshop fit into established VFX workflows over the years, and we've held out hope that Adobe might finally get it right now that Photoshop has broad support for 32 bit float.
there is a reason AE added an "interpret as linear light" option. Those scoundrels in the AE team actually listened to the testers and, while it's unconventional to represent exr rgb data as gamma encoded, it does happen. If users want it, it might be worth considering.
Like Alan said, I think "contortion" is quite a good word to describe the experience me and my colleagues had while fitting Photoshop into our Nuke-based vfx compositing pipeline for a major studio just a few months ago.
And reading through this entire thread... I'm exhausted by it. Please please listen to Progress, David, Jonah and Alan etc. Can we get a little flexibility here with PS's EXR behavior?
If you use OpenEXR with an A channel (defined as always being transparency) then you ARE working with premultiplied data. Even if you work with it unpremultiplied while in the application (like it always is in Photoshop) - you already premultiplied it when it went into the EXR file. YOU ALREADY LOST DATA WHEN YOU SAVED. Oh, I'm sorry, am I shouting?
If you need unpremultiplied data - don't write it into OpenEXR with transparency, or TIFF with transparency. Instead, write the transparency/alpha channel into an unassociated alpha channel. (unfortunately, this means Photoshop can't read it from EXR right now because we only open the ARGB channels, but Photoshop will happily open up to 56 channels in TIFF).
Alan - read the previous posts, please. I'm not redefining anything - I'm doing what the file format says we are supposed to do. There is no other interpretation available -- we do what we're supposed to. If Nuke has a bug, why would Adobe duplicate that bug? If Nuke fails to read the file format specification, why would we reproduce the same bug?
Why are people joining the forums and making their first forum post to this topic without reading the previous posts or taking a few minutes to find out what the heck they're talking about?
If you want the Photoshop behavior with regard to the A channel in OpenEXR to change, you are going to have to take it up with the folks who write the OpenEXR spec. That spec says that the data is to be interpreted one way, and one way only -- which is exactly what Photoshop is doing. If you want the data to do something else, or mean something else: please use another file format that does what you need, or change the EXR spec.
Chris Cox wrote:
Even if you work with it unpremultiplied while in the application (like it always is in Photoshop) - you already premultiplied it when it went into the EXR file. YOU ALREADY LOST DATA WHEN YOU SAVED. Oh, I'm sorry, am I shouting?
Where in the spec do you read the above, about doing multiplication of the RGB channels with the A channel as the data gets written to disk?
All I can find is; "The [channel's] name tells programs that *read* the image file how to *interpret* the data in the channel." (page 4 of TechnicalIntroduction)
I can't find the paragraph, where it says you have to multiply the RGB channels with the Alpha channel as the data is written to the EXR file, thus loosing data.
These "people" you are so flippantly addressing, are industry professionals who have spent the last 2 decades or so up in the small hours of the morning writing elaborate scripts or awkwardly contorting already strained pipelines to decieve Photoshop into reluctantly relinquishing relivant images, so you can casually claim your product was used on [insert film here].
Adobe Photoshop Engineers would be wise to listen to their user base, especially when they have so patiently explained the situation. And rest assured, as gut wrenchingly painful as it is to read this mindlessly repetative thread; we have.
consider this fromt he open exr documentation ( http://www.openexr.com/photoshop_plugin.html )
"Un-Premultiply: by convention, OpenEXR images are "premultiplied" - the color channel values are already matted against black using the alpha channel. In Photoshop, it's more convenient to work with unmatted images. It's important to use this option rather than un-premultiplying the image within Photoshop, because the plug-in will un-premultiply before applying exposure and gamma correction.
This option will have no affect if your image does not contain an alpha channel."
by convention OPENEXR images are premultiplied, sure, by convention, you shouldnt wear white socks with sandals, but that wont stop vfx folk from doing it!
Point being, this is not an unreasonable request, it is entirely trivial to impliment, and noone has been anything but patient when requesting it.