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

[_progress_]

It seems the monkeys have been at the file formats again...!

Open an exr with an alpha in CS2 and the image displays normally and the alpha is retained.

Open an exr with an alpha in CS3 and the alpha channel is applied to the transparency and then lost... which is really STUPID considering you might apply 0 alpha values to parts of the image you retain visually, as you might just want to use the alpha to drive an effect and not just be myopic and think it's just for transparency.

So, can this be fixed? I can't see any info on it?

Will CS2 non intel plugin work on an intel system in CS3

If not, effectively PS is useless for exr work for us.

Or is this fixed in CS4?

[_progress_]

Users only use what is programmed Chris... if you wish to bang the standards drum, bang it to other developers, but trying to shut the stable doors when 1/2 the world are riding the herd and asking them to come back isn't going to work... especially when it's within the same product.

As I keep saying. Alpha is a representation of opacity. It is not opacity per se. If that was the case it would be impossible to have something at 0% opacity with an RGB value... but it isn't.

It's really simple. Removing the alpha shouldn't take the RGB values with it.

Now, if you say these RGB values still exist, and that it's possible to get them back even though the A is no longer accessible, then let's have that functionality.

Just because a format is premultiplied doesn't mean you can chuck the alpha willy nilly. It still serves a purpose, even as opacity.

But you can't go around 'fixing' things that people have learnt to work with in a productive manner. Well not if you want the quiet life, or the nod of approval from those that lead the industry.

Call it serendipty, whatever, but it worked before, it's been shown to work with plugins, it's simple it's current state that's broken. I can hoop jump to fix it, but what's the reason that I have to do that except your interpretation of something...?

There seems little point in sticking with something that breaks the interest of so many.

If Adobe is interested in an expanding market, perhaps it should think about not shrinking the one it has. Given the nature of HDR images, it's not like it's something the novice user is going to care about.

It's another reminder of how out of touch Adobe have become with their user base.

[_jonah_]

LOL. Hey "progress", how about starting another thread with your last post? You could title it something like Dead Horse.

I think the discussion has progressed well beyond these points and is going in a very positive direction. Let's not impede the effort at this point eh?

[_progress_]

Oh I agree... not trying to...

But lets just say we've been down this road with other formats before ;)

[_progress_]

I also thing there is a misunderstanding of the pre vs straight. The data is written the same, but the data before it's written is different in each case. Therefore a format can carry pre or straight, but the image data written is different. You can't bounce between the two after they've been written but you can beforehand. I can choose to save pre or straight on the point of saving to TGA. The image looks the same before I do that, but the results are different, yet either straight or pre, the file is still RGBA.

[_Zap_Andersson_]

> No, many file formats are not premultiplied,
> and some file formats support an alpha channel
> that has nothing to do with transparency/opacity.

Apologies for being unclear, I expressed myself sloppily.

I meant to say, for all format that support a *premultiplied* alpha channel, the *meaning* of premultiplied should adhere to what was just defined for OpenEXR, i.e. that the color (1,1,0,0) is valid, and means "luminescent yellow".

> TGA is not premultiplied (some people think it
> supports opacity, and some don't).

Well, the TGA specification supports all variants, if you go back and read it. Quoting from it:

Byte 494 - This single byte field contains a value
which specifies the type of Alpha channel data contained
in the file.

Value Meaning
0: no Alpha data included (bits 3-0 of field 5.6
should also be set to zero)
1: undefined data in the Alpha field, can be ignored
2: undefined data in the Alpha field, but should be retained
3: useful Alpha channel data is present
4: pre-multiplied Alpha (see description below)
5 -127: RESERVED
128-255: Un-assigned

> PNG is not premultiplied, and only supports opacity.

Correct. One of the main failings of PNG, I might add, and probably why it isn't used nearly at all by CG professionals, other than maybe for painting textures.

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

Well, there is this thing known as "de-facto standards" as well. I would rather say that the interpretation of alpha in TGA files has matured and evolved.

For example, the original TGA spec (quoted above) simply directs you back to the original SIGGRAPH 1984 Duff & Porter paper on premultiplied alpha. Did Duff & Porter think about the luminescent yellow color? No, they didn't.

Does that give anyone the right to assume it is "illegal"? No.

/Z

[_Thomas_Helzle_]

You know what this whole discussion reminds me off?

I once sat in a train, across the corridor there was a family sitting at a table with the kid (maybe 4-5 years old) drawing with color pencils, the father reading a a paper and the mother reading a book.
Suddenly the father reached out and bashed the kid HARD in the face yelling: "There is no such thing as a green dog".

One of the most shocking experiences I ever had.

Once upon a time, software was developed for the user who paid money to get things done faster and more flexible.

If a software company representative tells me that what I want is wrong, not to spec, that I have no clue about compositing if I even think about using a channel for something else as what somebody defining a file format intended ( but most probably never intending as rigid an interpretation) and that many many people will suffer from extreme confusion if they are presented with a choice about how a channel should be interpreted somewhere in advanced preferences, I can only walk away with a very irritated feeling of extreme absurdity.

I highly respect everybody here, but pussyfooting around a guy who simply is using his position of assumed "power" to tell everybody off and that "there is no green dog" is absurd.

Chris: may you live a long, full and happy live as far from the specs as possible. :-)

Carpe Diem and best Regards,

Thomas Helzle

[_Mike_Ornellas_]

I think we should not adhere to any specifications. That way we all can all do what we want - kind of like how the product is packaged and sold... Makes perfect sense to no one and everyone is happy.

[_progress_]

I know what your saying Mike, but one has to remember that people had adopted HDR for quite some time before PS started playing with it.

[_Mike_Ornellas_]

Yes, but you have to understand that Chris can only do what he can in his environment. He has people to answer to and more then one company as well. To be honest, Adobe is out of control at this point and they have lost the essence for fear of retaliation by its customers. It's a case of damn if you do and damn if you don't. The real problem is the people higher up who have NO BUSINESS making decisions on how shall an industry be steered are the ones pissing off the majority of people that are being affected by said changes.

All this comes down to the lack of market research in the industries they cripple based upon their semi tempest decisions - do to the lack of actual real world experience because they are developers and not entrenched in any specific field they affect.

I call it irresponsible plight for the sake of corporate stock holder edification.

But we all do what we can as individuals - but the real problem is tunnel vision because Adobe REALLY does not understand the markets they cater to...

[_progress_]

agreed.

[Serene_artistry15C2]

Hi guys,

Ive read the whole thread and I have a new question to add to the mix...

Does ProEXR support Photoshop CS4 Extended (on XP64) ???

Ive been trying to get this thing working for ages, no joy, any shared experiences would be very welcome.

Tommy L.

[Toastman3000]

Interesting to read where Alias and Autodesk stand on alpha channels:

Maya image files also contain an alpha channel (or mask channel) which represents the presence and opaqueness of objects, and a luminance channel which represents the intensity or brightness of the image.

There is no reason why PS should automatically remove the corresponding RGB values for us according to the alpha channel. But then maybe Adobe is trying to change format standards again...

I hope this thread keeps on going until something gets changed.

[Chris Cox]

Toastman  - it helps a lot if you read the thread before posting.

Adobe is not removing anything, only doing exactly what the file says to do.

[Serene_artistry15C2]

Chris,

Maybe Adobe should listen to customers, not files.

[Chris Cox]

Adobe does listen to customers, many millions of them.

In this thread people have been confused about terminology, or asking for a solution to the wrong problem, or getting confused about which version of Photoshop they were running.  None of those could be solved directly by Adobe -- but I am testing a solution to the underlying problem of editing transparency/opacity data.

[Serene_artistry15C2]

Hooray!

[Serene_artistry15C2]

Let me give you an example.

I am an architect.

I am designing a multi-use building.

I am discussing the ground floor plan with a client.

Client (customer): I want room #2 to be the reception lobby.

Me (architect): Well I designed room #1 to be the reception lobby.

Client: I am the client, I say the Room #2 is a reception lobby.

Me (architect): It cant be.

Client: Why not?

Me: Because its not designed to be.

Client: I dont care, I think it would work better and increase the inherent

value of the design. It would also streamline human traffic.

Me: You are stupid, I am an architect and I say so.

Client: I pay the bills, I buy the building, I use the design for my own

creation.

Me You are stupid, I say so.

Client: Can you give me a reason why not, or even a viable alternative?

Me You are stupid, I say so.

Now just change the Characters:

Chris (Adobe)

Client.

[Chris Cox]

Huh?   That is so totally unrelated it's not even funny.

Please read the existing thread.

Standards exist for a reason.  In this case to enable interchange.  If you start ignoring the standard, you stop being able to use the format for interchange (nobody will ever know what the bits in the file mean unless you tell them for EACH file).

I have given very clear reasons, and very clear explanations.

[Serene_artistry15C2]

Yes, and most everybody understands your explanation. It is not a SOLUTION

however and that is where we do not meet in the middle. The solution is so

tightly related to the explanation, yet you seem completely unwilling to

bend on the implementation of the file-type. This is because you are

adhering to a protocol that is not allowing the solution to be met.

Its not important WHO is 'RIGHT, its important WHAT is BEST.

[Chris Cox]

Ok, that makes little sense.

I am trying to do what is best.  I'm trying to address the underlying problems, not the specific (and sometimes mistaken) features requested.   I have a solution to the underlying problem described here (editing transparency/opacity) on the way.  Solutions to some of the related problems (what to do with zero opacity) are still in progress.

But I have to think about what is best for all users. I can't just change things based on a few users misunderestandings, or their willingness to ignore standards.  Changing the file format implementation for a few users might help those few users, and might hurt/slow down/lose money/confuse many other users.

If you present a reasonable argument for change, I will listen.   But your current postings are not likely to make anyone listen.

[Serene_artistry15C2]

By the way, the usage of these in the context of 3d rendering packages is

HUGE, especially Vray, the market leader of the rendering engines. Creating

HDRI, using multiple render passes, prepping image sequences for

AE/Combustion etc, building entire workflows/pipelines to streamline

production can exploit this facility. It is not just some inane function

that a couple of renegades are looking for.

[Serene_artistry15C2]

Now thats the kind of response I appreciate!

I am proposing that the considerable amount of people who currently use the

functionality of the ProEXR plugin be given the same functionality as an

option when opening an .EXR file in vanilla Photoshop. Now I know that goes

against the grain when considered within the context of the file

inventors(?) at ILM(?). However, if the guys at ProEXR can do it, why not

Adobe? I dont think its breaking any laws......

Functions:

1: Multiple arbitrary channels.

2: Transparency embedded in rgb as default, but with the option to retain

un-molested rgb and include transparency as an Alpha.

The argument for doing it is simple. People already use this functionality,

hence the valid business with ProEXR. Also, thats why someone from Pixar(!)

posted in relation to this issue.

[Toastman3000]

I have read the thread, it just seems Adobe is the only other company pushing for the way opacity channels work in Photoshop CS4.

Using any other photo editing program or compositing software wether it be by Autodesk or Apple or even open source The Gimp.....and the file format always retains the alpha channel. It just seems strange that PS CS4 is the only software to automatically delete RGB channels to the corresponding A channel (which also becomes lost) before even editing the file. Very, very strange.

[Serene_artistry15C2]

Well Chris has explained the thinking behind that, to be fair. However, I

whole-heatedly agree with you. I think the basis for the Adobe logic (the

format authors) has less foundation than the laws of common sense.

[Chris Cox]

Toastman - it sounds like you didn't read all of the thread.

Photoshop is preserving the transparency/opacity channel, always.  Nothing is deleted.  When you open an image with transparency/opacity -- the transparency/opacity is right there in the document.  And the color data is right there in the document.

The only things photoshop is not doing is allowing you to edit the transparency/opacity directly, and not working with premultiplied color (which is far too limiting for Photoshop).

Other applications confused transparency/opacity (which you can only have one of) with alpha channels (which can be many, and may not related to the color data).  They expose the transparency/opacity channels for editing in a different way than Photoshop does (or just ignore the fact that they are transparency/opacity entirely).

And if another application uses premultiplied color data, then it may do a better job of preserving premultiplied color artifacts than Photoshop does (because Photoshop has to un-multiply the data in order to make it compatible with all the things Photoshop can do).