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