Forums

well swapping the plugins doesn't work, the plugin wont load under cs3 intel

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.

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.

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?

Chris, it's not. It's really simple.

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.

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

Thanks for the link Florian.

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)

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.

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

i 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 ! :D

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?

i which Photoshop doesn't let you do easily.

which should read ;

which Photoshop did let you do easily, but has been broken.