This content has been marked as final. Show 253 replies
Also, since you seem so intent on adhering to the openEXR spec, where's the support for the rest of the file format features:
-alpha; luminance and sub-sampled chroma channels; depth, surface normal
directions, or motion vectors
-Multiple versions of a tiled image, each with a different resolution, can be stored in a single multiresolution OpenEXR file
-color timing information, process tracking data, or camera position and view direction. OpenEXR allows storing of an arbitrary number of extra attributes, of arbitrary type, in an image file.
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.
Ah, so you did open that EXR in AE then? why is the rgb still there in AE?
So the few people who...
"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"
include the developers of After Effects, Nuke, Fusion, etc...Photoshop is now the anomaly in our workflow.
Targa and tiff files work this way but neither of these will store extra channels like Z depth, Velocity, Object ID etc. This is why we love EXR.
I really don't understand why you won't admit that having the option is better than not having it. Let us wallow in file format blasphemy if we so choose!!
Have you done any compositing work yourself? Have you tried opening the EXR file I posted in After Effects and seen what happens when you choose ignore alpha?
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.
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?
Or is this an exercise in squaring the circle? :(
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.
would you kindly reconsider.
No, OpenEXR files are premultiplied by definition. If you want to change the definition, talk to the OpenEXR folks. Photoshop is using the existing definition for the file format.
We do listen to users, a lot. But sometimes users make mistakes. Sometimes they ask for things that would do more harm than good. Sometimes, they even ask for things they really, really don't understand. And we try to explain, we try to help them understand (and help us understand why they're asking for something bizarre). Are you listening?
When the OpenEXR file format specification changes, we will reconsider. Until then, I strongly suggest that you use a file format more appropriate to your workflow needs.
I read all the posts before I posted. Yes, this has been cross-posted to the Nuke users list.
Strict adherence to the spec may work in the world of engineering, but we're in a business where specs evolve. The spec was designed for doing professional visual effects work. If you're going to implement the spec, it would be helpful if you learned a bit about how it is used in professional visual effects/CG production. I've seen contributions to this thread by people whose names are on the spec. They might be able to point you in the right direction.
The number one requirement that all of us have is that if a tool reads in data, the tool should be able to write it out without changing it. Clearly, this is broken for some users.
You're reinforcing a frustration that so many of us have with working with Adobe products- there's the Adobe interpretation of computer graphics, and there's an industry consensus, and they're not the same, and the ways that they are different often seem pointless.
Photoshop does read EXR data in and write it out with minimal change.
Yes, specs evolve. But the EXR spec. has not changed. Again, we'll reconsider when the spec. changes. Trying to "evolve" the spec. by ignoring it just leads to trouble (and I'll offer this topic as exhibit #1).
If you try to use OpenEXR and expect un-premultiplied behavior - then it was broken the moment you wrote the data into an EXR file.
But according the the EXR spec. Photoshop is doing what it is supposed to do. If Photoshop did what you ask, it would break interoperability, and would still not do what you need (unless everyone agrees to always treat EXR as non-premultiplied all the time, and that just breaks all existing files and existing versions of applications).
No matter how many people try to use a screwdriver to drive in a nail, that doesn't make it the right tool for the job. You have other tools, that are more appropriate for the job -- use them.
Have you seen the ILM's photoshop exr loader Chris?
You can downloaded from the openEXR site.
It let you unpremult the alpha and even gives you an option
to change the gamma and exposure.
I've been using it and I love the OPTION I have with that plugin.
The reason I wish you guys would come up something like that is that
the ILM exr plugin doesn't support 32 bit, and it's been causing
some issues in recent shows we've been working.
I assume over 95 % people who use the exr format in Photoshop are people in the VFX related, and at this point as I read this thread, pretty much 100% of the users WANT to have the option to unpremultiply the alpha.
Even if you are right about how you implemented the spec, no one is happy with it, and don't want to use it.
Then, I don't see why you would even have exr format support in photoshop. You might as well mention in the spec sheet that Photoshop supports exr but no one in the VFX industry likes it, and recommend to buy proEXR as a alternative solution.
Wouldn't you want to have a feature that makes people happy, and actually use?
You seem to be confusing your segment of an industry with the larger audience of Photoshop users. People are using the EXR plugin shipped with Photoshop, in many industries. Only a few have complained. VFX represents a very small fraction of the people using the EXR file format. But Photoshop has to support everyone using the format, in many different workflows, interoperating with many other applications.
If you don't like the way EXR is designed, you are free to use another file format, or petition the EXR folks to update their spec. But we implement the current spec.
None of you have really talked about what you're trying to accomplish -- you're still asking for your imagined solution to a problem as you understand it (back the the screwdriver for nails thing). If you want a useful solution, we're going to have to talk about the larger problem, larger workflows, and consider alternative solutions (you know, reach for a hammer).
PS. Inviting drive-by postings by people unfamiliar with the issues really is not helping your case.
Break interoperability with what exactly?
Because for now the interoperability you say is already broken and prevents me from bringing any EXR that went trough PS to my comp package as it was and should remain.
And even tho I do get your point regarding the specs I still can't see how something as simple as this, which could be easily solved by a really silly PS Action if it worked the other way around would do more harm than good.
The OpenEXR docs haven't been updated since 2006 and it says "By CONVENTION, all color channels are premultiplied by alpha" and not "All color channels MUST be premultiplied by alpha", so even by that time they've left room for different ways of dealing with this.
But as you said there are other tools that are more suited for the job, in this case the current Photoshop built-in EXR reader just isn't one of them.
Meanwhile if you really need OpenEXR files in Photoshop better spend 95 bucks on the ProEXR plugin from fnord or just dump Photoshop till ILM takes the time to update those three text lines on their docs to make Adobe happy about it.
I posted this to the nuke list in the hope the people most affected by the current implementation would share their wisdom and help improve future versions of Photoshop.
These are the people that you should be turning to for guidance, its their visions that will become the commonplace features of Photoshop CS18.
This is the exact opposite of using a screwdriver to hammer a nail, the founding intention of exr was to provide a FLEXIBLE format for the VFX community who were feeling restricted by the regular formats available in 99.
I can guarantee the other industries enjoying the pleasures of exr would be equity elated to see the requested feature.
At its most basic:
A ) If an element cant pass through our studios pipeline utterly unchanged, I have failed.
B ) If an element cant pass though an image manipulation package utterly unchanged you have failed.
Saddly A is dependent on B,
And a specific practical example, um.... i have an exr with information in the A channel, i save it from photoshop, at a later date the A channel is deemed unsatisfactory, i open it again.....(i fail )
Most of the troubles are issues with how we use exr in other applications that don't tie the rgb to the a. For example textures on a 3d model. We often times paint beyond the border of the alpha because depending the filtering a 3d app uses when it maps it onto the 3d model, you will often times get 1-2 pixels of black on the borders of the UV's. So it is very important to keep that extra data beyond the alpha.
With compositors we will get matte paintings with extra information outside the alpha which often times we will use at a later date because we are going to change the alpha inside our compositor. The current way photoshop reads and writes openexr forces us to write unpremultiplied images to bring into photoshop and then when we do have mattes for separate layers we have to write them to a separate files so photoshop doesn't nuke the information outside it.
Another big issue with the exr reader is it crops the image down to the bounding box(DOD). When I give someone a 1920x1080 image, I expect it to read into photoshop the same, not as a 1024x1024 image. The placement of objects in the frame is very important.
>You seem to be confusing your segment of an industry with the larger audience of Photoshop users. People are using the EXR plugin shipped with Photoshop, in many industries. Only a few have complained. VFX represents a very small fraction of the people using the EXR file format.
Exr was made by vfx artists for vfx artists. We are the audience it was made for, not the larger audience of Photoshop users. Even though the spec doesn't specifically lay it out that way it would be nice if there was a check box so the image is read in as unpremultiplied with the alpha in the channels as a b&w alpha and not as transparency.