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

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

"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

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?

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 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 not use the "Advanced" feature. Many applications out there use this approach. Perhaps it's worth considering?

Cheers,

Konstantin

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?

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.

Brendan

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.

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.

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