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.
253
Replies
it could be much worse. When I was in print we learned how to do
AdChoices