Change in EXR open from CS2 to CS3 can this be fixed?

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.

Cheers

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.

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?

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

Hi Chris,

Like Alan said, I think "contortion" is quite a good word to describe the experience me and my colleagues had while fitting Photoshop into our Nuke-based vfx compositing pipeline for a major studio just a few months ago.

And reading through this entire thread... I'm exhausted by it. Please please listen to Progress, David, Jonah and Alan etc. Can we get a little flexibility here with PS's EXR behavior?

Or is this an exercise in squaring the circle? :(

Cheers,
-Ean Carr

Chris-

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.

gary

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.

Alan

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.

cheers,
dg

> If AE has it why can't photoshop have it?

If you keep pushing it, it might well disappear from AE. :D

Ill agree with those here in the industry who are asking for this functionality. We need options, albeit with the reasonable defaults Chris is talking about.

We use unpremultiplied imagery like this often in certain circumstances, and we know we are not the only ones. Nuke and Shake and Fusion all do not force you to be premultiplied or unpremultiplied, making you have to handle all this yourself. Being able to be smart about how we make our file import interpretations allows flexibility. If you want to paint a mattepainting for reprojection onto cg, you may want to start with the painting first, and then start to hack away(make transparent in the final render) parts while you go through the iterative development process. If you eat in too much by painting black on the alpha and you have saved it, you want the ability to go back and "undelete" that area. The alternative now is to have a psd master file with a layer mask, and then bake down an rgba version every time you make an edit, this adds an additional file and management to something which could be simplified by adding this import/saving behavior option. If AE has it why can't photoshop have it?