Welcome Dialog

Welcome to the Community!

We have a brand new look! Take a tour with us and explore the latest updates on Adobe Support Community.


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

Community Beginner ,
Nov 18, 2008 Nov 18, 2008

Copy link to clipboard

Copied

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?

Views

194.5K

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
replies 253 Replies 253
Community Beginner ,
May 20, 2009 May 20, 2009

Copy link to clipboard

Copied

Chris,

Is there an ETA on the solution for editing the transparency/opacity?

Happy to help with testing.

(progress)

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
May 20, 2009 May 20, 2009

Copy link to clipboard

Copied

It's going through normal feature development and testing.  Which means I can't tell you the ETA without an NDA.

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Beginner ,
May 22, 2009 May 22, 2009

Copy link to clipboard

Copied

Happy to sign an NDA on behalf of the company.

If you want the details, let me know and I'll PM/email them.

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Engaged ,
Jun 09, 2009 Jun 09, 2009

Copy link to clipboard

Copied

(Didn't realize this thread was still going on...)

BTW, everyone, I've got a new beta of ProEXR. Actually, I've re-written the entire thing, in part to take Chris' advice for speeding things up by sending bigger chunks of pixels to Photoshop (and therefore using more memory). I've also got a 64-bit version for Windows and a companion plug-in ("ProEXR EZ") for people overwhelmed by the all-out layered approach and just want control over alphas.

Since it's all new, I'm going to keep it in beta for a bit. Try it here:

http://www.fnordware.com/ProEXR/beta/

Let me know if you find any problems!

Brendan

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Beginner ,
Aug 27, 2009 Aug 27, 2009

Copy link to clipboard

Copied

I was going to post this to this thread back in March but the thread devolved in such a way as I thought it might not get read seriously.

I note that this discussion has been revived and has returned to a more serious note. Chris, I notice you have asked once again in your May 18 2009 2:50 pm posting that if a reasonable argument for change can be posted that you will listen to it.

Here is my reasonable argument.

MY BACKGROUND

For the record I've been doing CGI for over 20 years. Before that I was in broadcast television and before that in offset print. I'm as comfortable in front of XSI or Maya as I would be in front of an Avid, a 1 inch tape machine, a vertical line camera, a Compugraphics typesetter, or an AB Dick offset printer. Some of the applications I have used over my career include Cubicomp, TrueImage Paint Software(TIPS), Aurora(240), Softimage(3D and XSI), Wavefront, Alias, 3DS Max, Maya, Quantel Express, Matador, Eddie, Shake, Composer, 3D Paint(IFX), Painter, Photoshop, After Effects, and Photoshop. I have also operated Laird, Chyron, and Dubner character generator systems, mostly prior to 1988 which is when I began doing 3D.

MY PERSPECTIVE ON THIS THREAD

I have read this entire thread. I've struggled with the CGI paradigm/Photoshop paradigm conflict for many years. The Photoshop "way" is relatively new to this industry and was not defined by this industry, even though Photoshop is quite old.

The Photoshop “way” was ultimately defined by the offset lithography, and photography industries. In recent year Adobe has made a valiant effort to accommodate the CGI industry with things such as pixel aspect support, expanded CGI file formats support, and other such things. But most of these things have been band aids placed on a larger system core philosophy which was not designed for modern CGI.

As a result there is currently a Photoshop Paradigm for handling images and a CGI industry Paradigm for handling images. The Photoshop Paradigm is currently incompatible with CGI on many levels though not entirely. If you've used other legacy applications such as Matador, Aurora, Eddie and Shake, or even current apps such as Fusion or Nuke, you likely already understand this. If not then the CGI industry paradigm, especially as it relates to alpha channel use, will likely be foreign to you.

After reading this thread, I realize I cannot overlook this workflow conflict anymore because there are serious issues not being addressed by Adobe and other issues which I believe that Adobe just does not have a full grasp of because they are probably “too close to the trees to see the forest” in a manner of speaking.

I have long suspected, due to Photoshop’s historical context, and it’s more recent development path, that Adobe, or at minimum certain development teams at Adobe, honestly do not understand the nature or context of the CGI industry, the tools we use, the workflow, and the reasons for why things are the way they are in this industry. The lone exception to that rule is After Effects which gets most things right, though in it’s own unique AE way.

I believe this to be an honest case of being at the right place at the wrong time so to speak. In the early days of this industry there were so many players all struggling to place their mark on what were perceived as niche areas they could excel in, the industry incubated numerous “islands unto themselves”. The reasons for that are many, but largely to do with the fact there were numerous development platforms and hardware platforms which were foreign to each other. Video broadcast equipment, SGIs, PCs, Macs, etc all spoke their own language and did not work well together. Development teams took their own “path of least resistance” based on the platform they found themselves on and this was complicated even further by the niche market they were programming for.

For the record the industry I am referring to today, CGI, would include anyone producing 3D video animation, 3D film animation, or any other 3D or 2D imagery reliant upon alpha channels for compositing or texture creation/application. While bigger than it ever was in the 80s, it is far more narrow today than it has ever been. A result of the merging of many of those incubators I referred to earlier.

Offset lithography, digital printing, and photography, while more modern today than ever, still is an industry all unto itself which largely does not understand modern CGI and the other way around. This is mostly to do with the fact that the output medium there is still paper, while in our world it is for a digital or analog display or film. This is further exacerbated by the inherit color philosophies and application, RGB add to black vs CMYK subtract from white, which still dominate both industries respectively.

MY POSITION ON PHOTOSHOP AS A CGI ARTIST

In all honesty, I often loathe the use of Photoshop for CGI work because in so many ways its not the right tool for 3D production. Its here now because many of the developers(Parallax, Aurora, etc, etc) which understood this industry and tried to make practical CGI image editing tools "died" a miserable and horrible death during the downfall of SGI dominance and subsequent rise of PCs.  Further, Photoshop is dirt cheap in comparison to the price points of the legacy apps, edits images over 10,000 pixels wide, and layers images with relative ease. It also supports print industry standards(PMS etc), something few of our legacy applications ever supported. It is an excellent application that does what it was designed to do extraordinarily well.

But it wasn’t designed for the things I want to do with it. I, like many others in this industry, have taken up the risk to use this app for something it wasn’t designed to do because it is useful, though its usefulness is dictated by how much headache and risk I wish to endure. It is a risk I take because there are very few options afforded me today. If I were producing something headed to offset lithography or print, which I still do on occasion, my opinion on Photoshop changes dramatically in its favor.

BACK TO THE THREAD

Chris, a few posts back you asked for a "*REALLY* good list of reasons" why Photoshop needs to be changed. I’m going to attempt to oblige you with such. Fair warning, this will be a long and complex discussion and I will start by saying that much of what I write, you, and many other readers, already understand, but I'm going to put the extra effort into this and provide definitions and details to provide background to the argument and bring everyone up to speed who may have been reading this thread but may not understand why those of us in CGI have a problem with the primary Photoshop Paradigm and how this workflow severely impacts CGI. Plus, I think there is a good chance people from both sides of this argument may learn something.

I’m not going to focus this strictly on EXR, because EXR is only one part of a much larger problem, instead I'm going to address the bigger problem which EXR is part of, and has been addressed in this thread, but only partially.

MY ARGUMENT

THE PROBLEM

That problem is a lack of consistency regarding file format and file content interpretation, interface context, file reading and saving behavior, and a general sense of workflow that works fine for print and photo but is very bad for CGI and alpha manipulation. Further the problem envelopes a general misinterpretation of what the real purpose of an ALPHA is, and who should have control over it and why.

Please keep in mind that my criticism of Photoshop is not a suggestion that Photoshop can’t do what is needed. Photoshop is a very capable and sophisticated software which is right on the edge of being able to support CGI’s needs in a big way. Unfortunately though, it was not developed to specifically support our needs and the current attempts to quick fix engineer it falls short. It all honesty it just isn’t there yet.

GENERAL DEFINITIONS

I’m going to define some basic concepts which will be necessary for everyone to follow along and to provide context for later discussion. If I am incorrect regarding any of these core concepts, relating at a minimum to Photoshop CS3, feel free to correct me.

PS LAYERS

Photoshop supports the concept of Layers, each layer being the source for a single image plane. Any Layer can be randomly positioned on the canvas if the positioning is unlocked.

Layers obey stack ordering where the top most image lies above the image below it, revealing the images below through various means of masking and compositing methods. The result, for lack of a better description, enables an ordered compositing "column".

PS CHANNELS

Every Layer possesses a base image plane comprised of multiple Channels, typically the RGB Channels(assuming the Image Mode is RGB Color of course).

The Layer may also include other Channels, beyond the base image plane such as an Alpha channel, Mask channels, or other Channels depending on the import process, image format used, or construction method.

PS TRANSPARENCY

Every Layer’s image plane possesses, by default, a permanent Transparency plane. This Transparency plane is connected, or merged, directly to the base RGB image plane but not to any extra Channels such as Alpha or Layer Mask. This “merged” pair should not be confused with a link. The two are inseparable. A link however can be broken.

You will be aware this Transparency plane exists the moment you move the image or erase part of it. The checkerboard beneath is evidence of this fact and reveals that by default any base image in a Photoshop Layer is actually a Cutout(a result of the merged image plane and transparency plane).

Transparency does not appear to be independently viewable but can be extracted and copied to another Channel to be viewed or edited.

PS LAYER MASKS

A Layer also supports Layer Masks, which is similar to Transparency, but Layers Masks are optional and not always present, while Transparency is always present even when you flatten the image.

Layer Masks can be added by the user by adding them manually or extracting a Load Selection and using that as a source. A Layer Mask is typically linked to the Image Cutout(not to be confused with being merged with the image plane like transparency) and moves with the image plane when linked.

If the Image Cutout and Layer Mask are unlinked the positions will be independent one another, allowing either to be moved at will. This provides evidence that Layer Masks are independent of the Image Cutout even though both Cutout and Layer Mask are present in the same Layer. Linking constrains their positions as well as prevent the Layer Mask from being arbitrarily moved out the Layer, but has no bearing on the Layer Mask’s real independence.

A Layer Mask, while it appears in the layer list, also appears as a channel. Here the Layer Mask visibility can be manipulated at will. Selecting the Layer Mask in the Layer also selects the Layer Mask Channel.

Layer Masks by default will affect or operate upon the Transparency, or other Layer Masks, resulting in a masking composite which defines the overall masking behavior for the entire Layer.

CUTOUTS

Why did I use the term Cutout earlier? Cutout is not a term embraced within the Photoshop paradigm to my knowledge, but it is an accurate description of a major part of the Photoshop Layer paradigm so I will elaborate on this in more detail. Further it is a generally accepted term in this industry for a very, very long time and most CGI people will know what this is by default.

Cutouts are things which were supported on legacy apps such as Quantel, Matador, Aurora, and numerous other high-end applications which had retail value in excess of $7000 back in the day. In the case of Quantel were talking in excess of $100K, and Quantel is among the oldest of applications to support this concept.

A Cutout generally is a "masked" image which can float over other images and be stamped in place when needed. This behavior should be very familiar to most Photoshop users.

Cutouts were always secondary in other apps, meaning that you were forced to create the cutout at your command, they were not created automatically for you as is done in Photoshop.

In Photoshop, Cutouts(the merged image and transparency planes) are primary, any image opened in Photoshop is immediately converted to a Cutout and inserted into a Layer as such. Each layer is by default a Cutout holder capable of also holding other things, but for which the Cutout is the dominant base component of the Layer.

Only Quantel comes anywhere close to this PS paradigm. In Quantel, cutouts played the dominant role in the creation process, but even with Quantel, Cutout creation had to be manually forced by the user.

PS CANVAS

In all other applications the core image is usually always the canvas, not so in PS. In PS the Canvas is a window or viewport separate the image. For lack of a better description it is a cropping viewport which limits the virtual layer workspace underneath it. This is not necessarily a bad thing, and for most image and photo editing, the Canvas and Layer methodology in PS is the trademark characteristics which set PS apart from so many other image editing apps. But while being its most significant feature, Photoshop’s layers are also it's most daunting Achilles heel.  But more about that later.

PS ALPHAS

Alphas are Channels created manually, or ingested upon the opening of an Image.

Alphas are generally permanently independent of the Cutout and/or the Layer Masks and usually impose no masking behavior upon the Layer.

It would seem that in Photoshop the “Alpha Channel” is not a real Alpha Channel, but just an arbitrary channel holder no different than any manually created scalar channel. In other words there seems to be no significant designation to the Channel which holds the Alpha image and marks it as the Image’s proper Alpha. It appears to be just another arbitrary Channel with “something” in it.

Theoretically Photoshop can hold numerous Alpha Channels, but theoretically Photoshop does not even know what an Alpha is. To Photoshop it is just an extraneous or arbitrary Channel named “Alpha”.

Ultimately these facts, and the perceived behavior which PS engages in regarding Alphas, appear to suggest that Adobe’s philosophy on Alphas is very different than that of CGI. This incongruence is the major factor in why the PS paradigm is in conflict with CGI and its use and application of alphas in most CGI image formats.

For the record, to be a qualified Alpha Channel the channel must be recognized by the software in question as the sanctioned, defined, and stored alpha, opened as alpha, and stored to the correct respective alpha channel designation when saved to the respective format that understands or at a minimum expects an alpha to be written. If it does not do this, it is just an arbitrary channel. Matador, Aurora, even TIPS all obeyed this rule.

ALPHAS IN GENERAL

To begin, the Alpha Channel is sacred. (to be clear that’s sacred with the little s not the big one)

In the vast majority of cases the Alpha is rendered simultaneously with the Image that owns it and it’s definition is directly, intrinsically, and exclusively related to the RGB channels for which the Alpha is associated with. 

The Alpha Channel is sacred. User should edit the Alpha at their own risk.

In CGI, the sole purpose if the Alpha Channel is to provide compositing applications, video editors, paint software, or 3D software with a scalar representation of the RGB Channels so that the user can composite those RGB channels correctly as image sequences, keys, decals or other products.

The Alpha channel is sacred. It is there for the user to employ it only when the user wants to, and no other time.

The Alpha is not merged with the RGB Channels, linked, connected, carried over, or inherited in any way unless the user chooses to pass it along within the composite or other action. It is a direct reference to the actual render and the render’s specific characteristics. It is both inclusive and exclusive at the same time.

The Alpha Channel is sacred. It has no relevant meaning to anything else but the rendered image which owns it or the artist who creates.

I’m not going to get into the whole conversation regarding pre-multiplication and proper design of an Alpha, at least not yet anyway. Frankly this is a moot point to the bigger problem for several reasons, but the primary reason is the fact that most applications already render the alpha correct directly out of the application of origin, so this is a moot point for this particular discussion.

The Alpha Channel is sacred. Most third party image editors, compositors, etc never alter the Alpha Channel in any way unless they provide the user a means to alter the Alpha at the user’s command. Most modern compositors provide this option.

Most people do not realize the Alpha is not exclusive to digital graphics. It existed, in theory, concept, and practice as the key or matte channel even in analog broadcasting equipment, character generators, and video editing equipment, long before it was implemented as a digital image concept. History provides strong and irrefutable evidence of the alpha as a compositing reference before digital compositing even existed.

The Alpha is sacred. Any tampering or misunderstanding of the Alpha’s intent, relevance, importance, or purpose seriously screws the entire CGI compositing concept that relies upon Alphas as reference.

Premult and issues like this are math issues which can be resolved in time, and are irrelevant to the core problem faced with Photoshop and Alphas at this very moment. The more complex and pressing issue though is the accurate interpretation and understanding of what an Alpha is, why it is, who uses it, and how it is used. This interpretation has evolved differently for Photoshop than it has for every other application in CGI. In this regard Photoshop stands alone. Adobe should consider reevaluating its interpretation of the Alpha and it’s subsequent use and repurposing, often to the detriment of the purpose which the user wishes to employ the alpha.

The Alpha is sacred. But I said that already didn’t I…….

Contrary to what appears to be expressed Adobe philosophy, the Alpha is not an arbitrary element. The fact that the alpha is rendered to specifically correspond with the RGB color channels refutes this idea. We do realize however that Adobe views the Alpha as important to making Transparencies so we are not saying that Adobe is ignorant about the Alpha’s importance. What we’re saying is that we don’t believe that Adobe should arbitrarily assume that the Alpha is there exclusively to support the Photoshop Transparency Paradigm unless the user explicitly wants that behavior.

ALPHAS IN OTHER CGI APPLICATIONS

(For the record I’m again referring to Matador, Aurora, Eddie, Shake, Nuke, Fusion, etc, etc)

These applications do, or did, treat the Alpha as if it were sacred.

No change was made to the alpha unless it was an option provided to the user and/or the user was aware that the alpha was being altered.

Different tools, nodes, or options were/are provided to treat or interpret the alpha as the user chooses. Atop, Over, Add, etc, etc are choices, not requirements.

 

All alphas, from all formats that the app is capable of reading, are treated the same. The Alpha is never stripped, moved to a different layer, or modified to fit a particular application workflow. The Alpha IS the workflow the vast majority of the time that the Alpha is present.

The Alpha is treated as a reference, not an element to facilitate an application workflow as opposed to a compositing workflow.

No situation is/was ever allowed where the flattening, combining or copying of the Alpha results in the altering of the alpha, or image color, without the user being aware, or the user being permitted to choose that result.

ALPHAS IN OTHER IMAGE FORMATS

In most common Image Formats that support an Alpha, the channel has special meaning. That is to say that whatever goes in the A, or Alpha, Channel becomes the image’s Alpha and nothing else. It can’t be confused as a layer mask, or transparency, or opacity, or some arbitrary extraneous channel. It is THE Alpha. It is sacred.

Most formats only permit one Alpha because of this special meaning for the Alpha. This is by DESIGN. It is not so by mistake or by careless programming habits. If the format permits more than RGBA, it is typically clear what the Channel is for and it is the bizarre exception as opposed to the rule. And yes there are formats which permit a lot of extraneous stuff that rarely gets used, but the Alpha is not one of those.

The ALPHA is not an arbitrary channel.

Since the Alpha is a direct reference to the RGB channels, the common CGI image formats only needs one Alpha, usually only has one, and theoretically only requires one Alpha. Anything beyond that is not a true Alpha, is arbitrary, is superfluous, or is extraneous data such as a normal, Z or other map.

Photoshop does not possess this same clarity. 

WHAT PHOTOSHOP APPEARS TO DO WHEN IT READS AN IMAGE WITH AN ALPHA

It all depends.

For this discussion I will stick to a handful of industry standards for brevity, but these should not be viewed as the only examples. For this test an image of a sphere is rendered over an empty background to multiple formats from different applications. The image is RGBA.

Softimage PIC: Softimage standalone Showpic.exe and imf_disp.exe reads and displays this image correctly.

PIC is converted by Photoshop to a Cutout where the RGB becomes the Cutout Color(or base image plane), the Alpha becomes the Cutout Transparency. The Cutout is placed in an unlocked Layer. The Alpha as a reference is discarded.

Maya IFF: Maya fcheck.exe reads and displays this image correctly.

IFF is converted by Photoshop to a Cutout where the RGB becomes the Cutout Color and the Alpha becomes the Cutout Transparency. The Cutout is placed in an unlocked Layer. The Alpha as a reference is discarded.

TIFF:

TIF is placed in a locked Layer. The Alpha is retained as an unlinked, unconnected, unmerged arbitrary reference in an extraneous Channel. A Cutout is created, but with a default full field 100% opaque Transparency. The Alpha is NOT used for transparency.

OpenEXR: imf_disp.exe reads and displays this image correctly.

EXR is converted to a Cutout where the RGB becomes the Cutout Color and the Alpha becomes the Cutout Transparency. The Cutout is placed in an unlocked Layer. The Alpha as a reference is discarded.

SGI: fcheck.exe and imf_disp.exe reads and displays this image correctly.

SGI is converted to a Cutout where the RGB becomes the Cutout Color and the Alpha becomes the Cutout Transparency. The Cutout is placed in an unlocked Layer. The Alpha as a reference is discarded.

GENERAL ALPHA HANDLING BY PHTOSHOP

In the vast majority of cases PS handles the Alpha unlike any other application I’m currently aware of. The majority of these cases PS turns the image into a Cutout by default which can be an improper way to handle the image depending upon circumstances and needs. If your goal is to do a lot of image layering, its quick and effective, but if your goal is to paint on the image or edit the alpha, you’re in for a hell of a ride or you are very possibly screwed.

The only exception of these examples is the TIF file which looks similar to a common proper Alpha inheritance and reference within other apps. But still it is not because it becomes an arbitrary reference as opposed to being retained as an associative reference. Why do I suggest this? Because Photoshop is ultimately a compositor, not a painter, even if you don’t want to view it this way.

The Layer column in PS is there to provide immediate compositing functionality. The way that TIF is opened removes, or disassociates, the Alpha from the RGB for the Layer even though the Alpha is retained. No relative compositing functionality is retained given the Alpha reference that exists, which is what makes this import of the Alpha arbitrary.

In Photoshop the only activity which would be even remotely close to most other CGI apps is to bring the Alpha in as a Layer Mask. Since a Layer Mask can be associated to the image plane via a link, can be edited independently while still being relative, and since the Layer Mask also shows up as a Channel, this would be the appropriate analogous behavior for Photoshop to behave as compared to every other CGI paint application. Further the Image color is largely unaffected directly by the Layer Mask. Unfortunately however this does not change the fact that the RGB color plane still possesses Transparency, though the Transparency would need to be full field 100% opaque. In other words for this to work, you cannot have both custom transparency of the alpha source and the custom mask of the alpha source and retain the 1:1 relationship with its original state outside of Photoshop. 

Unfortunately however, Photoshop puts serious roadblocks in front of the user which prevents this from being practical. First it doesn’t load the Alpha to Layer Mask, and second, what Photoshop does upon saving the image seriously screws up any reasonable workaround to this impediment in some cases. The presence of the wrong kind of Transparency in conjunction with a custom Mask can detrimentally affect the Mask or Transparency and summarily the entire image itself because it must flatten the image upon saving the image to a custom CGI format.

The whole point here is that the CGI world, specifically the users, views alphas as Associative, Exclusive, Inclusive, and Independent of the RGB channels all at the same time. A difficult concept to grasp I realize, but it all depends on the users intent and use of that alpha at the moment. Which is what makes this such a difficult topic of conversation, because we have so many different users with their own particular view on this matter as it relates to the workflow they are accustomed to.

WHAT PHOTOSHOP APPEARS TO DO WHEN IT SAVES AN IMAGE

It all depends.

Normally Photoshop saves out to the format the way it reads it in. Or rather it writes out Alpha depending upon the same way the open finds it and processes it. But this is wrought with problems and inconsistencies depending on the format needed to open and the format needed to save in a particular session.

For this reason, opening a file of one format, editing it in PS, and saving as another format can be, or is, disturbingly problematic for a lot of people.

For these tests I rendered a simple image, a sphere over black out of multiple applications such as Maya and XSI using their native formats.

Maya IFF: Assuming you open the Maya IFF file with alpha into Photoshop, if you immediately save it out as Maya IFF with no changes, Photoshop attempts to write the Cutout Transparency plane out as the Alpha.  It partially succeeds with the Transparency indeed being written to Alpha but the image itself becomes corrupted with garbage showing up in the RGB channels when viewing this in fcheck.exe. This is not evident however if reopening the image in PS.

The result appears as if the Transparency gets extracted and removed from the Cutout, and the RGB layer get flattened over white, resulting in the Cutout being rendered over white and then written out with the separate Alpha to the IFF file. But there is still black in the image where there is no alpha so in general the result appears as a corrupted file when viewing from fcheck.exe. This is all assumption based upon the appearance of the image.

Softimage PIC: Assuming you open the Softimage Pic file and commit no changes, it does the same exact thing as with Maya. It saves the Transparency to the Alpha and corrupts the RGB plane. The error is viewable in showpic and imf_disp but not when reopening in PS.

SGI: Same as Maya and SGI. Image corrupted when viewing in either fcheck.exe or imf_disp.exe.

OpenEXR: File is saved normally with NO garbage displayed when viewing from imf_disp.exe.

TIFF: Assuming the Tiff file is saved with no changes, it writes out whatever is in the Alpha Channel out to Alpha. The image is generally viewable in most utilities with no anomalies.

Photoshop re-opens all the saved custom CGI files without any garbage. But the native file display applications, for each application suite, displays garbage. This poses the serious question what is wrong with these files, are they usable, and even if they happen to be usable are they trustworthy. In other words, will using one of these IFF or PIC files as a texture map blow up my render up on Frame 34 of a 3000 frame render at 3:17am on Saturday morning?

In each case but the TIFF the Photoshop file saved out files which were larger in size than the original even though no change was made to the file. The Tiff actually decreased in size. Can’t say I’m surprised by that, but why? What is being introduced to expand or decrease the file size? Is the file a nonstandard save of my trusted format?

Attempts, other than TIF, to save a file with an extraneous alpha channel fails even though Alpha Channels are selected on output. How do I know that? Using the SGI file format for example:

Open the SGI file.

I introduce a New Layer and fill it with Black.

Reorder the Layer column so that the black field is at the bottom of the Layer Column.

I flatten the image thus compressing and reinitializing the Transparency.

(Transparency isn’t removed, just reset).

I create a New Channel using the default Alpha 1 name the dialog provides.

I fill the Alpha 1 Channel with Black.

I paint a couple of lines to the Alpha 1 Channel thus creating a custom Alpha Channel.

I save the file using Save As and insure that Save Alpha Channels is on.

Now this is where it gets screwy. If I view the modified/saved file using imf_disp.exe, the Alpha is a solid opaque white field. Imf_disp.exe further indicates the image is of RGB type instead RGBA type, which is what the original .sgi file reported. But if I re-open the modified/saved file in Photoshop the alpha returns as a “alpha” in the Channels list though this time named Alpha 2 instead of Alpha 1. So Photoshop “thinks” it has an alpha but for the apps that really care or matter, the Alpha is….. gone.

If I repeat this example on other formats such as Softimage PIC or Maya IFF, the results show that these formats, when saved, lose the Channel named Alpha 1 completely. The Save As dialog presents no Save Alpha Channels option. It further results in absolutely no alpha, or “no mask” as fcheck.exe reports it.

Now I could take my Maya IFF file which has this custom painted “Alpha 1” Channel and do the following:

Open Maya iff.

Duplicate the Background Layer

(PS locks everything it thinks is a background instead of letting the user do this themselves or letting them unlock it at will)

Delete the locked background

Load the Alpha 1 into Selection

Create a new Layer mask using Hide Selection

(for some bizarre reason load selection creates an inverse selection)

Then Apply Layer Mask to convert the Layer Mask to a Cutout.

Save.

Now I get my custom Alpha the way I want, but oh, did I mention, there is garbage in the image. I did mention that didn’t I.

Ironically, I can repeat this entire process with OpenEXR and get different results, for example:

Open Photoshop

Open EXR file

New Layer

Fill Layer with Black

Move Layer to bottom of Layer Column

Flatten Image

Switch to Channels tab

New Channel Alpha 1

Unhide Channel Alpha 1

Fill Channel 1 with Black

Paint on Alpha 1 Channel

Load Selection: Channel, Alpha 1

Switch back to Layers tab

Duplicate locked Background layer

Delete locked Background Layer

Create New Hide Selection Layer mask on Background Copy

Apply Layer Mask to generate a Cutout

Save As OpenEXR file

Enjoy image with custom alpha and no garbage in file!

Pant…pant…pant….pass out…. call ambulance…..

But in the rest of the “grits eatin” legacy CGI world it was pretty close to this instead:

Open Application

Open whatever file you like

Switch to Alpha plane

Edit Alpha plane

Save whatever image you need

Enjoy image with custom alpha and no garbage in file!

Is this starting to make sense?

Are you beginning to get a sense as to why our frustration level with this application is so high?

I’ll continue now because it only gets better…or worse….depending on your point of view.

READING ONE IMAGE FORMAT INTO PHOTOSHOP AND SAVING AS ANOTHER

So let’s say I’ve got a Softimage Pic file I want to edit, or I want to create a file in PS and save it as a PIC file. To get the Alpha I need, I have to alter the PS document so that it is a Cutout and save as EXR and convert to PIC outside of PS. But remember that PIC and IFF don’t save the image correctly, they leave garbage in the channels. Or I can move the Alpha to a Channel and Save as TIF, or I can save as a format that doesn’t corrupt the file.

This is ultimately a problem though because all this robbing of Peter’s Layer Mask to pay Paul’s Alpha introduces a workflow which requires moving the original alpha around to different things like mask etc just to edit as needed. Can we do this, yes, but it is extremely prone to damaging the true Alpha, or image, unless you know exactly what you are doing and exactly what Photoshop is doing underneath.

What am I talking about? I’m talking about additive comps where the Layer Mask adds to the masking of the Transparency. I’ll explain in more detail.

WHY “SWAPPING” TRANSPARENCY/LAYER MASK /ALPHA IN PHOTOSHOP CAN BE A BAD THING.

I’ve gone to a lot of detail here to illustrate one of the serious pitfalls to the current Photoshop workflow which is an extreme level of copying, swapping, moving, duplicating etc which makes using the workaround workflow a dangerous and time consuming proposition. But it doesn’t stop there.

Open any of the original test images(the sphere over black with alpha channel) except the TIF file. The EXR file will do fine here so do the following:

Open the EXR file.

Load Selection Layer 0 Transparency

Create New Layer Mask using Reveal Selection

At this point we would edit the Layer mask but were not going to do that now.

Apply Mask to compress the Cutout and “return” the layer mask back to the Cutout.

But in reality thats not what it did is it? The unsuspecting artist, td, renderer, engineer ,whatever, not familiar with Photoshop’s seemingly benign method of extracting transparency to mask then re-applying back to transparency may not have realized that they were actually adding the original alpha(found in the transparency plane) with the copy found in the new layer mask. Once the Layer Mask is applied it disappears and its changes are added to the Transparency. But its not a swap! Repeat this several times and you will begin to see the perimeter of the transparency change, it will get smaller, each Apply Mask operation, even the first one, has been reducing the size of the original alpha by a small amount of pixels.

Is this unexpected? If you’re a Photoshop guru(not a DCC or CGI artist) not prone to working with alphas this behavior is very expected. Place a gradient Layer Mask behind a foreground object with Transparency and the foreground object inherits the gradient inside of the transparency because the two are being added together. There is a remote chance they are actually being multiplied I suppose but the result regardless the actual math is that the image is altered in a way which you didn’t want. Take the same Transparency field and copy it to the same image’s Layer mask and Apply and you’ve just permanently altered your original alpha channel, so even if you think you can send it back to OpenEXR with alpha, your sending back a modified alpha even if you make absolutely no changes at all to the Layer Mask, which, unlike the Transparency, can actually be viewed and directly edited without editing the color plane at the same time.

Unless of course someone can tell me of a way to directly paint or edit only the Transparency of a Photoshop Cutout without painting or editing the Cutout’s color. No other application that supports cutouts, to my knowledge, ever supported this either. That’s why Cutout’s were secondary as opposed to primary in those apps. They wanted to give the artist every opportunity to get the Cutout just right, that is color and mask, before committing to the permanent cutout creation.  To edit a cutout in those apps you split the image from the mask, edited, and recreated the cutout.

That’s right….if you had not realized it already this is part of the Achilles heal thing I was mentioning earlier, in Photoshop when you are editing the image you are actually editing the Cutout. A feature which provides incredible potential, as well as incredible risk, as I’ve demonstrated.

WHY “SWAPPING” IS A DIFFCULT THING

So we’ve illustrated some the pitfalls with pseudo-swapping of transparency, masks, and alphas. Is there a workaround, sure! Can we actually swap these fields? Yes, but it is an extremely painful thing.

Swapping in any situation currently poses problems because the image you would swap the transparency out of needs to be flattened, typically with black, but could need to be flattened with a different color, optimally the color within the actual Cutout Image plane. What should really be happening is that during a swap the transparency gets removed and transferred and the Cutout becomes a background using all of its original color. But I know of absolutely no way to do that within PS.

So for now “swapping” can only happen if you follow an example similar to the one above like this:

Open the image

Create a new layer

Fill the Layer with Black

Reorder the black Background to the bottom

Reselect the foreground object Layer

Load Selection Transparency

Create New Layer Mask Reveal from Selection

Flatten the image……

ooops……… we just lost the Layer mask, start over……..

Open the image

Create a new layer

Fill the Layer with Black

Reorder the black Background to the bottom

Reselect the foreground object Layer

Duplicate the foreground Layer to a NEW file for temporary holding

Return original EXR image

Flatten the image

Cant unlock new Background Layer

Duplicate the Background Layer to the same file

Delete original but locked Background Layer

Return to the New file with cutout Layer

Duplicate the layer with layer mask in the New file back to the original file

Return to original file

Select foreground Layer

Load Selection Transparency

Create New Layer Mask Reveal from Selection

Unlink the foreground Color and Mask

Copy the Cutout Layer Mask to the flattened Background Copy Layer

Delete the duplicate Layer Cutout

Re-link the color and mask(mainly to prevent the two from getting out position sync)

Edit the Layer mask

Apply the Layer mask

Save the file to OpenEXR

Pant….pant….thud…[intercom]”Dr House to Emergency room STAT! Patient in critical condition…”

Seriously…..All of this just to move the Transparency to a Layer Mask without corrupting it? If there is an easier way I would really love to know about it.

Why can’t we just open the file, edit our alpha, and save?

Why does that simple procedure have to be such a foreign concept to Photoshop?

Further, did the flattening alter the color in any way that corrupted any premultiplication which was explicitly relative between the image and the original alpha? Yes it did but we’ll force premult again later in the compositor. Copy the original cutout back in, zoom in real close and exam the difference between the two. The alpha is intact, we know this because it was never edited, but the color, that’s been changed. We get a slight black ring that was not there before, the original premult was lost with the flattening. A problem for some people, but not for others, it all depends on how much you paid for your compositing software. Heck, even After Effect gives you an open dialog to choose how to interpret the alpha.

Does the intrinsic fact that flattening the image does not actually remove Transparency but instead replaces the Transparency plane with full coverage, full resolution 100% Transparency field for the entire Cutout complicate matters? Who knows but its doubtful.

Why can’t we easily “swap” this information without fear of damage to the file?

I do realize that something regarding this was being discussed in the latter portion of the thread. But it can’t be a hack. It must allow for the Alpha to be moved wherever the user wants it, not just to Layer Mask and back, but anywhere the user wants to put it.  And it must prevent the alteration of any color data or alpha/mask data in the process.

WHY MULTI-FORMAT WORKFLOW IS PROBLEMATIC IN PHOTOSHOP

Everybody has their own pipeline and workflow. Everybody uses different images for texturing, different images for rendering, and different images in comps. The choices made and used are often predicated on the software being used and the best formats which those softwares support.

Add in pipeline, workflow, stability, and standardization issues, very few people can stick with just one format through the entire process. And PSD is rarely ever that format due to it’s being a format which is so extraordinarily sophisticated.

Its true that sometimes less is more. In the file format game this is incredibly true, especially with image formats that are used as textures. Yes, I know that there are a lot people who would love to use PSD and place all sorts of maps, of every imaginable relevance, into a PSD and use it as a texture source. Some apps support this. But the reality is that most of us stick with native formats because we know they are incredibly trustworthy, and the PSD often isn’t.

Why? Because it possesses too many possible construction combinations running the risk that one or more of those combination will cause problems because the app can’t foresee the possible combination and the complication which may arise. Then there is version issues. PIC and IFF haven’t changed in how many years? PSD Is getting updated how frequently? In this case less IS more, or more is less, all depends on your point of view.

What am talking about? Images with layer masks, with multiple layer masks, with vector masks, with alpha channels, with extraneous channels, with smart objects with…..well I think you get the picture. I use App X, therefore I texture with App X’s native format. Besides, most of these textures will get converted to a binary map of some sort before rendering to make them more efficient for rendering. Massive image maps of the Mars surface come to mind here, that sort of thing.

The point? The point is that I want to use the native formats as much as feasibly possibly because they provide less risk. If we’re getting TIFS with Alphas but need to save as Maya IFF, the pipeline becomes convoluted if Photoshop is introduced. We read the TIF into PS, edit the alpha, bounce the alpha around several times from alpha to layer Mask, to Transparency, yada yada yada, then we export to OpenEXR so we can convert back to Maya IFF outside of PS. This is the point. We’re dealing with ridiculous levels of effort, uncertainty, risk, and liability because Photoshop is not providing reliable image in/out support when writing to/from our native formats.

For starters why can’t we just Open the TIF and Save as Maya IFF? Because saving Maya IFF or Softimage PIC files with Alpha, directly out of PS often results in a corrupt, partially corrupt, or apparently corrupt file. We’ve discussed that. Then there is the issue of the TIF import placing the Alpha in an extraneous channel when, even if Maya IFF worked, the Alpha has to find its way from Alpha Channel to Transparency, just for the Alpha to get exported on the save. But most other PS format imports take the Alpha and store it to Transparency. But If I ignore the difficult workflow and go the extra step to save as OpenEXR, this creates even more work for the artist outside of PS to convert back to the file of choice.

So ultimately there is an inconsistency in Import/Export behavior, the Alpha in some files go one place, in others to a different place upon import. All file imports should send the Alpha, at a minimum to the same place(preferably to the Alpha Channel or Layer mask). The current workflow creates uncertainty, multiple workflows, extra work for the artist, and in general mass confusion when it comes down to what Photoshop is really doing to those sacred Alphas, or in some cases to the color. This kind of confusion in an application is bad. It generates distrust of the software because it is perceived that it can’t be used for purposes it needs to be used for.

WHAT NOW?

So I’ve said plenty about the reason why the current Photoshop workflow presents problems, difficulty and risks to file integrity etc. What should be done about it?

We’re not asking to alter Photoshop in some way that screws up the good things about the software. We are asking for changes in workflow, and in the interface which provides more options to the users while retaining as much of the existing workflow that other industries rely on.

Oh yeah, that’s right, other industries. Almost forgot about that. In my long career I’ve worked in some of those industries. I have a perspective about that too.

Photographers mostly edit photographs, they rarely ever open PSDs or other images with Alphas in them.  Alphas are at least mostly insignificant here.

Print/Layout/Design folks do on occasion rely on Alphas, but not for the same reason CGI/DCC does. There is a bigger workflow cooperation with other applications than say Photographers require, more workflow between Illustrator and the like. Alphas are at least partially insignificant here.

Arch/Vis and Sci/Vis folks are in sort of a purgatory halfway between Print and CGI. A lot of static images, renderings, etc extremely large resolution images, etc, but drawing from external applications which generate imagery and put together in Photoshop. Alphas are significant here.

CGI/DCC/Vfx folks are generating the vast majority of their content electronically outputting to video or film, in most cases PS performs a supporting role as opposed to the application used for final delivery of product like Photo or Print/Layout. Alphas are extremely significant here.

Adobe needs to be having a significant conversation with people in the CGI/DCC/VFX industry as to why the Photoshop Alpha workflow does not currently work as well as it could.

Bear in mind that folks using PS in CGI are rarely opening Photoshop to use it as a final compositor. We have compositors, good, highly sophisticated tools that process thousands of images, not just one or a handful. We are bringing files into Photoshop to directly edit the color or the alpha. We’re not using Photoshop as the final compositor like Photo or print people do. Bringing images into an editor that converts them to cutouts by default introduces a bizarre workflow when all we want to do is open the file edit alpha and save the file. A photo person might only want to bring in 20 images and make one image, making custom masks along the way with each image in a new layer. This is the significant difference in need which drives the pain we are feeling with Photoshop which other industries don’t, or can’t, fully understand.

WHAT NEEDS TO BE DONE?

For starters, a comprehensive overhaul of Photoshop’s entire OPEN/SAVE functionality. Full featured, across the board, unified file format system support

All CGI/DCC file formats need to be supported natively within PS with the highest level of support by PS.

File format support should NOT be implemented as Plugins if possible, when and where possible. Why? Because it needs to be consistent, and we need Adobe to take control of this problem once and for all. Besides how does the most popular image editor in the world work well without taking file format support seriously?

All import/export/open/save functionality needs to be fully scriptable.

OPEN/SAVE functionality and dialogs need to provide the user with explicit control over where the Alpha ends up in the PS upon opening and which alpha/mask/transparency source is used upon saving. Options should provide the user with the ability to send the Alpha to Transparency, Layer Mask, or an Extraneous channel as REQUIRED by the user, or which channels, mask or transparency to save to the Alpha in the file of choice.

Open Dialog support should also include an option for proper alpha interpretation, straight or premult.

If sending Alpha to Mask or Channel on Open, then transparency needs to be full field blank, or some solid color to prevent over multiplying the masking effect.

We need the ability to unlock the standard background image plane.

The Transparency from the Cutout needs to be viewable and editable, either as a specific unique channel or separate editable scalar image plane.

Transparency, Layer Masks, Alphas all need to be explicitly swappable at a single command. The user should be able to move these fields to whatever part of the software they need it to go to, without the swapping affecting the source data in any detrimental way. That means that the necessary steps must be taken to prevent over multiplying or over adding masks, transparency whatever in the swapping process.

When saving a file with a full field of Transparency and a Mask or Alpha, the transparency needs to be properly removed before saving the file with Mask or Alpha selected as Alpha output.

SUMMARY

I am certain that are things here which I have forgotten and that other folks would have things that should also need to be addressed regarding this topic. If I’ve gotten anything technically inaccurate in regards to how Photoshop works please feel free to correct me.

I do realize that I haven’t touched much on the entire Premult/OpenEXR issue. As I said earlier the premult issue is a math issue and can be easily resolved. The bigger problem is workflow and a general sense of incompatibility with DCC/CGI.

This is not to say that premult is not a serious issue, it is. But for most of us Premult is already handled when the image is rendered, or if not produced there it is handled appropriately by the compositing software such as Shake or Nuke or whatever. Admittedly is very disturbing that if I create an image in Maya with premult on and Place that image into PS, the layer is comping incorrectly and I must force premult off in Maya to make it comp as it should.

We don’t want Adobe or PS tinkering with our Premult settings if it can be avoided. Like every app we deal with, PS should provide Premult processing as an option for us to force it when needed and ignore it when needed. The artists, TDs, compositors, and rendering technicians are the best judge of this, not Adobe.

Ironically Open EXR is the least of our problems. Surprise surprise! It works better than most of our other application’s native formats. I fault the whole 3rd party file format plugin exercise for this inadequacy, but that was the result of Adobe ignoring these formats while everyone else was trying to support RLE formats, raster metafile formats, and other formats.

Even OpenEXR is still susceptible to much of the Photoshop workflow which is what got this thread started. The bigger problem that I have tried to address here is that anomalies inadvertently turn up when people who use Photoshop are not fully aware that the Photoshop paradigm is tripping them because the paradigm’s Achilles heal is that it requires every layer to possess a cutout with a transparency and that what has become Transparency in some cases was once our scared Alpha….or sacred Alpha that is. (If I were an Alpha in Photoshop I’d be scared too, suppose that typo works anyway.)

But I digress, every image we load in Photoshop becomes a cutout and we’re trying to edit alphas on images which are cutouts. Whoda thunk it? For DCC/CGI people this does become a scary and complicated proposition. Our alphas are being scavenged, stolen even, to facilitate a some 20+ year old Photoshop workflow which requires every layer float over the previous. But really what we want is our images to be a canvas and our relative, inclusive, exclusive, associative, but dissociative alphas back so we can edit them too. But we feel like Adobe is telling us that Adobe knows better what we should be using Alphas for.

Do some people use Alphas for things other than compositing? Sure. Do some developers use Alphas for other things? Sure. That does not change the fact that the Alpha’s primary intent is to assist in the compositing of one image over another. It does not however give one developer the right assume that the way this has been done for over 20 years is wrong and their way is right. Might their way be better? Possibly. For some people. In some instances. But not for everyone.

It would be really nice if we could have special “canvas only”(read no transparency) layers but I do realize the canvas thing is not likely. However better alpha management is absolutely crucial.

Adobe needs to be mindful that data finished in Photoshop works ok in the current Photoshop workflow and paradigm. Setting Photoshop standards that others want to take advantage of and are willing to accept as their standards is fine and we are ok with that. We don’t want to destroy that. But we want options. When data exits Photoshop, with the intent that this data will be used in other software, the data must not be violated in anyway which damages the integrity of the data or the workflow and pipelines of those who use the data. Any real workflow which is less than that runs the risk of making Photoshop a risk or liability in that pipeline or workflow.

Transparency, opacity, mask, matte, alpha, it can all be the same thing, or it can all be different, just depends if you are a airbrush artist(mask), video editor(matte), 3d artist(alpha), or developer(transparency/opacity). This exercise over obsessing on the interpretation of the essence of the meaning of the specification is well….bizarre.

Please stop for just a second, put the specifications down for just a second. The specifications are only as good as the people who wrote them and the people who read them. Trying to match one set to another or fit one set into your own interpretation of things can be wrought with seriously pitfalls and perils if you interpret too strictly.  But realize that there are multiple definitions and interpretations to the same terms and put just as much effort into trying not to ignore your customers and what they are telling you as you are to not trying to ignore the written specs.

You have one industry which you can not harm, print/photo, because there you have it right. You have another industry, CGI, struggling to be heard because the print/photo design of your app is extraordinarily destructive to them as I’ve demonstrated for you in specific detail.

We would respectfully ask that Adobe do whatever it can to accommodate these needs, implement these requests, change this software when and where it can to make Photoshop less a risk for us and more an application we actively seek to use for every task which it provides a superior benefit.

Thank You

Joey Ponthieux

Yorktown, VA

PS It would really be nice if Adobe would send your engineers and programmers to Siggraph every year so we could share these comments and concerns with you face to face like we do most other CGI developers.

PS2. I’ve not used CS4 yet so if any advancements have been made there which address these concerns, they will be welcomed.

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Engaged ,
Aug 27, 2009 Aug 27, 2009

Copy link to clipboard

Copied

I flatten the image thus compressing and reinitializing the Transparency.

(Transparency isn’t removed, just reset).

I think you need to clarify this. When you "flatten" a file, you are removing or for a better term, applying transparency and a Background is created. Technically, a "Background" is not a layer and therefore can not have transparency.

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Engaged ,
Aug 27, 2009 Aug 27, 2009

Copy link to clipboard

Copied

You have one industry which you can not harm, print/photo, because there you have it right.

I think it's best to stick to your CGI issues because print is a complete mess in my opinion, but that is another issue all together.

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Beginner ,
Aug 27, 2009 Aug 27, 2009

Copy link to clipboard

Copied

it could be much worse. When I was in print we learned how to do

everything on a drafting board and triangle. I realize there are complex

issues in print too. PMS stability, etc. But in general from a content

creation standpoint for print and image generation, photoshop gets it

right. What I am trying to focus on is workflow issues. Most people who

sit down to do a poster or layout or art piece don't have anywhere near

the workflow issues CGI does. In my opinion photoshop is actually too

easy for print/photo work. Thats what creates the problem with CGI

workflow. Photoshop is programmed to do too much automatically for the

user which the user should be forced to do manually so they can have

more control over the process.

My dream app would be the merging of Illustrator and Photoshop together,

thats about the only thing that would solve a lot headaches for me when

doing print work.

Joey

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Engaged ,
Aug 27, 2009 Aug 27, 2009

Copy link to clipboard

Copied

Joey -

I don't want to make this thread go completely sideways and I can easily do that. I think we need to focus on CGI issues and file formats. Print is a mess because there is no workflow, but that is another story.

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Beginner ,
Aug 27, 2009 Aug 27, 2009

Copy link to clipboard

Copied

A background is only a locked layer. Its still a layer.

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Engaged ,
Aug 27, 2009 Aug 27, 2009

Copy link to clipboard

Copied

Technically a Background is not a layer.  A layer supports transparency.  I know a lot of people call a Background a layer, but realistically its not.  Symantics?  Maybe, but a layer is defiend as having transparency.

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Beginner ,
Aug 27, 2009 Aug 27, 2009

Copy link to clipboard

Copied

Mike,

Reviewing that excerpt a little closer, I did omit a step here. In order

to reorder the column you have to duplicate the Background layer and

delete the background layer. I omitted that step in the example. The

background that is created, again because it is locked, must be

duplicated again in order to manipulate it.

I have no knowledge to the contrary, but I can't see how the Background

layer is any different than any other layer other than it is not movable

and can't be unlocked. But you can duplicate it and you can delete it so

aside from being some kinda useless freaky teenage mutant ninja layer it

has to still be a layer. If it had some kind of special meaning or was

unique beyond being locked and unmovable in the layer column, I don't

think you would be able to delete it. That would not make sense.

Frankly the background layer never made any sense to me. Deleting that

thing is the first order of business after creating a new file or

opening a new file and duplicating the background. Whats the reasoning

behind this thing anyway? Are the users not smart enough to know whether

to lock the image if they need to, position it as the last image in the

column if they need to? Why am I required to go through these extranous

steps of nuking the locked background just to edit my image?

I'm really not sure what its reason for existance is but the day it gets

permanently removed will be a glorious day.

Joey

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Engaged ,
Aug 27, 2009 Aug 27, 2009

Copy link to clipboard

Copied

I have no knowledge to the contrary, but I can't see how the Background

layer is any different than any other layer other than it is not movable

and can't be unlocked.

Again, A background is not a layer and does not support transparency. You can unlock a background by double clicking on the icon in the layers palete. It then becomes a layer and not a background technically. Therefore, you now have active transparency in that object - like it or not.

You can move the contents of a background by moving channels one at a time. It's a total cludge to do what you require, but it's not completely locked per say. There is a huge bug in the app whereas if you toggle the eyeball in the channels palet on and off after moving said channel out of the canvas area,  it will lose the data outside of the canvaa and is vaporized for good.  So in conclusion ur kinda screwed either way you look at it unless you work with an oversized canvas and are willing to move one channel at a time on a background canvas area.

yea right..

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Engaged ,
Aug 27, 2009 Aug 27, 2009

Copy link to clipboard

Copied

Frankly the background layer never made any sense to me. Deleting that thing is the first order of business after creating a new file or opening a new file and duplicating the background. Whats the reasoning behind this thing anyway?

It's there because its been there before layers and some scripts and imaging requirements need  a non transparent object. It's there because Multichannel needs to function in a non transparent environment and it gives the user the ability to move around channels independant of eachother.  Photohsop is so hard coded for RGB or CMYK channels and it really needs to break out this channel restriction, but Im afraid it would break many other industries if Adobe did that. But, I have other ideas to address that but thats again another long winded story.

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Beginner ,
Aug 28, 2009 Aug 28, 2009

Copy link to clipboard

Copied

Again, A background is not a layer and does not support transparency. You can unlock a background by double clicking on the icon in the layers palete. It then becomes a layer and not a background technically. Therefore, you now have active transparency in that object - like it or not.

So if I double click on the background, then click OK on the dialog that unlocks the background. How very..... intuitive. I've been duplicating and deleting since before the Photoshop version I used on SGI 13 years ago. Learn something new every day. Thanks

Not trying to over analyze the mouth of a gift horse, but, there is so little in depth information in PS docs that explain what a Background really is. As i reviewed these docs this morning several times it refers to the Background as a "background layer", so one would only assume it is a layer, complete with transparency but locked, or rather super-locked.

Since I don't really know, I'll defer to your explanation of what a Background is, and I am sure that a lot of users rely on its existance, but if its that easy for Photoshop to currently support and convert a regular layer to a transparency-less background layer, and visa-versa,  whats stopping them from easily implementing a strategy for the full support of true non-arbitrary alphas and the transfer or swapping of alphas using a variant of this background object?

In other words it would be a Canvas object based on the Background object which can only be manipulated with Layer masks instead of tranparency and does not require, permit, or possess a transparency ever. It would be an option to the regular layer and not the rule. This would bring Photoshop partially in line with what most CGI artists need as it relates to the alpha. At least in the effort to prevent adding of the transparency and mask/alpha which ends up corrupting the image.

Since a layer with layer mask, and theoretically a restricted canvas layer with layer mask, would display the mask as a fourth channel in the Channels column, the same as would be expected with an alpha channel representation in any CGI compositing app, one could both edit the imported alpha(imported to layer mask) and color(RGB), see them and manage them in Channels, edit, copy and swap them individually in Layers, and still get compositing behavior as expected using the layer mask exclusively instead of transparency. 

For swapping alphas(masks) etc, one could bring in another layer with mask, unlink the masks, and drag and drop adding a swap feature option to the replace feature currently supported during a drag and drop of masks across layers. This would all be dependent on the ability to redirect alpha to layer mask on open, and the reverse on save.

The ability to convert to this Canvas layer to a Background or Regular(transparency) layer and back would also be expected. And of course this would all be dependent on whether "layers" do actually exist without transparency as it would be assumed that Background is per your assertion.

Just an idea.....

Joey

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Engaged ,
Aug 28, 2009 Aug 28, 2009

Copy link to clipboard

Copied

I for one believe that it's time for Adobe to get their crap together and divide Photoshop into industry specific builds. They were on the right track with Image Ready, but they blew it when the company merged with Macromedia. Now we have a Standard and Extended version of Photoshop that is completely lost as far as I see it. They don't understand the industrues they cater to as well as they should. Adobe is trying to make Photoshop do too many things all at once and it's just a mess, but I do understand your issue and I agree that ur screwed.

Print may be seen less screwed by you compared to your issues, but screwed just the same in a different form and function.

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Engaged ,
Aug 28, 2009 Aug 28, 2009

Copy link to clipboard

Copied

Adobe_Creative_Suite_4_logo.jpg

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Aug 28, 2009 Aug 28, 2009

Copy link to clipboard

Copied

Joey - I don't know where to start.

You still have a lot of history and terminology confused, and you don't seem to see the connections between CGI applications and Photoshop. Your rant on "alpha" is particularly telling. You ignored the more common usage of "alpha channels" and the definition of alpha channels in file formats to rant about how Photoshop's common usage of the term and adherance to file format standards does not match the imagined usage in your industry niche.  You also made a lot of statements about alpha channels which are wrong because you ignored the problems of premultiplied color and straight color.  The fact that you ignored all the corrections and explanations already made in this topic is also pretty insulting to everyone involved.

Then you rant about file formats with results that don't match any bug reports, or anything anyone has ever reported about Photoshop file format support.  Photoshop is a vital part of many CG workflows, and aside from people not understanding file format specs or the word "alpha channel" there are almost no problems reported. The few file format problems reported are due to corrupt files causing crashes, or really obscure variants of file formats not working as expected (ie: CCITT images over 30,000 pixels across, 13 bit signed integer pixels not loading, etc).

Yes, you are much too close to the trees to see the forest.  Please realize that we are looking over many forests - yet we do take the time to learn about and help each small area.  We may not always do things exactly the way you envison them -- because we're looking at a much bigger picture and trying to help a lot more users than just you.

BTW - Adobe has a pretty huge presence at SIGGRAPH every year (check the authors for the past few years), and other CG conferences, and image processing conferences, and CG trade shows, and ....

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Beginner ,
Aug 28, 2009 Aug 28, 2009

Copy link to clipboard

Copied

Joey - I don't know where to start.

Please start with the first item in the text that you think needs to be addressed and refute the opinion, argument, or example with evidence to the contrary. From there, Wash, Rinse, Repeat. I will openly welcome a point by point discussion on each item.

You still have a lot of history and terminology confused

Respectfully no I don't think I do. I was rendering 3D animations with CubicompPicturemakerin 1988. I was compositing these animations with Cubicomp Sequence using their .a8 channel during that time. 1988 was barely one year or so after Photoshop was even conceived. A couple of years prior to that a professor was teaching me in regards to the use of key channels, or "alpha channels" as he referred to them as they related to the functional operation and communication between a Laird character generator and a Grass Valley switcher and it's downstream key.

you don't seem to see the connections between CGI applications and Photoshop.

Unfortunately there are few reliable connections between modern CGI applications and Photoshop. Thats what I and numerous others during the course of this thread have been trying explain. Photoshop does not behave like or behave well with most modern CGI applications or the products they create. Do they work, in most cases, but not like they should. I provided to you point by point examples how this is the case with files from both Maya and Softimage. Are there connections, sure, can Photoshop be used in CGI, absolutely, if you want to bludgeon yourself with the Photoshop Paradigm, absolutely there are connections, again I provided direct examples of just such cases.

Your rant on "alpha" is particularly telling.

Well...it wasn't a rant, but you are certainly entitled to view it that way if you wish.It wasn't a technical specification driven example of what an alpha is. I didn't intend it to be that. I was attempting to convey to you how and what we, animators and compositors, use, perceive, understand, treat, and expect from, the Alpha. How the Alpha relates to our world. I don't think you will find any digital compositor that disagrees with my...uh...rant...because these principles have not changed in over 20 years.

You ignored the more common usage of "alpha channels"

Please tell me what the more common usage of "alpha channels" in Maya IFF, SoftimagePIC, SGI, TGA and EXR files are.

and the definition of alpha channels in file formats

Please tell me how many file formats define alpha as transparency, how many define alpha as opacity, and how many define alpha as a mask. In all truth, I don't know the answer to that question.

to rant about how Photoshop's common usage of the term and adherance to file format standards

Please tell me why a Softimage rendered PIC file and/or Maya rendered IFF,  when read into Photoshop and saved out of Photoshop, are larger in byte size when then they are saved out of Photoshop with absolutely no change to the file and saved to the same format they were sourced from?

does not match the imagined usage in your industry niche.


Are you saying that I am imagining how I use and expect to use the images our software creates?  I'm stunned. I've rendered from Cubicomp, Softimage, Mental ray, Maya and Max, and I've composited in Sequence, Softimage Eddie, After Effects, Max Video Post, Wavefront Composer, Discreet Flame, Shake, and SoftimageFX Tree. Did I imagine my use of these apps too?

But then you did say that OUR INDUSTRY niche imagines how we use these things, didn't you? All of us. Thats cool. We all get it wrong I suppose. Not just me. I feel better now. I'm in good company.

You also made a lot of statements about alpha channels which are wrong because you ignored the problems of premultiplied color and straight color.

Premultiplication. Sure, we can discuss this. Premult is pretty easy to understand actually. I don't remember the actual math anymore, and the concept, the whole multiply the color at the antialias edge using alpha as the multiplier thing so that black(the black in the RGB plate under the rendered object) is not added to the comp at the antialias perimeter is well,.... boring.

But suffice it to say you multiply the anti-aliasededge color in order to cancel out the background black rendered into the anti-aliased edge. When using the pre-multiplied image with the standard alpha you don't get a black ring in comp because you canceled out the black in the anti-alias edge as it relates to the alpha's corresponding anti-alias. But you see I don't normally have to worry about those details.

Its like this. Most 3D apps, I'll address Maya and Softimage specifically because they are the apps I use now, render in one of two states. Premult or no premult, some call this straight. Soft and Maya rendering both allow you to change this state and both are set to premult by default and most compositors use this as the default if they are going to comp these images in Shake, Nuke, or whatever. If I bring an IFF file and a PIC file both into Shake, comp with an Over node, I can swap out the IFF and the PIC to the Over node input till the year 3000, they will both work identically with no black alpha ring, because the Shake Over node knows how to handle the rendered premult edge properly. It was the same with Composer, Flame, Eddie, etc. I think in Eddie you had to throw a switch to force premult computation, but it supported it perfectly. Even Cubicomp did 20 years ago.

The point is that premult is either on or off, and all 3D applications support Premult computation fine. So why can't Photoshop support it correctly? Why is it that when I render an object in Maya with premult on and take the rendered IFF file and Place it in Photoshop it has a black ring around it when Shake handles the premult image just fine? Why do I have to go back and rerender in Maya with premult off in order to get a straight image to use with Place? The assumption is that Place is designed to work with straight by default, is this true?  I don't have a clue, but I know my Maya image is rendered with premult on. I also know I have to rerender with premult off to make the image composite correctly in Photoshop. Whats up with that?

Is it the IFF reader that messes this up? Is it Place? is it the Layer? Why doesn't Photoshop use premult by default like every other high-end CGI compositing app? Lets examine this in more detail.

OK, So All I have here at the moment is XSI and Photoshop CS.

I render two images from XSI, both are the same camera shot, single frame of a red crcle over black.

One image is with premult, one is straight.

The premult image is 21 KB large.

The straight version is 15 KB large.

So lets benchmark this, we'll open SoftimageFXTree and create a comp.

Load both images as file inputs

Create  an over node.

Create a mask shape and make it full field white

Connect the white field to the background input of the Over node.

Connect the premult image to the foreground input of the Over node.

Open the viewer and look at the result.

By default Over is created with Background type set to Pre-multiplied.

Since we have the premult image connected to fg and premult as the process method, that is the method and image type match, there is no black ring.

Now if I change the background type in Over to Not Premultiplied,,,,oh my

There is a black ring now. Look familiar...youbetcha...but we'll touch on that in a bit

Now lets connect the straight image into Over fg disconnecting the premult image from the tree

Odd. It renders just fine, no black ring. Hmm...no whats up with that?

Change it back to premultiplied, again no change, no black ring... curious?

Well, whats going on here is that the image, when rendered from Softimage with premultoff, renders the object edge so that there is 100% color not mixed with background black. In essence the image RGB looks like it is aliased as opposed to anti aliased, but closer inspection reveals that what has really happened here is that anywhere the alpha's antialias is rendered at non-zero the RGB anti alias is replaced with full color, giving the comp solid color to blend in the comp and the appearance of an aliased edge. It doesn't matter if we switch Over's background type setting back and forth, between premult or not premult types, the result is visually the same.

So on to Photoshop.

We bring both images, the straight image and the premultXSI images into Photoshop CS.

Place white layers below each

The premult image has a black ring around it

The straight image doesnt.

So why is that? What this presumes to tell us, at least as it relates to XSIFXTree, is that the premult image in Photoshop is being computed as not premultiplied because it is the same result we get when we set the Premult image in FXTree to be computed using Not Premultiplied in the Over node.

So we attempt to change the layer blend mode. Normal, Screen, Overlay etc.

Hard light, Vivid Light, Pin Light and Linear light seem to help, but are these safe for the color in the rest of the image. We want a direct over result, we don't want the rest of the image to be affecting incorrectly.

So blending doesn't really help or doesn't appear to be safe for what we want to do. Normal doesn't cut it.

Is there a true premultiply processing feature in Photoshop? I can't find it.

So after I render 3000-4000 frames of a video animation, comp it and send it to video the client comes in and says "i'd really like to make a montage now of alot of the elements in the animation for some print stuff, can we do that?"

Sure I say, so i load  Photoshop and start bringing in premultiplied rendered foreground elements that I just comped in Shake and they all have black rings around them. So I have to go back to maya or XSI and rerender them all, just for Photoshop. Not for FXTree, not for Shake, not for even After Effects, but I have to do that for .....yep...Photoshop.

So please, tell me again exactly what I ignored regarding the problems with premultiplication?

The fact that you ignored all the corrections and explanations already made in this topic is also pretty insulting to everyone involved.

I did not ignore any of the corrections and explanations already made. I read them. The whole thread. I don't accept some of them. I disagree with some of the assumptions being made about CGI and the work that we do. I don't accept the excuses being made here regarding what can and can't be done to make Photoshop better. I don't agree with these conclusions, because ...after all....we've been told that the way we use these images is...how did you put...imagined?

Truth is, we are the ones who should be insulted. Personally I'm more amused at this point. I've only got several hours of finished animation in my portfolio from the last 20 years, many animations of which had as many as 20 or 30 comped layers and foregrounds(those broadcast news folks...they love to see hundreds of little floaty shiny things in their graphics).  Lets see, 30 frames x 60 seconds x 60 minutes x an average of 10 layers......if i discount the background layers .......that easily a million images I've composited per every hour's worth of portfolio. I think I know how an alpha channel is supposed to work.

Then you rant about file formats with results that don't match any bug reports,

Consider the examples I provided as a new bug report. Seriously, break out your copy of Maya, fcheck.exe, Softimage, etc, create the test images yourself, follow the instructions I laboriously provided. If the results are different tell me how I screwed up. I can take that. But if my examples show what I described, please log the examples as bugs and lets have a discussion about what I have described to you. You did after all ask for someone to provide a good reason.

Photoshop is a vital part of many CG workflows,

As I pointed out in detail. I've worked in Print, Television, and Animation. At one point in the 90s I worked at a television station where we used Photoshop to generate text elements for our Quantel Express. I think I'm well aware of the different workflows.

and aside from people not understanding file format specs or the word "alpha channel" there are almost no problems reported.

So how do you explain the complaints in this thread? We're trying really hard to share with you the problems we are facing. If there are no other problems than ours being reported regarding Photoshop, then Adobe's plate must be really open to listen and accommodate our needs. At least from your account of it, it sounds like we are the only ones complaining.

Again, I encourage you to sit down and replicate the examples I have provided you. I think you will find these things to be illuminating. And don't discount the references to the way we used to do it in Matador or other CGI applications. They may be prehistoric by todays standards, programmed in Fortran and all, but there is alot to be said about the features they had which excelled in their simplicity. We are seeking the same thing from Photoshop.

The few file format problems reported are due to corrupt files causing crashes, or really obscure variants of file formats not working as expected (ie: CCITT images over 30,000 pixels across, 13 bit signed integer pixels not loading, etc).

Once again you need to review the file issues I've illustrated here. The byte size differences, the difference in display between Photoshop and fcheck etc. Photoshop is creating non-standard versions of some these formats. They appear to work, look like they work most of the time, but there are artifacts being displayed in some of the files being generated from Photoshop, the file sizes are wrong or inflated beyond what they should be. You seem like the sort of person who really wants to adhere to the specifications of these formats so I think this would be a serious concern or you.

Yes, you are much too close to the trees to see the forest.

Yes you are right. I have been in this forest for a very long time. But I'm not lost and I've seen some of these tree grow up from little saplings. Some cut down from shear corporate stupidity and others clear cut in the wake of shifting industry winds.

yet we do take the time to learn about and help each small area.  We may not always do things exactly the way you envison them -- because we're looking at a much bigger picture and trying to help a lot more users than just you.

Funny, I don't feel like Adobe is taking the time learn about my area. If I'm mistaken please correct me, but in this response I've been told that the argument i provided you, with excruciating detail and long comparison of what we expect and how other apps did it, is a rant?  I'm further told in this response that I have a lot history and terminology confused, I dont see the connections, oh yeah I rant some more, I ignore common usage of alphas, I'm wrong, I'm insulting, and oh yeah, I...we in this industry, have an imagined understanding of it. Forgive me, but we're not feeling the genuine concern that Adobe is really interested in our plight. In fact....at least for myself, I feel belittled by this whole process.  Whether its pointed at me or other people on this thread who were trying very hard to convey their problems with the software. I know what they are dealing with, been there done that. They're not making this stuff up. Its not imagined. And when you have to fight with these inconsistencies not just once, or here or there, but for hundreds or thousands of images, you start scratching your head wondering, why is this workflow so poor. After all, making an animation  is not like creating a poster. There could be tens of textures involved and hundreds if not thousands of rendered frames.

I went through this exercise to share with you some things which I felt had not been discussed so far in this thread. The EXR thing is only one problem, but ultimately its not the worst of these problems. I was trying to illustrate how these other problems, while related to EXR, are part of a much bigger workflow problem. I went through the enormous detail and length that I did to provide you a serious and fair criticism of whats wrong with Photoshop for us. You did after all ask for that. Twice. I did NOT want to respond with "photoshop sucks", because it doesn't but its a far cry from a good fit in this industry. I've seen my applications of choice, Matador, Aurora, gFx, etc all fade into history. I use Photoshop because there is little to nothing left that can do what it does and do it across CGI and Print. Just because Photoshop is king of the hill now and no one is trying to make a custom CGI app anymore doesn't mean that Photoshop has it "right". It just means it survived, mainly because of it price point. My first seat of Matador cost us almost $15K back in the mid 90s. There are thousands of people who own licenses of Photoshop. Only a handful push the software to its limits. We are a large part of that handful.

I have had these arguments regarding Photoshop for years. There are some people who work in this industry who think PS walks on water. "PS is the industry standard", "PSD files are the industry standard", and all that.  I don't want to deny them their loyalty, but in many cases they are wrong. It doesn't work like it should, and in many cases they know it but can't explain why. And not being able to explain makes it easier for them to maintain their undivided loyalty. Thats why I wrote this. I wanted to explain why because I know why I have problems with this software. I know what I want it to do that would make it better. Because I have a perspective, it may be a bit prehistoric, but a perspective that most, no 95% of Photoshop users don't have. I've used Matador, I've used Aurora. I've used applications designed specifically for my industry. In a lot of ways they were superior to Photoshop for my needs. For $10K or more they had better be and they were.

BTW - Adobe has a pretty huge presence at SIGGRAPH every year (check the authors for the past few years), and other CG conferences, and image processing conferences, and CG trade shows, and ....

Papers sure, but how many of your developers and engineers show up to talk to Adobe's average user? Its been many years since I've seen Adobe in the Exhibition. 2001 or 2003 maybe. As for other trade shows, I'm not interested in those. I'm interested in Adobe showing up at Siggraph with real people to listen to their users in this industry.

Finally I would ask again, run the examples I provided you for yourself. If you don't have the time find an intern or someone else to do that and get their opinion on whether I provided you a good example. But verify these results against the apps the final images or created for. I'm sure you've got copies of Softimage and Maya, don't you? Shake? No...probably not Shake, ....get a copy of Nuke then. If my examples don't measure up, let me know how. If they do, then lets figure out a way to fix it or at a minimum reduce the number of commands and actions required to do the work. You're a smart developer, I'm not worried about your ability to program the features, but I think you and your team need a different perspective on what people want from this application. I'm more concerned with workflow issues, fewer keystrokes and buttons to push, ease of use. Stronger compatibility with the CGI softwares I use. Preserving my alpha channel from unecessary corruption.

I, and a lot of others in this industry can provide you a lot of insight into what would make Photoshop a real, rooted staple in this industry. We need to do things such as rotoscoping(Matador, that prehistoric beast, did that you know), sub pixel rendering(Matador did that too), along with all the other stuff I already mentioned. We're very eager to share our thoughts. We just need someone to listen.

Joey Ponthieux

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Aug 29, 2009 Aug 29, 2009

Copy link to clipboard

Copied

Thank you Joey. 100 x thank you.

And another personal thank you on the end. If I were close enough, Id give

you a big hug.

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
LEGEND ,
Aug 29, 2009 Aug 29, 2009

Copy link to clipboard

Copied

JoeyP41 wrote:

We're very eager to share our thoughts. We just need someone to listen.

Gotta tell ya, in my experience (alpha/beta tester on Photoshop since about 1996) the way you in particular and the vast majority in this thread in general are going about it is all wrong. First off, presume the engineers have the attention span of a gerbil on crack cocaine...if you can't get your point across in 25 words or less, you've lost before you even started. I actually read each and every line you wrote...Chris might...but I suspect nobody else will.

The "troubles" in the way some industries use Photoshop is not Photoshop's problem to solve entirely. Photoshop's primary file format it's responsible for is PSB (the large file format) and PSD and TIFF in that order. Pretty much every other file format is the fault (responsibly) of somebody else. If an application saves out a file that Photoshop needs a plug-in to read, it's not Photoshop's responsibility to do ANYTHING other than what somebody else's specs say it should. If you have specifics where that is not the case, file a bug. I know for a fact that Chris and the other engineers pour their hearts into this stuff and are constantly trying to "do the right thing" even when the right things is not so clear cut.

You should also get off the thought that Adobe is in the position of being the ultimate arbiter of problems in other industries...Photoshop is part of the Creative Suite and has VERY LITTLE time to do anything other than a limited  set of new features, limited compatibility adjustments for the Creative Suite and try to test the heck out of it before it ships. If you want to bring about change, 2011-2012 is the time frame you should be looking at...

As for Adobe doing it's best to solicit the feedback of the various industry groups, it does what it can. The home office is at 345 Park Ave, San Jose, CA. Chris works out of that office...if you or a handful of industry leaders want to get together, I'm sure Chris could facilitate such a meeting. The hope would be to have a bullet point presentation with a list of the top 5 things that could be done to help YOUR industry. I'm sure John Nack would be happy to get such feedback...as long as you understand that little could change between now and the next version and the odds are it will be further out if you need something that requires massive changes–which is what would be required if I read your lengthy diatribe correct.

Oh, and saying you don't know what's currently in Photoshop CS4 ain't a really great way of trying to ingratiate yourself with the Photoshop engineers...

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Beginner ,
Aug 29, 2009 Aug 29, 2009

Copy link to clipboard

Copied

Gotta tell ya, in my experience (alpha/beta tester on Photoshop since about 1996) the way you in particular and the vast majority in this thread in general are going about it is all wrong. First off, presume the engineers have the attention span of a gerbil on crack cocaine...if you can't get your point across in 25 words or less, you've lost before you even started. I actually read each and every line you wrote...Chris might...but I suspect nobody else will.


I first became aware of this thread back on February. I read the entire thread and found the nature of its outcome disturbing. I thought hard about what I would say in response and I wanted to provide specific constructive criticism. If I thought for one minute that the engineers had the attention span of a gerbil on crack cocaine I would not have written the 17 pages I wrote. Nobody would have read it. I would have wasted my time. I don't think I did.

You can't always get your point across in 25 words or less. Sometimes subject matter is too complex, too deep, too misunderstood to be described in that manner. Is 25 words or less a better approach, sure if it can be used.  Numerous people attempted to make that explanation via brevity early in this thread. There were over 150 posts before I decided to respond.

I felt the prior attempts failed not because the posters or readers were incapable speakers or writers. When you discuss things of this kind of complex nature, one group sees the matter from their perspective, the opposition from their own perspective. If the two sides have extremely different perspectives, especially on things such as terminology common to both sides, but the terminology has diferent meaning, until one side goes to the extent to share more depth and background about how and why their perspective is defined, it may never be understood. The other side will struggle to make the connection, even if it is anxiously willing to do so. Because it has no reference for what the other side is trying to say and can easily misintepret what the other side is trying to say because all judgements by that side are referenced by their own unique perspective which is foriegn to the opposition.

In other words, its akin to a language barrier because each side has its own language base and neither can understand what the other is saying even if the words are understood. A person from south Mississippi might not understand a person from the Bronx saying "Yo, the popo be robbin my crib". he understands the words, but not the meaning. That was my take when I first read this thread. And oddly it reflected my longstanding perception of Photoshop in our industry. Its got a lot of singular things we can use and understand, But from a larger perspective, it does not make sense in a CGI workflow.

  The "troubles" in the way some industries use Photoshop is not Photoshop's problem to solve entirely.

Adobe creates software. It wants to sell as much of that software as it can. So its sells it to anyone who will buy it. At this point it has two options, it can create whatever it wants and ignore everyone who buys the software and only sell what it can to whoever is willing to buy it that way. Or it can cater to the people who buy and use the software and try to make if better for them thus building a symbiotic relationship with the customer and the software's development. If Adobe wants us to really like this software, sing its praises to our colleagues, be excited about purchasing upgrades, and be loyal dependable advocates of Photoshop, it is ENTIRELY Photoshop's....correction.... Adobe's problem to solve. If it doesn't want that it can do whatever it so chooses.

Theres another reason why it Adobe's problem to solve. Because our software, our deliverables, work a specific way, and have done so that way for decades. To a time in the early 80's since before Phostoshop was even created. We have decades of accepted practices as they relate to the Alpha, I tried my best to convey those.  This thread has left the unfortunate appearance that Adobe is only interested in its accepted practices and that our practices and requirements only need to come in line with Adobe. I say appearance however because I honestly believe that this situation is an example of misunderstood perceptions. Adobe perceives alpha workflow its way, we perceive it the way we have for decades.

I have been fortunate enough to work in both print and animation. I see both sides. I have a broader understanding of both perceptions. Its not unusual, uncommon, or unreasonable for two different user bases to have these differeing perspectives.  But when software developers allow their unique perspective to prevent them from seeing the perspectives of their cutomers they should not be surprised to find dissention in the ranks of the people who use their software.  There job after all is to make software that we like to use and will spend hard earned money to buy.

Photoshop's primary file format it's responsible for is PSB (the large file format) and PSD and TIFF in that order. Pretty much every other file format is the fault (responsibly) of somebody else.  If an application saves out a file that Photoshop needs a plug-in to read, it's not Photoshop's responsibility to do ANYTHING other than what somebody else's specs say it should.

Its Adobe responsibility to support any and all formats that they think will help them sell more copies of Photoshop.  If they don't want to support those formats they should not provide the plugins on the install dvds. If they provide the plugins, they better put the full faith and credit of Adobe behind their ability to support those formats properly. 

But this raises a serious question. Why shouldn't Adobe support these formats? Why would they not want too? Seriously, why would the company that created the "greatest image processor the world has ever known" NOT want to support as many formats other than PSD and TIFF as it can? Is that the definition of great software development?.... "use our sanctioned fomats,....your formats...their not worth our time" is that what youre saying?....you can't be serious? The more people who get their formats supported with care, quality, and reliability, the more people who will commit to buying the software and the fewer who will feel alienated by it.

It's Adobe's responsibility to listen to it's customers. Adobe can do whatever it wants. If it wants to not listen, its within its rights. It would be stupid, and I don't think Adobe is stupid, I think they just have a perspective about our industry which is not accurate and they are making judgements without accepting constructive input. At least, to be fair, thats the appearance of it.

If you have specifics where that is not the case, file a bug. I know for a fact that Chris and the other engineers pour their hearts into this stuff and are constantly trying to "do the right thing" even when the right things is not so clear cut.

I have no doubt that Chris and the other engineers pour their hearts into this software. Really I don't, in fact I think they do that so well that the "Adobe way" is more important to Adobe than what we are suggesting. An unfortunate cultural trait common in super large organizations. On the contrary I've known CGI developers, typically smaller companies, that have gone to extraordinary lengths to acquire their customers "heart" into there software. By asking them what they want, taking feature requests not just bug reports, having user group sessions which solicit ideas and open discussion about what they need. Their private and public philosphy is that of creating software thats easy for the user to use, because it was built on the backbone of what the user asked for.

The appearance I get as a result of this thread, the unfortunate conclusion I have acquired is that our concerns are less important than a perception of an interpretation of a specification. I realize that that may not actually be the case, but that is unfortunately the perception on this end that is being received. How else am I to fairly judge this, we were practically told that we have an imagined sense of how things really are in our industry. Without a doubt, its Adobe's responsibility to show us a different response or show us how our perception of Adobe's responses here are wrong.  The way to do that would be start asking us what we want, why we want it, and any ideas we have for implementing it. If Adobe can make it happen then we were listened to and we will know it. If it doesn't happen, we can live with that until something else better comes along. If it can't be done, tell us why it can't be done. Give us all the gory details.  And don't be terribly surpised if we disagree that it can be done. But don't tell us we don't know what we are talking about or that we have imagined how we perform our work.

You should also get off the thought that Adobe is in the position of being the ultimate arbiter of problems in other industries...

This has absolutely nothing to do with Adobe being the arbiter of problems in other industries. If you read both my posts you will note the problem as I defined is not in OUR industry. Alphas and images that hold alphas work fine between Maya, Softimage, Max, Shake, Nuke, Flame and Fusion. These images though don't work in Photoshop the way they do in these other apps. Again, the problem is not our tools, the problem is Photoshop. We desperately need Adobe to be the arbiter of the problems in Photoshop which I outlined in great detail. Or does Adobe, and yourself for that matter , actually believe that Maya, Softimage, Max, Shake, Nuke, Flame and Fusion are all screwed up at the same time, and Photoshop somehow has it absolutely 100% correct? If so, then would someone please also go tell that company that is developing After Effects how AE is screwed up too. Because it follows the same  rules on alpha compositing as Maya, Softimage, Max, Shake, Nuke, Flame and Fusion.

   Photoshop is part of the Creative Suite and has VERY LITTLE time to do anything other than a limited  set of new features, limited compatibility adjustments for the Creative Suite and try to test the heck out of it before it ships. If you want to bring about change, 2011-2012 is the time frame you should be looking at...

Thats why we're having this discussion now instead of 2011. I'll take the features I need whenever I can get them. Sooner would be better but I can't expect they will be done yesterday. Further a really complex discussion needs to be had about a lot more than the problems I outlined here. Things like rotoscoping, layer redirection,  and sub-pixel painting,  But they aren't as critical.

As for Adobe doing it's best to solicit the feedback of the various industry groups, it does what it can. The home office is at 345 Park Ave, San Jose, CA. Chris works out of that office...if you or a handful of industry leaders want to get together, I'm sure Chris could facilitate such a meeting. The hope would be to have a bullet point presentation with a list of the top 5 things that could be done to help YOUR industry. I'm sure John Nack would be happy to get such feedback...as long as you understand that little could change between now and the next version and the odds are it will be further out if you need something that requires massive changes–which is what would be required if I read your lengthy diatribe correct.

I'm on the east coast but if they were willing I would teleconference. Heck I'd buy a plane ticket if I thought they would provide all the time necessary to discuss this till its exhausted. I'd feel the time and money were well spent if there were adequate time for such an audience.

Bullet points? Thats easy

1. We would like Photoshop to provide true corruption free support for exclusive alpha channels

2. We would like Photoshop to provide editing, swapping, booleans and other feature support to Trasparency, Masks andArbitrary Channels. That includes the ability to interchange any T, M, or A with any other T, M, or A instantly.

3. We would like Photoshop to provide full integrated and unified file format support for at a minimum the post popular CGI formats. That support would include the redirection on Open of any file Alpha to a T, M or A channel or any T, M, or A channel redirected to Alpha on save.

4. We would like Photoshop to provide support for Canvas Layers. That would be described as functional layers without transparency, or at least at a minimum with transparency but with full field 100% Transparency permenantly locked. In that way Alphas could be processed as Masks without the fear of Masks and Transparency over adding or over multiplying and corrupting the image, alpha or both.

5. We would like Photoshop to provide full support for pre-multiplication compositing in the same manner it is handled in all the predominant CGI compositing applications.

I could add more, but if I am limited to 5, these would be it.

Oh, and saying you don't know what's currently in Photoshop CS4 ain't a really great way of trying to ingratiate yourself with the Photoshop engineers...

So is honesty a bad policy then? I shouldn't be up front that I havent used CS 4 yet when I haven't? If I describe something that I can't do, but it can be done as a new feature in CS4, but I didn't reveal what version I am current on, it could easily be assumed Im on CS4. Why would I not want to be up front about that?

Incidentally I have CS4 sitting in a file cabnet at work. Havent installed it yet. Been too busy compositing in Shake

Joey

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Aug 31, 2009 Aug 31, 2009

Copy link to clipboard

Copied

Joey - Yes, and I've been writing and using 3D and compositing software since 86.

We test those applications and file formats quite regularly.  We haven't seen anything like you reported.  Nobody else has reported any similar problems. And I don't know how you could have gotten the results you claim.

Adobe listens to customers, all the time.  We seek out knowledgeable users in every industry that uses Photoshop.  We learn about all of the industries, and we try to address their needs.  Some of us go out of our way to learn about customer workflows and needs, and spend nights and weekends working on features that we feel strongly about.

But you are ranting, and still making very little sense.

I'm sorry, but your posts are not helping.

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Beginner ,
Aug 31, 2009 Aug 31, 2009

Copy link to clipboard

Copied

But you are ranting, and still making very little sense.

I'm sorry, but your posts are not helping.

Ranting?....maybe...maybe not. But I'm making plenty of sense.

Since I have been unable so far to do a good enough job to  provide you an example which you can understand, I will try again with more detail.

For this example I will be using Softimage 7.5 and Photoshop CS3. Break out you copy of Softimage and follow along. Any recent version should do.

Open Softimage and create a sphere and set the material and color.

image1.jpg

Render the image out via Mental Ray as a standard Softimage PIC file. Then view the file in ImfDisp, a standalone provided by Softimage.


In order to benchmark that there is not something wrong with the ImfDisp viewer we will use Maya's fcheck.exe to view the same file.

image2.jpg

They are identical. And now we'll interrogate the alpha.

image3.jpg

Image is rendered fine, alpha is fine. Now we will bring the image into Photoshop CS3 using File/Open.

image4.jpg

Note the telltale sign that the image has been read by Photoshop, the alpha has been confiscated to create a Cutout. In other words a Layer with PS Transparency. That fact is evident by the checkerboard visible behind the sphere which means the opaque black background which previously existed has been replaced with transparent pixels.

Without making any changes to the image or any Photoshop settings, we will immediately save the file in the Softimage format using File/Save As.

The first obvious thing that should concern us is that the new image has a different size than the original, its only 2kb but we made no changes, it should theoretically be no different in size.

image5.jpg

Now we will view the Photoshop saved PIC file using both fcheck and imdisp.

image6.jpg

Both maya fcheck and the Softimage provided standalone display the image incorrectly. In fact both display it exactly the same, there is bad image data in the perimeter of the sphere's boundary.

Pretty weird huh? So whats going on here? Theres a lot of white pixels where they should be black. The image is not displayed correctly by two applications which should reliably display these images. So is it the image or the viewers?

We know the images are different, because the sizes are different, but size doesn't tell us much. In other words we could assume that Photoshop added some extra comment data or extraneous information. Just because the sizes are 2kb off is not a guarantee that Photosho did not write the image correctly.

The fcheck and imfdisp viewer results however, that showed us something is very different.

Softimage provides a good compliment of standalone tools that we can use to investigate this without being invasive. First tool we'll use is imf_diff.exe.
It will tell us if the two images are different. The second thing we'll do is use infopic.exe to gather more data about each image.

image7.jpg

So we see from imf_diff.exe that the images are very different. 86% of the image does not match the original. So from this we understand that the 2kb file size difference indeed is not a clear indication of how the file has been changed when in fact an enormous quantity of the file is different.

Infopic.exe however suggest something different. Infopic tells us some more about each image. We see that the new file is different and it provides us evidence that the file was actually written from Photoshop. There are some curious oddities but nothing too weird.

So what part of the image is different? On second look it looks like it is ok...maybe, but our eyes tell us different. We have another standalone that can tell us more. Its call diffpic.exe. Diffpic.exe shows us the following

image8.jpg


So where you see grey in diffpic is where the pixels are actually different. A subsequent test on the alpha(not shown here) declares there is no difference in the alpha that is saved. So we know from this that the white part of the image is the difference.

Since bringing this image back into Photoshop to interrogate it there will only cause us to lose the image data outside the alpha into the Transparency again, we can't rely on Photoshop to view and test actual image pixels and their relative colors because we won't be able to see them. Why? Because we can't control or limit the direction the alpha goes when opening the image in Photoshop. It gets used in a way we don't want it to be used. So Photoshop is useless for further interrogation here.

We'll need to bring the image into Softimage FXTree instead.

image9.jpg

From FX Tree I will see that the white is actual pixel data, reflected as RGB 1.0,1.0,1.0. The alpha is still intact and unchanged but the image has been altered in a serious way. Incidentally you can't see the cursor position with the screen grab and the file name in FX Tree is truncated at the first period in the name, so you are seeing the Photoshop saved file.

Whats not clear is whether the Photoshop Softimage reader/writer is at fault or if Photoshop Transparency Layers is the fault. If I do this same exercise in Maya, I get similar results with Maya IFF files.

So whatever is the cause is more complex than just a bad importer. In general I am using the same importers delivered with the CS3 install. Here are the details on the Softimage extension.

image10.jpg
So the files behave most of the time, but only if you are using the alpha as a mask. You are left with the serious question mark, can I trust these files?

What this reveals is that you can't bring the PIC file into Photoshop and edit the image bitmap and expect to keep the change if the change is not within the apha's perimeter. Thats a problem because not all images with alphas are used with their alphas.

This unwanted alteration to these images has been ongoing for years. Its not new. I suspect that what is going on here is that Photoshop is doing this to the image when it gets sucked into a PS Layer. My educated guess is that the layer is figured not to need the data (represented as white by diffpic, but which was once black) anymore since the Photoshop wisdom is that only what is inside the alpha and summarily becomes the Cutout is what is important. Therefore it is assumed incorrectly that the data is not needed and somebody decided to toss the extra "unneeded" image data regardless what the users think about that. Probably as a file size reduction effort. But i don't know that for sure, its just a guess.

But it should NOT be happening. The file bitmap data saved out should be adsolutely identical to the original.

I've included the source files with this post. If you don't get the same results with them I will be very surpised.

So please tell me why this is happening.

Joey Ponthieux

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Sep 01, 2009 Sep 01, 2009

Copy link to clipboard

Copied

What that tells us: you still don't understand alpha channels and transparency, or what 100% transparent means.

And I don't think you fully appreciate that Photoshop does not work with premultiplied color (we have to convert it to straight color for editing).

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines