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

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.

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

Invert doesn't work so well when your limits are -infinity to +infinity

Level is just using UI that customers are familiar with....

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

Brendan

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:

http://cvs.savannah.gnu.org/viewvc/OpenEXR-images/ScanLines/PrismsLenses.exr?root=openexr&view=log
http://cvs.savannah.gnu.org/viewvc/OpenEXR-images/ScanLines/CandleGlass.exr?root=openexr&view=log

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. It's almost as helpful and constructive as a VRay forum thread!

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.

Thank you everyone.

Jonah

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.

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.

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?

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.