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?".
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?
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, 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.
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.
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.
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).
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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).
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?
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.
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.
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.
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?
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.
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.
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.
"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.
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.
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?
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.
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.
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 – 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).
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.
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.
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.
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?
which Photoshop doesn’t let you do easily.
which should read ;
which Photoshop did let you do easily, but has been broken.
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.
Ditto to what progress and jonah have said…openEXR simply does not work in it’s current implementation in CS3 (& CS4). 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?
Jan 22, 2009
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. 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.
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?
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?
Thanks for clearing that up Chris. You might want to tell your colleagues developing AE that they are doing it wrong as well.
Jan 31, 2009
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! 😀
Joking, joking.
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.
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.
Feb 1, 2009
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 composting 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.
Ill agree with those here in the vfx 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?
Hi, 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.
This is seemingly a dead end, in terms of working with this particular representative. Is there another Adobe representative that can weigh in on this topic?
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.
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.
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…..
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 1920×1080 image, I expect it to read into photoshop the same, not as a 1024×1024 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.
I am very aware of that VFX is a small potato for Adobe.
But I was specifically talking about photoshop users who use EXR file format, and if you say there are other industy using this format more than VFX industry, could you tell me who that is?
I might be the ignorant one here if DTP or web are using EXR format more than VFX industry, and that would be a big news for me.
At this point, I am convinced that there are nothing we could change your mind, and I am giving up to have any hope for adobe to implement anything good for VFX.
I currently work in web and I am an aspiring matte painter.
I have never used the EXR format for web design or DTP. In fact, the only time I have read, heard, or talked about EXR it has been in relation to VFX. I have never used EXR in my web design career. Most of my colleagues/friends who are amateur/pro photographers don’t use EXR. The only other industries that I can think of that uses Photoshop would be medical image analysis, crime scene image analysis, and architecture. I doubt these industries use EXR on a daily basis.
Are there any other industries using EXR?
Regarding some of the messages that have been posted here. Everyone knows what’s been said. There’s no reason, other than to be facetious, to quote some of the remarks made. But I do feel that it’s important to note that for matte painters such as Susumu Yukuhiro, Photoshop is our only option for finished matte paintings. There is no other tool besides Photoshop for compositing/painting photo-real matte paintings. Cinepaint in it’s current form can’t offer the functionality that a feature film matte painter requires.
I hope that the EXR documentation can be updated so that the Photoshop crew can implement updates to the way that Photoshop handles OpenEXR. However, it would be also be great if Adobe implements features that its customers ask for.
The error here is that Chris is interpreting the word "premultiplied" literally. Many people do, incorrectly. I really hate the word, actually, because it leads you to believe it’s literal meaning, that something has been multiplied with something "before" (i.e. "pre" something).
THAT IS WRONG. It is a total misrepresentation of what "premultiplied" means.
I don’t know what a better word would be, but it’s meaning is "dont’ multiply the color-channels with alpha".
I.e. in non-premultiplied (aka "straight" alpha), a compositing operation would be
r = fg * fg.alpha + bg * (1 – fg.alpha)
And in "pre multiplied" the compositing math is
r = fg + bg * (1 – fg.alpha)
Notice the lack of a multiplicatoin on the fg? This is what lead the people to name this to say it is "pre multiplied". It isn’t, really. It just means IT HAS THE PROPER RGB DATA TO BE ADDED TO THE MATTED BACKGROUND. This is *****NOT****** and I repeat * N * O * T * the same as "having already premultipled it with alpha"
Because this is a completely legal premultipled RGB color (1.0,1.0,0.0,0.0).
This is 100% transparent luminiscent yellow.
When composited properly, according to r = fg + bg * (1 – fg.alpha) it ends up ADDING yellow on top of the (unmodified) background. This is a very common workflow that renderers output such channels.
The whole idea that for a zero alpha, RGB data is always zero (or can legally be thrown away) is WRONG. It is a complete misinterpretation of the concept of "premultipled" alpha. It is a total misunderstanding, going so far as some documents claiming this "illegal" completely erroneously.
(For street cred of my position, since that seems necessary here, I had this discussion with Alvy Ray Smith, the guy who *invented* the Alpha channel, and he agrees with me on this).
"VFX represents a very small fraction of the people using the EXR file format." Could you read again what you have written? As one user pointed out, OpenEXR was *created* by this industry, specifically for it’s use. I do suppose that your statement is either a lie to server your argument or simply ignorance, as I’m pretty sure the VFX industry is the most important user of the OpenEXR format. But maybe I’m wrong, so enlighten us and tell us which other industries have a number of users of OpenEXR which is significantly bigger than the "very small fraction" in the VFX industry. Nobody asks you to break anything. Use the specs as you see fit, but offer the OPTION to your CUSTOMERS to use the software in the most useful way to do their job. I don’t care about the spec. I want an OPTION in the loader to let me ignore the alpha if I WANT TO. Because *I* know how my pipeline works, not you, neither Adobe. I’d also like you to show an example of how this addition of this option would break the workflow of someone, who would that someone be and in what industry would he/she be involved in (supposedly with a greater number of user of OpenEXR than the VFX industry). This is so typical of Adobe arrogance. "Screw the users, we know better and we will force them to break their workflows if it’s more comfortable for us". Your users ask your for *options* to make their life easier — or at least don’t make it harder — (again, they don’t ask you to break something) and you hide behind the "spec" paper and tell them to leave you alone.
i’ve read through this entire exhaustive thread now and just want to mention a point that nobody else seems to be bringing up.
I can see your position with regard to CS3+4 treating the "A" channel as transparency by default, but as you have pointed out multiple times, photoshop’s EXR plugin doesn’t currently support more than RGBA OpenEXRs. if we want to bundle a matte with our RGB channels that does /not/ represent the transparency of the image, the only channel we have at our disposal is that A channel. anything else currently gets thrown away on import.
the suggestion of, "finding a more appropriate format" Chris Cox, "Change in EXR open from CS2 to CS3 can this be fixed?" #80, 3 Feb 2009 7:40 pm </webx?14/79> isn’t particularly helpful or realistic. visual effects facilities have entire pipelines built around specific image formats and re-structuring those pipelines around an inflexibility in a piece of software that likely makes up a very small corner of that pipeline just isn’t going to happen.
the plea here is to (until the day when full multi-channel EXR support makes its way into photoshop) give your VFX user base some options with regard to how that precious "A" is handled. fine, let the default be the "right" way to interpret the data, but don’t cut us off at the knees. being flexible is of primary importance in production.
regards, erik winquist
btw..
"I probably do more compositing before lunch than you will do all year."Chris Cox, "Change in EXR open from CS2 to CS3 can this be fixed?" #62, 3 Feb 2009 12:04 pm </webx?14/61>
Wow, this thread is pretty intense. I wish someone had pointed me to it earlier. I’m a bit biased, but I agree that ProEXR solves all the alpha problems mentioned here. It was created by someone who works in the VFX industry (me). You can try it free for 15 days.
This is covered in the ProEXR manual and in this thread, but to recap: OpenEXR files use premultiplied images, while Photoshop long ago chose to use straight. Turns out this was an unfortunate choice because, as Florian and others pointed out, any non-black premultiplied pixels with a black alpha will get decimated when converted to straight. Nuke, Shake, and Fusion are premultiplied, so they don’t have this problem. I can’t think of any advantage to using straight, but it would probably be hard to switch back at this point.
Sometimes VFX artists don’t actually want Alpha to be transparency, although that is the standard thing to do and it’s the ProEXR default as well. But we also give you a dialog for changing the behavior if you like. You can keep the alpha channel separate and choose whether to un-multiply the RGB. I don’t know if Adobe should change what they’re doing in their own plug-in, but I’m glad I could swoop in as a third party developer.
If you have other ideas for making ProEXR better work in a film workflow, let me know.
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.
Chris, we’ve been over this before on the CS4 beta forums and it really surprises me how you stick so much to the "EXR File Specs"
Obviously a lot of people are really annoyed that they can’t use EXR (a file format created BY the FX industry FOR the VFX industry!) anymore like they did in CS2. First I thought it was just Mental Ray’s Problem, but it turns out that Renderman creates the same problems.
I really think it is Adobe’s time to move on this and make a little File Open dialog where you can choose how to treat Transparency and Alpha channels.
It doesn’t matter if it’s different from the EXR specs Chris! People need to be able to use their renders and pipelines and need this flexibility!
We also use ProEXR sometimes, but it is really sloooooow, so at the moment we have a separate machine with CS2 installed and save all our EXRs as PSB files, which is very annoying too.
– Either make it an option in preferences ("Treat additional channels as transparency or leave them alone")
– Or apply the Alpha as a layer mask, so the user has the option to enable or disable it at will.
The current implementation is destructive and very very very annoying.
And this is true for EVERY single format that supports more than RGB, not only EXR.
I do graphics for 15 years and I NEVER EVER even once wanted the behaviour that Photoshop is showing.
Photoshop it THE melting pot for billions of images from thousands and thousands of sources. This is not about being right or SPECs etc. (you can’t win this uphill battle anyway)… This is about creativity software. People want a choice.
This is not a game where you score points by belittling the work of your customers.
The folks who have commented on this thread as a result of cross-posting in the nuke list are not a bunch of drive-by hecklers, and we seem to be doing our best to add some clarity and represent our interests.
The computer graphics and visual effects community does have a sense of ownership over OpenEXR, because it was designed to work well in our pipelines. Adobe’s customer base is so large that a seemingly miniscule change like we’re talking about can break the things that we depend on. TIFF is a good example of this.
The EXR spec hasn’t been updated for a while- probably because the folks who wrote it have moved on to other problems. Perhaps if you’re not interested in listening to the concerns of the community, you could simply not support it, and give some breathing room to the plugin developers.
"We also use ProEXR sometimes, but it is really sloooooow, so at the moment we have a separate machine with CS2 installed and save all our EXRs as PSB files, which is very annoying too."
Christoph, I’m aware of the speed issues when dealing with big images. The slowness is actually not within ProEXR itself but with Photoshop when I request/provide pixels. You can verify this by checking your CPU meter in those instances and seeing that none of the processor cores are very active. ProEXR is currently optimized to use as little memory as possible, but perhaps that’s not meshing with however Photoshop works internally.
I’m in the process of experimenting with different combinations of memory usage and pixel region requests – hopefully it’ll yield some improvements.
Brendan – you should be working in larger tiles (256 rows, or 256×256 makes a good starting point) instead of writing a row or a small area at once. The fewer times your plugin calls back into Photoshop, the faster it’ll run. (we have a lot of cross DLL overhead to deal with, plus error checking on each and every call)
Zap – Please read some file format documentation. Your discussion on premultiplication is mostly wrong (with just enough right to confuse people who aren’t familiar with the math).
Photoshop supports more blending options and filter options than most packages — and for what we do, unmultiplied data is much faster in the majority of cases than using premultiplied data. (otherwise you spend a lot of time un-multiplying, operating on the color data, and remultiplying — which some other applications do)
With recent (1994 or later) CPUs, compositing operations are almost entirely limited by DRAM bandwidth or cache bandwidth and not by calculations – the small amount of calculation saved by premultiplication is irrelevant.
If you want to change the definition of OpenEXR – you shoud seek a change the official spec. We implemented OpenEXR support in a way consistent with the spec. to ensure interoperability. That spec. exists to make sure that there is no confusion in interpreting the contents of the file.
You are asking me to add confusion to the interpretation of every EXR file, to throw away interoperability. With your change, nobody using an OpenEXR file would know whether the A channel should be opacity or an unassociated alpha, or whether the A channel was premultiplied or not. If they guess wrong, things will break (and they only have a 1 in 4 chance of getting it right). Your request would break existing workflows that rely on the specification, that use the intended interpretation of the data.
You are asking me to add extra UI on opening and saving an EXR file that will slow down the workflow of anyone using the OpenEXR file format (and probably confuse the blazes out of those not in the VFX industry).
I need a *REALLY* good list of reasons to make a change that affects so many users, especially when the change is only benefitting a relatively small number of users. And even more so when you are clearly ignoring standards or misusing the tools ("But I want my screwdriver to drive nails better"). If you have good reasons, please communicate them. But you’ve got to stop the drive by postings and "because we said so" arguments – they’re still doing your cause more harm than good.
BTW, everyone, you can get back the functionality of the Over mode found in Nuke/Shake by manually reconstructing the transfer mode with two layers. So with an RGBA EXR you’d:
1. Open with ProEXR, using the option to put the A channel on a separate layer. It should appear beneath the RGB layer.
2. Put your background layer beneath these two layers.
3. Invert the A layer and set the transfer mode to Multiply.
4. Set the RGB layer to Linear Dodge (Add).
And there you have the exact math Florian described for compositing premultiplied images. Now, this approach can definitely be fraught with problems and headaches dealing with two layers, but it can come in handy in a pinch.
After Effects has the Luminescent Premul transfer mode to do the same thing. It also can be problematic, especially when you try to use plug-ins that are assuming a straight alpha.
Chris, would you mind explaining how a simple option (default being it’s current implementation) will make matters worse? Or how it will confuse everyone?
I think one solution to the "breaking the workflow" scenario would be to have a button/tab called "Advanced". If you don’t know anything about EXR, then you probably should use the "Advanced" feature. Many applications out there use this approach. Perhaps it’s a worth considering.
Konstantin – A semi-hidden advanced option might work, and at least minimize the confusion on the UI side. Right now there is no UI for OpenEXR in Photoshop, so just adding a UI will slow down some workflows (especially those that are currently automated and don’t want to stop for a UI). BUT, I’m adding UI for saving different bit depths and other new EXR options – so that issue isn’t a big deal.
The bigger issue is the interpretation of the file contents, and how that works when sharing the file with other users (especially ones at another company or site).
I think anyone twisted enough to click the advanced exr tab will be comfortable being personally held responsible for the outcome. I am confident the only impact on the industry will be more smiles.
Thank you for considering this option. Would you mind sharing your intentions with the remainder of the exr spec implementation you mention above?
"A semi-hidden advanced option might work, and at least minimize the confusion on the UI side. "-Chris Cox Could we enable what we want through the Photoshop API, via a script? If it can be implemented earlier than a new gui element, that would work at Warner Bros and maybe for a few others, for now until the hidden gui is available. Thanks for helping us, (not my first post in pshop forums) Graham
The big post houses who have had the most experience so far with the .exr format use tools that require their artists to use a transparency channel as data in whatever way they require.
There are plenty of situations where for artistic / technical / economic reasons an artist does not want to mDiv a plate by the transparency/alpha channel or wants to use a transparency/alpha channel embedded in a different .exr
Chris is right that maybe us VFX guys should have two channels, one for transparency and one for alpha to avoid confusion/mistakes i.e. for those that don’t understand the multiplication/division process. But implementing this in a workflow or comp would just be messy and expensive.
It matters not if the .exr has beens saved ‘to standard’ but if the workflow for that artist/post house gets the best result with the available resources. We want to use Photoshop, as it is the best paint tool on the planet, but we cant because it breaks our workflow. All of our tools let us save the transparency channel in whatever state we choose to get the job done, and consequently we need that same choice when opening up an .exr
This thread has done the rounds in many of the big post houses now and I don’t see any of those recognized artists come forward and tell us we are all talking rubbish here, just people like Chris and Zap trying to clear up some common misconceptions about various definitions.
I need a *REALLY* good list of reasons to make a change that affects so many users, especially when the change is only benefitting a relatively small number of users.
this thread has made me really curious.. the question has been asked a couple times now and not answered. among adobe’s customer base, who is using OpenEXR with photoshop besides the VFX community?
i’m asking this with complete sincerity, not trying to be snarky. other than education/research, what other sectors are making use of the format that makes the VFX community such a tiny slice of the pie?
Can someone from Adobe with a personality and the ability to communicate in a lively discussion without being a smart ass please chime in. There are several points here that Chris is choosing to ignore. First, no one asked you to change the implementation of OpenEXR in PhotoSlop. And secondly, everyone is asking you to change it back and you are telling them they are all a bunch of idiots and they do not know what they are talking about. Can Adobe please stop screwing up the application every time you release one of these overpriced updates that should be a free online update? All you are doing is destroying the existing workflow that we have all spent years developing in order to justify these so called updates, and doing it without the users requests or input.
Please, someone else from Adobe reply to this thread, as we do not need one more redundant reply from Chris Cox telling us we do not know our you know whats from a hole in the ground. Instead we need answers and measures to address the problem, possibly an option within the Adobe implementation that allows a check box or options. At the very least we need to be listened to, because this stubbornness and arrogance is really making me wish I had competing options of software.
Photographers are using OpenEXR for HDR photo work (someone told them it was the best format for HDR), 3D artists are using it for some textures and final renders (not the same as VFX, and so far they use the transparency as per the spec.), some studios have standardized on OpenEXR files (but most use it as defined in the spec.), and some effects houses have also standardized on OpenEXR – but some use it according to the spec. and some don’t.
There are other market segments experimenting with OpenEXR, but that haven’t standardized on it that I know of (astronomy, medical, etc.). Most of those would probably be better served with a different format, and the number of users isn’t huge.
Basically, OpenEXR was described as the answer for all HighDynamicRange image needs – and people have been adopting it whenever they have HDR data. Some people find EXR too limiting and go to TIFF, a few are still using Radiance files, and those just curious about HDR and using Photoshop can stay with the PSD/PSB format. (and researchers just write their own file format for each new project anyway) The ILM name has helped "sell" OpenEXR to people well outside the VFX and movie/video industries.
I don’t have hard numbers for EXR users – HDR usage is growing and changing rapidly. But we have done a lot of customer visits, we talk to a lot of customers, and try to keep up with forums, publications, newsletters etc. to see what people are doing and using. From that I have estimates on the sizes of the various market segments using the EXR format. I wish I had real market data I could throw around – but I don’t do marketing, and it’s not like cameras (or software) where I can just check someone’s sales figures.
Sigh.
The bad part of working on Photoshop is that we have to think about how changes we make will affect many people across many industries and market segments. There are lots of changes that I would like to make, that make sense to me, but would confuse the blazes out of almost everyone else (well, other than Stu). So, either I find a better way, or don’t do it.
Let’s see if an analogy will help: when you’re canning fruit for yourself and a few dozen friends – you can take shortcuts and nobody will care. But when you’re canning fruit for millions of people to consume – you have new rules, regulations, insurance, and a lot of other things to take into consideration if you want to stay in business and out of jail.
I don’t mean to belittle anyone here — I’m just trying to help you understand my perspective on this.
Adobe staff does not regularly monitor the Adobe forums. When members of the Adobe team show up here from time to time, they do so as volunteers and on their own time.
We are very fortunate in this particular forum to have Chris Cox contributing after a long absence of about a year. I don’t recall any one higher in the Adobe chain of command than Chris ever participating here in the last six yearswith the possible exception of an isolated post or two by someone else about three or four years ago.
If you want to address Adobe, use the Contact link at the top of this page.
Personally, I don’t give a damn about EXR, Open EXR, "the VFX community" or anything related to video or the film industry. As far as I’m concerned, your whole "industry" could disappear without my ever noticing it. However, I do have a keen interest in preventing this forum from becoming a hostile environment in which Chris Cox is not inclined to participate any longer. He has been of great assistance in the past.
Clearly, this is not the venue to spew your ill mannered, insulting and idiotic comments. As I said, contact Adobe directly or use the Feature Requests section of this forum if you think you are capable of expressing yourself like a thinking person.
Somehow the quote "I reject your reality and substitute my own" comes to mind here. 🙂
No, my explanation of alpha channels is not "wrong" in any way, shape, or form. If it is, please point out my error, and back it up with documentation that it is in error. And the incorrect TGA format documentation that tends to accompany some Adobe products most *certainly* do not count.
The reason Adobe is very stubbornly turning a blind eye to proper premultiplied behaviour, is because they use a straight alpha pipeline internally. This pipeline is *incapable* of representing a color such as premultiplied (1,1,0,0) (the "additive yellow" I mentioned in last post). Due to this complete inability to even represent this, they have a vested interest in defining it out of existence and claiming it "wrong", while it is not. Which I bet accouts for 90% of the stubbornness preceived in this thread.
Adobe products use a "straight" alpha (where alpha is considered more as a "mask" than opacity) because they stem from a paint tool background, where a "mask" is something you create out of pixels that are already there.
With that mindset, saying you have "multiplied with the alpha" in a premultiplied file makes sense.
But from the context of a renderer, this makes no sense. In a renderer, it’s about taking samples off some geometry. In the simple case of opaque objects, lets say we take 16 samples in a pixel. 12 of these hit an opaque yellow (1,1,0,1) object, and 4 of these hit the background (0,0,0,0).
When summing up these samples, we get a color that is (0.75,0.75,0,0.75). This is not because we have "multiplied with alpha", it is simply because there was a *coverage* of an entity with an alpha of one in 75% of the pixel.
Now assume instead that the background was red (1,0,0,0), which is quite legal. The downsampled pixel would have a color of (1,0.75,0,0.75). And pixels where NO samples hit would have a color of (1,0,0,0).
While this may not be so useful for traditional compositing, it can be useful for all sorts of other reasons. For example, a 3ds Max render always sets the alpha to 0 in pixels that are "background", even if they are filled with, say, a sky, or anything else. So there is completely legal RGB data there, but with an alpha of zero.
If this is put into an EXR, and loaded by Photoshop, this sky is now lost forever. So data is clearly destroyed in the process.
We furthermore have these luminiscent pixels. Go back to our object-against-a-background issue, but instead of making the object just yellow, lets make it luminiscent yellow, i.e. (1,1,0,0). When this object covers 75% of the pixel, and the background is transparent black (0,0,0,0), the final pixel will be 0.75,0.75,0,0.
This means that when this color is comped on top of the underlying layer, the premultiplied "over" operation, which is…
r = fg + bg * (1 – fg.a)
….will work out to an add, since the alpha is zero, and hence (1-alpha) is (1-0), e.g. 1, so the math boils down to
r = fg + bg
The fact is that photoshop simply cannot do this, because it is "straight alpha" internally.
After Effects is kind of limping along here with the "Luminiscent Premultiplied" mode, but it is still a hack and breaks down any time you add even the slightest effect, since the AE effects pipeline is also, unfortunately, straight alpha.
Straight alpha has a few merits (notably with multiplicative post math and in color correction), but ends up being needlessly complex (compared to the premultiplied math) for lots of other operations like blurs, filtering, etc. The math in the premultiplied case can simply treat the alpha as another channel, and apply the exact same operations to it as it does to RGB, for things like blurs, convolutions, whatnot. A "straight alpha" system has a much much harder time here.
But hey. What do I know? Apparently I’ve been "defined wrong" in this discussion, even though I have the inventor of the alpha channel on my side.
Personally, I don’t give a damn about EXR, Open EXR, "the VFX community" or anything related to video or the film industry.
You’re in the wrong thread and off-topic, troll.
If there is one hostile person in this thread, it’s Chris Cox. Mr. Cox, I still want to see some *clear* statement about industries which are bigger users of OpenEXR and would be negatively affected by the inclusion of an option or even of a preference. You were very specific that changes in the workflow would greatly affect a much larger number of users than the VFX industries yet in the post were you were supposed to clarify this the information was very vague: "some market segments are experimenting", "I don’t have hard numbers", "some studios, of which some use it as in the spec and some not","texture artists". And photographers interested in HDR, this being indeed probably a significant community (I’m talking about numbers). I fail to see how a preference or dialog box on open (and with a checkbox "Don’t show again") can affect in a bad way the workflow of anyone you mentioned.
This topic, although quite heated with comments from many first-time visitors, has none-the-less been pretty civilized and articulate until post #115.
It is rare to have someone as directly involved in Photoshop development as Chris Cox appear and respond as he has here. Whether you agree with his viewpoints or not, he’s a valuable asset to these forums, particularly to the many who have been regular participants over the years.
For this topic, everyone is welcome to make his or her point so Chris can use them to evaluate any future changes in the app. It’s to no one’s benefit to make him feel unwelcome.
So please, let’s keep the topic to the point and name-calling and accusations out of here. I do not want to be put in the position of closing this long topic.
This is quite a thread. I’m writing as one of the people on the After Effects team that finally chose to throw in the towel on spec purity and add options are users needed.
To summarize this whole thread in my own words: The spec is very clear that OpenEXR images are linear data and premul with their alpha data. What Photoshop CS4 extended is doing is technically correct and following the standard.
Alas, many, many other products, and people using OpenEXR’s manage to stuff all sorts of data into RGBA which doesn’t conform to the standard.
In the AE CS3 beta cycle we tried to conform to the standard. But in the end, we found so many ‘perverse’ OpenEXR files 😉 , that we decided it was better for After Effects to be flexible enough to deal non-conforming files and further pollute the workflows than to follow the standard.
As Chris Cox pointed out, the Photoshop customer base is different than After Effects and the PS team has a different risk tolerance for adding support for non-conforming workflows. I’m not going to try and guess what percentage of Photoshop users are trying to work with non-conforming OpenEXR files. Clearly there are at least the number of posters in this thread ;).
Luckily both AE and Photoshop support file format plugins. For those of you who need support for non-conforming OpenEXR files in PS CS4, Brendan Bolles sells the ProEXR plugin. AE CS4 actually ships with his OpenEXR plugin for AE.
A number of people have written to bring this thread to my attention. I haven’t had time to read through all 120+ posts (!), but I’ll try to do so shortly (isn’t that what weekends are for?).
At the end of the day, we have to do what’s useful to you, and we will.
To summarize this whole thread in my own words: The spec is very clear that OpenEXR images are linear data and premul with their alpha data.
But, as I said many times before, to say this is to *fundamentally misunderstand* what "premultiplied alpha" means.
All it *really* means is DO NOT MULTIPLY in your "over" operator.
I.e. do NOT do
r = fg * fg.alpha + bg * (1 – fg.alpha)
but do
r = fg + bg * (1 – fg.alpha)
That is ALL it means. Which, if you actually read the technical document, to OpenEXR as Florian himself (part of the team writing it!!!) posted above, *actually says*.
Yes. It *explicitly says* that the format of the RGBA data is such that the "over" operation should be
r = fg + bg * (1 – bg.alpha)
To draw from this the conclusion that a color with zero alpha and nonzero RGB is "illegal" and can be thrown away is quite an unfounded extrapolation to make!!
And also note that the spec says that this is *by convention*. Not rule, nor law, but by *convention*. I.e. "the most common case".
What Photoshop CS4 extended is doing is technically correct and following the standard.
So not using the channel labeled "alpha" as an alpha channel is tecnically correct? To throw away fully legal RGB data just because Alpha is zero is correct?
For those of you who need support for non-conforming OpenEXR files in PS CS4, Brendan Bolles sells the ProEXR plugin. AE CS4 actually ships with his OpenEXR plugin for AE.
Please correct me if I’m wrong, but the solution is as easy as cloning and installing the same ProEXR plug-in in Photoshop CS4 as is included with After Effects?
For those of you who need support for non-conforming OpenEXR files in PS CS4, Brendan Bolles sells the ProEXR plugin. AE CS4 actually ships with his OpenEXR plugin for AE.
Please correct me if I’m wrong, but the solution is as easy as cloning and installing the same ProEXR plug-in in Photoshop CS4 as is included with After Effects CS4?
Neil, the ProEXR plug-in for After Effects is an AE-specific plug-in. It uses the existing 3D channel API to send those extra passes through. The AE plug-ins are free, open source, and ship in CS4. It doesn’t do anything special to the alpha channel because AE already has settings to deal with that.
For Photoshop, it’s a totally different plug-in (Photoshop API), doing a totally different thing (making layers), and er um it’s not free.
since you claim to know exactly what I mean, without actually discussing this with me outside this rather bizarre thread, I would like to clarify that I, as the original author of OpenEXR, completely agree with Zap Andersson’s post earlier today.
"Premultiplied alpha" describes how the "over" compositing operator is supposed to work. Premultiplication does not mean that A == 0 forces R, G and B to be zero. As I mentioned earlier in this thread, zero A with non-zero R, G and B is a perfectly legal combination. It represents a self-luminous but completely transparent object, not an abuse of the OpenEXR file format.
Photoshop is an outlier in how it treats OpenEXR’s A channel; Nuke, After Effects, and many other programs handle A differently. The OpenEXR specification does not say that Photoshop is right and everyone else is wrong.
I agree that Photoshop’s implementation can be considered "correct" (except for the A == 0 case, which started this whole thread in the first place). However, there are other correct – and more useful – ways to handle the A channel.
Frankly, I don’t understand why OpenEXR is "the wrong file format for what [some Photoshop users] are trying to do." Plenty of other applications let users do what they want to do. Personally, I’d say this is strong evidence that the file format isn’t really the culprit, but Chris, I’m sure you’ll find a way to refute that.
Sigh. I guess I need to write a tutorial on what premultiplied and non-premultiplied color mean and how they relate in different applications and contexts. (and probably document why straight color works better for editing)
From the viewpoint of an application that works with straight color, premultiplied does mean that you multiply the color values with the opacity channel (same as compositing over black while leaving the opacity channel intact).
From the viewpoint of an application that works entirely in premultiplied color, you could have non-zero color values even if the opacity is zero. Whether those values are useful or garbage is debatable (since if you just add them you suddenly have changes where you claimed to have no opacity).
But you can’t get from the straight color system to the premultiplied system without multiplying the color values by the opacity values. Wherever the opacity was zero, the premultiplied color values become zero.
When going from premultiplied color to straight color, you have a clamped division operation. And what color is the result of a non-zero color value divided by zero opacity? Unfortunately, it is undefined (infinity is an easy answer, but that kinda breaks later processing).
Florian – partly I’m going from what you wrote in the spec., and partly from previous conversations (email, phone, and at your office).
There is no notion of "self luminous but completely transparent" in straight color — you must have some opacity for any color to appear. That concept of color without opacity only works in a premultiplied pipeline (but still breaks some filtering stages).
There are 2 requests here so far:
1) to treat the color in EXR as straight color, not premultiplied (or at least open it that way and let them do other work on the data) 2) to open the A channel as an arbitrary alpha channel, not opacity
Both of those go against the spec. as written and break interoperability for EXR files. If you intended for those to be allowed, then it was not communicated in the EXR spec. And I strongly feel that allowing them will create more confusion around the interpretation of EXR files. What is written into the file should have one, clear, unambiguous meaning. Having multiple potentially valid interpretations of the same file data leads to big messes (even bigger than we’re dealing with here).
What "premultiplied" means, in fact what any word means, depends on who uses it. That’s why technical documents generally try to define important terms before using them.
Since the OpenEXR documentation is ambiguous enough to allow the present discussion to take place, I will augment the documentation. On about page 5 the "Technical Introduction" states:
[The A channel represents] "alpha/opacity: 0.0 means the pixel is transparent; 1.0 means the pixel is opaque. By convention, all color channels are premultiplied by alpha, so that "foreground + (1-alpha) × background" performs a correct "over" operation.
I will add following (or something close to it):
Note: describing the color channels as "premultiplied" is a shorthand for describing a correct "over" operation. With un-premultiplied color channels, "over" operations would require computing "alpha × foreground + (1-alpha) × background."
"Premultiplied" does not mean that pixels with zero alpha and non-zero color channels are illegal. Such a pixel represents an object that emits light even though it is completely transparent, for example a candle flame.
Since pixels with zero alpha and non-zero color can and do occur in OpenEXR images, application software must avoid discarding the color information in pixels with zero alpha. This can be a problem for applications that internally use an image representation where the color channels have not been premultiplied by alpha. After reading an OpenEXR image, such an application must undo the premultiplication by dividing the color channels by alpha. This division fails when alpha is zero. The application software could set all color channels to zero wherever the alpha channel is zero, but this can alter the image in an irreversible way. For example, the flame on top of a candle would simply disappear and could not be recovered.
If the internal un-premultiplied image representation uses 32-bit floating-point numbers then one way around this problem might be to set alpha to max(h,alpha) before dividing, where h is a very small but positive value (h should be a power of two and less than the smallest positive 16-bit floating-point value). The result of the division becomes well-defined, and the division can be undone later, when the image is saved in a new OpenEXR file. Depending on the application software, there may be other ways to preserve color information in pixels with zero alpha.
Florian – ok, I think we can deal with that, and that minimizes the loss due to premultiplication of the color data.
But that does not address the requests here to treat the A channel as non-opacity, or the requests to treat the color data as straight color. Those requests might be based on misunderstandings of the situation, but it’s difficult to tell from the posts made here.
In Florian’s words in the tech doc, and like others have pointed out, it’s only a "convention" so that should leave the door open for better PS flexibility in the EXR reader: an option to treat the A channel as non-opacity. At least until you have multi-channel EXR support, like Erik said.
Pretty please? With a cherry on top? Whipped cream? Sprinkles?
Wow, we’ve come to a conclusion! Thank you, Florian, for the addendum, and thank you Chris for listening patiently. It’s really appreciated.
Layer masks may be technically very different from Transparency, however, in a user’s perspective a layer mask does the same job and is more accessible. The root of the problem is that Photoshop hides the Transparency channel. If Transparency would just show up in the Channels palette, and would be editable, we wouldn’t have this discussion in the first place…
Here is a constructive approach on how to provide options for advanced users without confusing everyone else. How about triggering the options dialog with a modifier key when the image is loaded? Hold CTRL on PC, or Option on Mac – and you get to all the advanced and (and possibly dangerous) settings: Alpha behavior, display/data window, linear/gamma. The standard behavior can stay as it is, and the casual HDR photographer won’t know and won’t be confused.
I’m very happy that such a discussion can actually be held in a constructive and civilized manner. Thanks to everyone for their patience.
We don’t have a conclusion just yet – but responsible parties are talking offline.
Exposing the layer opacity channel would require quite a few changes, and a lot of testing. That’s not going to happen quickly. What I have proposed is a way to move the opacity data from a layer into a layer mask while setting the layer opacity to 100% opaque (currently you can do that for 8 bit easily, but can’t do it correctly for 16 and 32 bit/channel). That exposes all the color values, and allows for independent editing of the opacity values. The command to reverse that transform is already in Photoshop (Apply Layer Mask). While that will help one nice person who really needed to edit his opacity values post-render, it does not solve any of the premultiplication issues.
Florian’s suggestion to pin opacity to a really small number may help the premultiplication issues. But I’m not sure it’ll solve everyone’s issues as posted here.
Feb 6, 2009
Thank you Chris and Florian and everyone. I know I’m a total noob in this crowd and that I don’t have much more than a "just because" argument.
This has turned into a great thread. I have read every word and I really appreciate all of the input and information. I’ve learned a lot.
We have one license of ProEXR (which we love) on a community workstation and that is solution enough for the time being. I look forward to reading further discussion.
One last thing: for everyone’s testing pleasure I shot two new photos for the OpenEXR sample image collection. The new images demonstrate use cases for pixels with zero A and non-zero RGB values. You can download the files from here:
Wow, you ILM guys have some cool toys, including now a camera that can shoot alpha channels?!? 😉
Neat images, Florian. I composited them in Photoshop using the 2-layer technique I mentioned earlier. BTW, Photoshop’s Invert function is disabled in 32-bit mode, so I had to use Levels and set Output Black to 255 and Output White to 0. (Don’t ask me why Levels uses 8-bit values in 32-bit mode.)
Chris, I think the standard Invert math works perfectly well in float and I imagine anyone who uses Invert in 16-bit will miss it in 32-bit (especially when working with a layer mask or something like that). Yes, anything >1.0 will end up negative, too bad there isn’t some sort of clip operator in Photoshop to take care of that.
The Levels UI situation is very problematic in linear space because the Input Black and Output Black settings get far too sensitive and the difference between 0 and 1 (8-bit code values) is too much. I’d like to enter 0.5 in there if only it’d let me. Or give us real floating point 0.0-1.0 entry. I doubt anyone working in 32-bit mode would be put off by this.
Brendan – while the math might work, the result is next to useless. (1.0 – x) works when the values are all between 0.0 and 1.0, but isn’t very useful when the values are -infinity to +infinity. While some people might be able to understand the math and make use of it (if the exact math was documented for them) — the vast majority would not (and would file bugs about it).
We’re still working on a better UI with more precision (that doesn’t cause other problems). The same goes for a number of other areas related to 32 bit images.
I’m really happy this discussion is getting somewhere. Special thanks to Florian.
And that Chris (& Adobe) is finally seeing the light of what "premultiplied" really means. (Perhaps even luminiscent yellow light 😉 )
I do however hope everyones understands that this definition of "premultiplied" applies to every format with an alpha channel, i.e. TGA’s, etc. etc, i.e. 1,1,0,0 is a legal color in a TGA file as well (well, it’ll probably be 255,255,0,0 but you get the idea).
No, many file formats are not premultiplied, and some file formats support an alpha channel that has nothing to do with transparency/opacity.
TGA is not premultiplied (some people think it supports opacity, and some don’t). PNG is not premultiplied, and only supports opacity. TIFF is premultiplied if you use opacity (associated alpha), and not if you only use unassociated alpha channels (because they aren’t opacity, the color data cannot be premultiplied).
Just because the format has a place for some extra data – that does not mean that the format supports your interpretation of the data. Most file formats are pretty specific about how the data should be interpreted, but some are not, and some (TGA) have grown a following of users who just ignore the specification entirely.
Users only use what is programmed Chris… if you wish to bang the standards drum, bang it to other developers, but trying to shut the stable doors when 1/2 the world are riding the herd and asking them to come back isn’t going to work… especially when it’s within the same product.
As I keep saying. Alpha is a representation of opacity. It is not opacity per se. If that was the case it would be impossible to have something at 0% opacity with an RGB value… but it isn’t.
It’s really simple. Removing the alpha shouldn’t take the RGB values with it.
Now, if you say these RGB values still exist, and that it’s possible to get them back even though the A is no longer accessible, then let’s have that functionality.
Just because a format is premultiplied doesn’t mean you can chuck the alpha willy nilly. It still serves a purpose, even as opacity.
But you can’t go around ‘fixing’ things that people have learnt to work with in a productive manner. Well not if you want the quiet life, or the nod of approval from those that lead the industry.
Call it serendipty, whatever, but it worked before, it’s been shown to work with plugins, it’s simple it’s current state that’s broken. I can hoop jump to fix it, but what’s the reason that I have to do that except your interpretation of something…?
There seems little point in sticking with something that breaks the interest of so many.
If Adobe is interested in an expanding market, perhaps it should think about not shrinking the one it has. Given the nature of HDR images, it’s not like it’s something the novice user is going to care about.
It’s another reminder of how out of touch Adobe have become with their user base.
Feb 11, 2009
LOL. Hey "progress", how about starting another thread with your last post? You could title it something like Dead Horse.
I think the discussion has progressed well beyond these points and is going in a very positive direction. Let’s not impede the effort at this point eh?
I also thing there is a misunderstanding of the pre vs straight. The data is written the same, but the data before it’s written is different in each case. Therefore a format can carry pre or straight, but the image data written is different. You can’t bounce between the two after they’ve been written but you can beforehand. I can choose to save pre or straight on the point of saving to TGA. The image looks the same before I do that, but the results are different, yet either straight or pre, the file is still RGBA.
You know what this whole discussion reminds me off?
I once sat in a train, across the corridor there was a family sitting at a table with the kid (maybe 4-5 years old) drawing with color pencils, the father reading a a paper and the mother reading a book. Suddenly the father reached out and bashed the kid HARD in the face yelling: "There is no such thing as a green dog".
One of the most shocking experiences I ever had.
Once upon a time, software was developed for the user who paid money to get things done faster and more flexible.
If a software company representative tells me that what I want is wrong, not to spec, that I have no clue about compositing if I even think about using a channel for something else as what somebody defining a file format intended ( but most probably never intending as rigid an interpretation) and that many many people will suffer from extreme confusion if they are presented with a choice about how a channel should be interpreted somewhere in advanced preferences, I can only walk away with a very irritated feeling of extreme absurdity.
I highly respect everybody here, but pussyfooting around a guy who simply is using his position of assumed "power" to tell everybody off and that "there is no green dog" is absurd.
Chris: may you live a long, full and happy live as far from the specs as possible. 🙂
I think we should not adhere to any specifications. That way we all can all do what we want – kind of like how the product is packaged and sold… Make perfect sense to no one and everyone is happy.
Yes, but you have to understand that Chris can only do what he can in his environment. He has people to answer to and more then one company as well. To be honest, Adobe is out of control at this point and they have lost the essence for fear of retaliation by its customers. It’s a case of damn if you do and damn if you don’t. The real problem is the people higher up who have NO BUSINESS making decisions on how and industry shall be steered are the ones pissing off the majority of people that are being affected by said changes.
All this comes down to the lack of market research in the industries they cripple based upon their semi tempest decisions – do to the lack of actual real world experience because they are developers and not entrenched in any specific field they affect.
I call it irresponsible plight for the sake of corporate stock holder edification.
But we all do what we can as individuals – but the real problem is tunnel vision because Adobe REALLY does not understand the markets they cater to…
Learn how to rescue details, remove flyaways, add volume, and enhance the definition of hair in any photo. We break down every tool and technique in Photoshop to get picture-perfect hair, every time.
Related Discussion Topics
Nice and short text about related topics in discussion sections
