-
"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.
I'd welcome any help from Adobe on this one!
Brendan|Mark as: -
-
Brendan - you should be working in larger tiles (256 rows, or 256x256 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)|Mark as: -
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.|Mark as: -
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.|Mark as: -
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|Mark as: -
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|Mark as: -
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).|Mark as: -
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?|Mark as: -
"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|Mark as: -
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.|Mark as: -
chris,
>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?
regards,
erik|Mark as: -
Can someone from Adobe with a personality and the ability to communicate in a lively discussion without being a smart *** 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.|Mark as: -
Erik;
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.|Mark as: -
zDarius,
Adobe staff does not regularly monitor the Adobe user-to-user 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.
[Edited formatting.]|Mark as: -
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.
/Z|Mark as: -
>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.
Dragos|Mark as: -
This topic, although quite heated with comments from many first-time visitors, has none-the-less been pretty civilized and articulate until post #117.
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.
Thanks!
Neil
Forum Host|Mark as: -
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.
Thanks!
Neil
Forum Host|Mark as: -
Hi Folks,
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.
--chris prosser
ae engineering manager|Mark as: -
Hi folks,
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.
Thanks for your passion & patience,
John Nack
http://blogs.adobe.com/jnack|Mark as: -
> 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*.
http://www.openexr.com/TechnicalIntroduction.pdf
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?
/Z|Mark as: -
Chris,
>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?
Neil|Mark as: -
Chris,
>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? Or is there a specific version for Photoshop?
Neil|Mark as: -
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), anderumit's not free.
Brendan|Mark as: -
Chris,
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.
Florian|Mark as: -
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).|Mark as: -
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).|Mark as: -
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.|Mark as: -
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.|Mark as: -
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?|Mark as: -
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.|Mark as: -
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.|Mark as: -
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|Mark as: -
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/PrismsLens es.exr?root=openexr&view=log
http://cvs.savannah.gnu.org/viewvc/OpenEXR-images/ScanLines/CandleGlas s.exr?root=openexr&view=log|Mark as: -
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|Mark as: -
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|Mark as: -
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.|Mark as: -
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).
/Z|Mark as: -
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.|Mark as:
Adobe Forums powered by Jive SBS ® 4.5.6.3 forum software
Jive Software Version: 154630
© Jive Software
Choose your region
United States (Change)
Choose your region
Close
North America
Europe, Middle East and Africa
Asia Pacific
Copyright © 2012 Adobe Systems Incorporated. All rights reserved.
Use of this website signifies your agreement to the Terms of Use and Online Privacy Policy (updated 07-14-2009).