Explore related tutorials & articles
253
Replies
Joey - again, you are just repeating that you really, really don't know what is going on.
Chris,
You’re right I still don’t know what Photoshop is doing to damage my PIC file. I’m still waiting for you to tell me why this is acceptable.
Photoshop really is a WYSIWYG editor.
To a point, yes Photoshop fits within the WYSIWYG principle. The vast majority of graphics apps do today. But many have evolved beyond WYSIWYG in some ways, or provide features which don’t adhere to WYSIWYG at all. Photoshop is one such application.
Back in 1984, I sat at the first computer I ever worked on. It was a Compugraphics 7770 II Typesetter. It was a massive beast of equipment by today’s standards which contained a photodrum that had a font screen affixed to it. Light was shuttered through the drum mounted font screen which rotated at high speed thus exposing type onto photopaper which was then photo-developed. The machine had a keyboard and monochrome single-character-height monitor. You entered every command to lay out your design, such as justification, type size, position, angle, line spacing, etc etc etc as long text string commands. You could not see what your final product looked like until you executed your script, exposed the photopaper, and developed it.
That process was not WYSIWYG because you could not see what you got. And if you got something you didn't want it was an expensive proposition. You had to be able to imagine what your layout looked like, because you could not see it. People who could reliably operate this machine were among the highest paid in offset lithography back in the day.
WYSIWYG, or "What You See Is What You Get", was the software development philosophy that evolved during that period to remedy this "imagine the product" problem. First with large turnkey or proprietary systems that accomplished WYSIWYG word processing or graphics production then with software dependent on the new and evolving PC and MAC platforms.
WYSIWYG means that what you "See" on your screen is what you will "Get" on output to printed paper, film, videotape whatever. The "See" and the "Get" had to be the same to be considered WYSIWYG.
WYSIWYG does not mean “the way I see it on the screen” or “what I see on the screen is what I get on the screen”. That would be redundant. The virtual display must match a tangible physical product outside the computer to be WYSIWYG.
But Photoshop displays things which can't be reproduced correctly upon output and it hides image data and does not provide a solution around this problem. Therefore this, at least for the Transparency Layers or Cutouts, declassifies it as true WYSIWYG. Because it will print or output something different than what is actually seen on the display.
So, we'll go back to my images to prove that point.
This is what I rendered from Softimage.
The image here is WYSIWYG, if I print it to a color printer it will look like what you see here.
Notice the black in the image RGB behind the red ball. I know it is black because I can see it and I can physically measure it. I knew that before I viewed this filed because I rendered it that way out of Softimage.
The file also has an alpha channel
But in this case I don't need it and have no plans to use the alpha.
I do plan to use the RGB image data in Photoshop to make a new image.
An example where this might be useful is if am making a texture map where I am building the base image from a rendered 3d model or models, but then I plan to bring the base image into a paint software then edit it or paint on it. I then plan to make a custom alpha or mask from luminance or color values of the new custom image, or hand paint the new alpha if that suites me. Rust, rivets, accent textures, logos, that kind of thing are good examples where this comes in handy. I want to construct my own alpha because I will use the new alpha in my 3D software to apply the texture on yet another model.
Therefore the original alpha in this case has no meaning to me even though one exists from the original render. The black background from the RGB has meaning to me and I wish to keep it.
The base color is my starting point for the texture.
I do know what it is in my file.
So I bring the Softimage PIC image into Photoshop
The image is immediately converted into a cutout.
The image is not WYSIWYG. But more on that in a second.
Photoshop isn't hiding things, or deleting them - just showing you what is in the file.
No sir. You're wrong. My black background is gone now, some of it hidden and some of it removed by the alpha-to-transparency conversion which creates this cutout layer.
I can only see the content Adobe wishes to show me here. Photoshop is not showing me what is actually in the file. I know that because I know what is in the file. Instead Photoshop only displays the RGB which corresponds 1:1 to the positive alpha.
In many cases I would like to access and use my alpha independently. Either use the alpha as a mask, paint on the alpha separate the image, boolean it with another alpha, move the alpha to another image, or do other things with the alpha. This is not one of those cases.
In this case I want to explicitly and intentionally ignore the alpha. Photoshop did not let me ignore it. I cannot make the black RGB pixels that I want to see visible on the screen without a 20-30 step process inside Photoshop(see post #179) or some other unorthodox processing of the image outside of Photoshop. In either case Photoshop does not provide a reasonable, easy, or acceptable solution to this problem within Photoshop.
Compositing it over a new layer with black fill at this point is not the same thing. I am interested in working only with the actual image. Why? Because it is my image and that is what I want to do. Besides I should not have to rebuild my black background, which is ironically already there and already black, every time I want to load the PIC file into Photoshop. If I had an unusual background color such as blue or chroma key green or whatever, I have to go through extra steps to make sure I build the correct color. This is a poor workflow and not a solution to the problem. No artist should be required to recreate something which is already there.
So the black is hidden in the transparency and Photoshop deleted some stuff in the image, we’ll get to the deleted stuff in just a second. These things aside, now both the image and Photoshop are no longer WYSIWYG for the moment. It fails the WYSIWYG test because if I print it here it does not print the virtual checkerboard, it “prints“ white instead of transparency.
Why, because you can't print transparency, transparency is a virtual concept, it doesn't really exist. The closest analogy in the real world is air, and we don't print air or print on air.
Some folks might think an accurate analogy would be to print on transparent acetate. But that is not accurate, because in WYSIWYG printing white is really absence of color, or the paper. That is why you can't typically print white to overhead transparent acetate unless you have some kind of steroidal digital printer than can print opaque white.
Normally only saturated color can be reproduced in common digital printing, white is dependent on the paper to exist. Transparency is not white therefore cannot be the same, therefore transparency cannot be WYSIWYG because it cannot be accurately reproduced as output. You cannot “GET” transparency as illustrated by Photoshop. Instead it will print as if it were assumed White.
For example, if I had a Photoshop layer containing a flat 100% white circle over a transparent background, the circle is visible to me in Photoshop and I can actually SEE it over the checkerboard, but when printed to acetate or paper Photoshop will print nothing. Because Photoshop's concept of virtual transparency exceeds the principle of WYSIWYG, therefore bringing it out of compliance with WYSIWYG, because I can never "GET" a printed version of the white circle that I can "SEE" by printing on clear acetate, or anything else for that matter.
In essence I am being allowed to see something I shouldn’t be able to, because Photoshop presents the white circle cutout over a faux checkerboard that does not really exist. The checkerboard is a helper, there to allow you to see things and recognize them as transparency if the object exists with transparency. Photoshop can't print this white circle over checkerboard to output, so it is not WYSIWYG.
However, if I had been looking at a white circle on a white background I would not be able to SEE the circle of course because both are white. For example, how many white text objects have you lost in a Photoshop or Illustrator document? We all have. If I attempt to print that white circle on white background to white paper I get on paper exactly what I see on screen, nothing but white, or nothing but blank paper. This is compliant with WYSIWYG. Because it printed exactly what I SEE.
So lets review what you wrote in post #217 of this thread
Chris Cox wrote:
Many other editors don't show you transparency directly - they show color in one place and a transparency mask in another (imagine if you will...), or show you lots of components and have a final pass to render the composite (non-realtime, imagine if you will...).
So from this explanation we can only assume that your perception of WYSIWYG is the opposite of what you define “Imagine If You Will” to be. You define “Imagine If You Will” as a situation where the Image RGB and Alpha are displayed separately and the individual has to imagine these separate RGB and Alpha elements together so that only the alpha relative RGB pixels are considered for use.
This presumption suggests that you think it is either wrong, not optimal, or at least not WYSIWYG, to have RGB and Alpha displayed separately. It further suggests that you think the proper way to perceive, display, and view a RGB image with Alpha is with the RGB & A unified and the A driving the visibility(opacity) of the relative RGB pixels.
Therefore the only conclusion that can be arrived at, about the view you define here, is that you think the sum of the RGB and Alpha unification(composite) which results in transparency as a permanent part of the image’s default display, is WYSIWYG.
Or in simple terms, you believe WYSIWYG to mean that we should SEE displayed to screen the compositing result of the unified RGB and Alpha that should GET an image layer with Transparency.
Or in even simpler terms, what you SEE on screen is what Adobe wants you to GET on screen.
Or in simplest terms, what you SEE on screen is what you to GET on screen.
This conclusion is supported by your statement from the same post
Chris Cox wrote:
Photoshop is a WYSIWYG editor -- you always see the image as it is, with the final composite (modulo the accuracy of downsampling for zooming), color corrected for your display.
The fact that the default loading behavior in Photoshop is to combine the RGB and Alpha to generate a Cutout, or image with Transparency, so that it floats over other images by default, also supports this conclusion.
But that is not what WYSIWYG means, WYSIWYG means that what you see on screen is what you get outside the application in the real world.
What is on the Display cannot be the Get, because the Display is the See. Otherwise it would be What You See Is What You See. Again, that would be redundant.
In Shake or Flame or Nuke or “fill in the blank” when we load an image we get to see the image for what it really is. We see the RGB channel complete with the black background intact. If we output this image to D1 tape, or DVCam, or even film, you will see on those output mediums exactly what you see in the compositor or the display. The red ball over black. That is WYSIWYG in its true sense.
The alpha was an accessory provided to us to use as an accessory, when we choose to use it, if we choose to use it, not when Adobe wants us to use it. Does the alpha reflect Transparency, sure it does, but only if we explicitly want the red ball to be composited over something else with the use of an Over node or some other explicit compositing tool that uses the Alpha.
In fact we don’t even have to use the Alpha to accomplish this. We could perform a luminance key, chroma key, math composite, or use any number of keying or compositing utilities at a our disposal to achieve the composite we want. Again, its about what we, the animators and compositors, want to do or not do with our image and alpha.
Further, you said in your last reply
you always see the image as it is, with the final composite
No we don’t. We want to see the source image and how it actually appears. We don’t want to see the source image composited with its alpha the way Photoshop thinks we should. The appearance of it is that you see both RGB and A as one and the same image. We don’t want this behavior in most cases and rarely ever will as a matter of default image interrogation.
We rarely choose to open the file as a cutout unless of course it is our choice and prerogative to do so at that moment and it is useful for the project at hand. IE printing project as opposed to video or film animation. We want to see the source image as our default input, not the cutout. We want to see the RGB and the A on load. Not the composite.
Now, just for argument sake I will momentarily accept this view of WYSIWYG, that we SEE on screen the product that the program let’s us GET on Screen, as being WYSIWYG. But I can’t get the image the way I want to see it. I can’t see my image the way I know it actually is, because I can only see it the way the programmer permitted the software to present it to me. As a red ball with transparency floating over a faux checkerboard background.
So I must “Imagine If You Will” that my black color behind my red ball is still there. I can’t SEE it, I must imagine it. Recall that your premise regarding “Imagine If You Will” was that you believe the image should be seen one way and that in Shake or Nuke or whatever you have to “Imagine If You Will” the image as a cutout because it does not display it there as a cutout by default. This is your preference for how you want to see the image with its alpha. However, it is our preference to see all of the image, so we have to “Imagine If You Will” that our black is still there when the image is read into Photoshop.
So I don’t SEE what I wanted to GET and I have to “Imagine If You Will” that my black is still there.. Its not WYSIWYG then, because the image I can SEE outside of Photoshop I can’t SEE inside Photoshop, or even GET inside Photoshop, and I have to imagine the image the way it really is. Photoshop converts my image, without my permission, into something I did not want, and displays it differently than I want.
Finally, even after assuming this perception of WYSIWYG is correct, that what you SEE on screen is what you GET on screen, then by that definition back in 84 when I was typing on that Compugraphic 7770 II, it was also WYSIWYG. Because I saw on screen what I got on screen. “new paragraph, left justify, font size=12pt, copy=’put text here’, quad left, carriage return”(or something to that effect).
Therefore, regardless the definition of WYSIWYG you assume, the conclusion ultimately is that an image with alpha loaded into Photoshop and displayed as a Transparency layer is not true WYSIWYG.
So back to the image.
>Photoshop isn't hiding things, or deleting them - just showing you what is in the file.
About that hiding and deleting thing. You do not show me what is actually in the file, you only show me the cutout representation you want me to see. I can't see the black background anymore, and some of it is gone. Remember, you optimized the file by removing part of the image within the transparency that you consider unnecessary. You apparently do that in order to optimize Photoshop performance, but that is only a guess..
This is what was “optimized”......
The gray field is what was removed or altered in the file.
Whether you are actually deleting that data or just changing the color data to a known value such as white, or some kind of null data, I don't know. Regardless, the result is that you delete the image data I had, which I wanted to keep. So again, you are not showing me what was in MY file. Photoshop has unacceptably altered my file.
I will remind you, you wrote in post #203 of this thread
Chris Cox wrote:
Photoshop may change some color values on some file formats when opening -- because the color values have no meaning in 100% transparent areas. Again, Photoshop is straight color, not premultiplied color -- this is an important concept. If Photoshop were limited to premultiplied color, it could not do most of the editing it does (or the editing would be much, much slower and more prone to adding artifacts).
Did you forget that you admitted that Photoshop changed color values on some file formats because the color has no meaning? No meaning to who? How does Adobe justify deciding what part of my image has no meaning when you've never seen it and don't know what I intend to do with it? Worst, how do you justify now telling me that….
Photoshop isn't hiding things, or deleting them - just showing you what is in the file.
…when you admitted previously that you do change things. If you change my black to white, you deleted my black.
My black had meaning in the areas Photoshop erroneously thought are supposed to be transparent. Photoshop removed/changed/deleted the black that was in my file that I wanted to keep. This assumption that I don’t need the black behind the red ball was and is wrong.
We go well out of our way to avoid doing harm.
Not according to this you don't. If I immediately save the file back to a Softimage PIC file, this is what Photoshop creates...
Its been doing this for years. Not days or months, but for years. This is not new. I get the same result from Photoshop CS as I get from Photoshop CS3. Did you not test this output with Softimage's file readers? It does the same exact thing with my Maya IFF files too. Did you not test the IFF file output with Maya fcheck?
But we also offer some tools that allow you to do harm if you don't know what you're doing.
All I did was open the file as-is and save it to Softimage PIC. Are you saying I don't know how to open a file and immediately save it? I did not edit or paint the image in any way. I couldn’t, because Photoshop screwed the file up by erroneously assuming I wanted a cutout. I didn't want a big white ..."thing"....surrounding my red ball over black. Photoshop did that. It harmed my image.
Adobe needs to fix this.
And If you don't understand transparency, or premultiplied color, or what various file formats require - you can create your own problems.
I know what I require. I need an image editing software that I can open and edit the file the way I need to and want to. Not the way you want me to. I want to edit the RGB independently or the Alpha independently, or both simultaneously. Your way currently quarantines my alpha, restricts me from editing the part of the image I want to edit, converts the image into a cutout which I don’t want(because I’m not going to composite the red ball over anything), and damages my image on save.
How are you doing to sort it out when you obviously don't know what is going on with your own pixels?
I just illustrated for you in visual detail that I know exactly what is going on with my pixels. I have a red ball over a black background which was rendered from Softimage with premultiplication on. I wish to paint on the RGB and I have an alpha which I choose not to use. Photoshop will not allow me to edit it the way I want, or even preserve this image from undue harm.
Why is it that you didn't know that the Photoshop harms PIC and IFF images that it saves? Or ....did you know that?
There are laws and rules that kinda frown on me making those things public.
Yet you engage in accusations against these companies and their products anyway? Knowing that you are using the blanket "them" to bypass being specific? Now they "all" know what you think of “them”. Why say anything at all against them if you can't be specific?
I'll keep filing bugs directly with the companies, thank you. (and anyone in the industry should already know who I'm referring to)
Good. They need to be kept on their toes. And they should file bug reports with you regarding their problems with Photoshop too.
Premultiplied color has to be converted to composite or display correctly.
Converted or processed? Converted suggests a permanent change to the data itself. Is it destructive? Is Photoshop changing the premultiplication on load? Does it convert it back to normal premult when saving? If not, then this would be unacceptable.
I can convert my PIC file to an IFF file. That is permanent.
If I process my PIC file in Shake, every step or node along the way the node processing changes the image instance a little bit, but the source data is unchanged throughout the entire tree so it is completely non-destructive. In other words I can replace any node in the tree with a new node or even delete nodes and never have to reload the file and still never use undo to get the image back to its original state. Can Photoshop say that?
All compositing software has to process premult images to composite them correctly. Shake uses an Over node, XSI FXTree uses a Premult type switch to process the data correctly in its Over node. The majority of applications can do this, Photoshop can't.
Image data needs to be color corrected for the display - otherwise you can't get an accurate idea of the color in the document.
At what level? Is the data being changed or is the image display being sent to the raster being changed. Just like zooming, display corrections should only be at the raster level, not actual changes to the file data if the user does not want that.
16 and 32 bit/channel data does need to be converted down to the display precision (usually 8 bit/channel).
Again, is that happening at the raster level or the data level? These things should not impact my data source, that should always be the same. Raster correction handled at the graphics card or display is one thing, everyone expects that, but none of the data within the typical CGI formats should be altered at the simple opening of the file if the user does not want that. And when returned to disk on save, it should be exactly like the original. No changes or conversions should occur unless I initiate the change, am aware of the change, and approve of the change.
But some applications ignore all that and try to throw bits to the screen as-is. It's certainly easier to ignore it, but that makes the application a lot less useful.
Ignore what? You assume too much here. The artist takes his images and tests them against a waveform and vectorscope for legal range, ire and color. In the process of sending the image to videotape its practically impossible to cross that void and have RGB colors match NTSC color. If you are lucky your display correction may assist you in simplifying your output to print, but the only way to produce accurate color output to NTSC is to test against waveform/vector and several live qualified NTSC monitor outputs with color bars.
All the color standardization, processing and converting you attempt to embed into the process is overkill in the video production environment because the setting of the encoders, transcoders, and decoders in any transfer to videotape in any two studios are all different and only as good as that facility's equipment, its age and condition, and it's engineer.
The point is that all this color management your tallking about, while useful for print, especially if you are all digital and all your equipment can reference against a standardized color profile, has little to no benefit for me. Animators are outputting to tape or film and we rarely ever using Photoshop as the output to video. If we can bring these images into Photoshop and edit them like we want, they will end up being resent through our formal sequence compositor such as Shake or FXTree or Flame where color, gamma, or videosafe corrections for the entire animation will then be applied.
Processing 1, 3 ,5, or 10 images into Photoshop out of a 3000 frame sequence rendered in Softimage, opened and processed As-Is through Photoshop, and then processed through Shake insures that I don’t have 1,3,5, or 10 images that don’t match the other 3000. Because then the only changes were the ones I implemented, not the ones Photoshop erroneously thinks I need. I should not be required to laboriously process 3000 images through Photoshop to maintain color correction for the whole sequence when all I did was paint out render bugs on 10 images. As-Is processing is better in this situation.
Why else is As-Is important? Because the image I begin with has no custom color profile. My video equipment can’t reference against your color profiles. Its easier for me to process everything As-Is because then I know what Red 200,018,026 looks like in Softimage, in Shake, on MY waveform/vector and NTSC monitor. If you change that in Photoshop then Red 200,018,026 looks differently in Photoshop than it does in Softimage or Shake. And they all look different than my NTSC monitor anyway.
Sometimes images I edit start as photos or renders, go through Photoshop and end up as textures which get re-rendered again, before they go to Shake and Final Cut or Softimage DS or Flame and then to D1, DV or Digital Beta tape. Photoshop in this case is so far at the beginning of the process its color management provides me little benefit. If I create a NASA logo from an EPS file with predetermined PMS colors, I may end up putting it on the side of an aircraft and the logo ends up all of 10 pixels tall on the screen. My color management is more critical for the final rendered image, not the texture. I don't always need the precision you assume I require. After all I am creating art, it can ultimately be any color I want it to be.
Don't get me wrong, this color management is extremely critical for some people and is very important, but not at every level of production or for every workflow or industry. Sometimes it boils down to just needing it to look like I want it to look. Remember that NASA logo with PMS colors, its not going to look right when rendered in NTSC video if I make no changes to it regardless how much Photoshop color correction or color profile dependency I use. Why? Because from PMS to RGB to NTSC, it changed. I can't stop that, no one can. I’ll have to change the logo colors anyway to make it look like it is supposed to look in NTSC.
So, there are cases like the ones I’ve just described when As-Is is better for the user. I think you falsely assume that the level of color management you describe is a one size fits all that helps in every situation. When in fact, in some cases it seriously gets in the way. Unless I am creating a print product, I always load images using the As-Is(do not color manage) option and will continue to do so indefinitely.
And again, you're making a lot of incorrect assumptions and accusations - apparently because you have no idea what you're talking about.
I'm not making any accusations I have not been able to back up with concrete example. Until you can prove to me that the example I set forth in this post is wrong, that Photoshop did not damage my PIC file by simply opening and saving it, don't tell me I have no idea what I am talking about.
The only thing you're doing here is convincing us that the CG industry relies on luck to get anything done,
Actually the CG industry doesn't rely on luck so much. Video broadcasting...that’s a different story.....it has relied on luck for over 60 years. Ever try to color correct the TBC on a pneumatic 2 inch videotape machine? There is a reason why NTSC is jokingly referred to as “Never The Same Color”.
because you know bugger all about the tools and techniques you use.
So tell me again why Photoshop can't support premultiplication?
Once again, you really are not helping this discussion.
On Nov 18, 2008 Progress began this thread with the following comment
Progress wrote:
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?
What I have contributed here illustrates clearly the problem Progress was complaining about if only in a different context. I have further illustrated the same exact problem is present in PIC and IFF files with more damaging results than EXR. My effort has been to keep this thread focused on the fact that automatically converting images to cutouts without the users specific permission is a serious workflow problem which produces far more problems than the mere convenience Adobe thinks it offers, the perception that its the only way to do it, or the perceived notion of adherence to some specification. My contribution fits clearly and directly within the scope and spirit of the original post.
If I’m not helping.... it’s because I’ve illustrated aptly that the problem is much bigger and more complex than what Progress originally complained about. It will require far more effort and thought to fix it right than a simple band-aid to allow users to see and edit the transparency that should not be there in the first place.
Joey Ponthieux
showing you the transparency specified by the file *as transparency*, and always showing you the composited final image.
Is it wrong to see, edit, and use an image not composited, or without its Alpha?
What if I did not want to composite the image I just loaded? Should I not be allowed to do that ever?
"Alpha" in Photoshop follows the more common usage of "alpha channel": any additional channel beyond the color channels (of which transparency is a subset). That has been the common definition since at least the mid 80s.
I understand that some developers have your alpha channel or alpha "container" view. That all channels after RG&B are Alpha Channels or arbitrary containers. I know a developer that holds this view and has the same view that these channels are arbitrary that you do. Thats aproppriate from a developer's or engineer's point of view but to artists "Alpha" means the content in the channel, not the channel container itself. So to us it has the same meaning that it has always had for the last 3 decades, that the term Alpha is synonomous with transparency, opacity, or mask. We are prone to referring to Alpha as Alpha Channel because most, but not all, of the images we use only contain one Alpha Channel and include the Alpha inside that Channel. To us Red Channel, Blue Channel, Green Channel and Alpha Channel is the same as Red, Blue, Green or Alpha data.
"Premultiplied Alpha" is an industry accepted term. When we refer to the term "Premultiplied Alpha" we mean the content in the channel that is the transparency data. Alpha and transparency is the same thing to us. Why would we say "Premultiplied Alpha" if it was not acceptable? If we deconstruct "Premultiplied Alpha" then "Premultiplied" defines the nature of the content in the channel, and "Alpha" defines the content. We don't often say "Premultiplied Channel", or "Premultiplied Channel 3", or "Premultiplied Alpha 0", or whatever. Its called "Premultiplied Alpha" because the term Alpha means and is recognized as the content within Alpha Channel 0 of the image. The Alpha, or the content in the Channel, is what is premultiplied. Therefore "Premultiplied Alpha" addresses directly the premultiplied transparency data in the channel. The industry may conclude therfeore that Alpha directly means Transparency, and Transparency directly means Alpha.
Since it is acceptable for Red Channel to mean Red, Blue Channel to mean Blue and Green Channel to mean Green, since Red won't go in the Green channel for example, it is then acceptable for Alpha Channel to mean Alpha, or Transparency.
Henceforth I will continue to refer to Transparency as Alpha, but to not confuse the issue I am happy to refer to it as Alpha 0 so that you have a clear understanding that I am referring to transparency/opacity/mask data in the first and most often only Alpha Channel of the image file.
Will that be sufficient?
You aren't being discounted.
No I'm not. We all are. You said and I quote
The only thing you're doing here is convincing us that the CG industry relies on luck to get anything done, because you know bugger all about the tools and techniques you use.
How am I not supposed to view my industry and myself as not being discounted with belittling comments like this pointed at me and others.? You made the accusation, now please prove that I don't know what I am taking about.
Right now you're damaging your own reputation with your claims and rants.
No I am not ranting, I am trying to have a discussion with you. If I were ranting I'd be flaming both you and Photoshop. I'm not interested in doing that.
I'm further being forced to defend myself from your accusations that I know bugger. As for my reputation, its just fine thank you. As is the reputation of everyone else in this industry who commented on the thread prior to me posting here.
Stop, take some time to learn more about the topic, then maybe you can engage in a more useful discussion.
I've learned quite a lot from this discussion. But I knew bugger enough to illustrate that Photoshop does this to my image
I also knew bugger enough to deduce that it was probably the result of Photoshop optimizing the file. I'm sure a lot of other users did not know that was happening.
I also know bugger enough to realize that you have avoided answering if you think this kind of problem is acceptable.
Hint: The response "No it is not acceptable. We'll have someone look into it. Thanks for reporting this." would be a very welcomed response.
But, of course, it is not required......
Joey
But it's not a bug.
But I did not ask if it was a bug.
I asked if it was acceptable for Photoshop to turn this
into this
Is this level of image corruption, by simply opening the file into Photoshop and then saving the file out of Photoshop, an acceptable product for Adobe to provide its users?.
Joey
But it's not a bug. It's just what happens when you take a premultiplied image into a non-premultiplied world and have to deal with colors under the transparency values of zero.
Ya know, for a second there I almost missed the relevance of this comment. You're saying now that this is a circumstance of bringing a premultiplied image into non-premultiplied workspace? I thought for second,.... maybe. Then thinking about all the tests I've run on this in the past, the fact EXR images didn't generate these mangled images on output while PIC and IFF do for example....
I thought no....this doesn't seem right.
Thinking back I realized I had tested non-premult images into photoshop but never out of photoshop. So I had to be sure and I ran another expriment.
I created a new XSI scene this time with a white ball instead of a red one.
I render it out as PIC with "Premultiply with Alpha" turned off in Softimage.
This is what I get
If you zoom into the edge of this image you will see the telltale signs of it being non-premultiplied.
So I bring the image into Photoshop
If we zoom into the top right corner we see no ring around the collar
Premultiplied. Ready and roaring for Photoshop primetime.
But what if we save it?
So we save it immediately out of photoshop......
and this is what we get
Nope. No joy here. Same as the premultiplied image.
Non premultiplied PIC image in non-premultiplied Photoshop space and no black ring
but the file is still trashed.
So I thought about what you had said
Chris Cox wrote:
But it's not a bug. It's just what happens when you take a premultiplied image into a non-premultiplied world and have to deal with colors under the transparency values of zero.
And then what you said back in post #203
You said
Chris Cox wrote:
Photoshop may change some color values on some file formats when opening -- because the color values have no meaning in 100% transparent areas. Again, Photoshop is straight color, not premultiplied color -- this is an important concept. If Photoshop were limited to premultiplied color, it could not do most of the editing it does (or the editing would be much, much slower and more prone to adding artifacts).
Here you said that the some color values are changed by Photoshop on open because they have no meaning in 100% trasnparency.
One can only deduce that any color, typically black located 1:1 with 100% trasnparency is changed, on purpose.
And one can further deduce that since you say it has no meaning, therfore you think it is unneccessary and eligible to be discared.
But if the image is non-premultiplied to begin with, why would it need to be changed at all? Which the above illustration shows that it is being changed regardless what it really is, premult or non premult.
It further made me wonder if it is so absolutely required and important that the color corresponding to 100% transparency be changed to white or null, then why isn't this being changed
Why don't these regions have to be white? Won't they interfere with the non-premultiplied space?
But what color are they really? I can't interrogate this jpg, its compressed and will lie to us. I can't interrogate the image further in Photoshop it will only compound the problem. So I bring it into Softimage FXTree
Its black 0, 0, 0 just like in the original image.
So why doesn't this black need to be removed?
WHy isn't it important to change this color when it is with everything else is?
But what was changed, the white around the ball, surrounds a near perfect square geometry. Not jagged areas, but the square bounding perimeter of the ball.
What impact does this exterior white area have? Especially since it is rarely adjacent the edge perimeter which is what is most reliant on being non-premultiplied?
That little pixel, its Black0,0,0
Only two white pxels on this side even touch the edge of the ball. Since it is non premult, the exterior pixels will likely end up near 0% percent opacity anyay.
So why is it necessary, as you claim, to get rid of some of the external 100% transparent RGB pixels? But not all?
In other words, the logic is like this. If the pixels adjacent to the ball's edge can be Black0,0,0, and they would matter most in optimizing the non-premult comp, and they were originally Black0,0,0 anyway, why do the pixels farthest from the ball have to be changed and not those closet the ball?
Sorry to borrow the phrase, but that doesn't make any sense.
But then I recalled that you said
Chris Cox wrote:
If Photoshop were limited to premultiplied color, it could not do most of the editing it does (or the editing would be much, much slower and more prone to adding artifacts).
Which is why I assumed that the pixels that are now white were actually turned into null pixels, but written as white on the save(IE Assumed background color is typically always white in Photoshop. Transparency is "assumed white" on print) because Photoshop can't put the colors back anymore. If it discarded the pixels to optimize the file there would be no reference to what they really are anymore, because if they had been saved, they wouldn't be discarded. Then it would be really easy to put them back. That was the guess anyway.
So what is really going on here?
The image opened in Photoshop was not premultiplied.
There are some colors under 100% transparency that are preserved and some under 100% transparency that were thrown away.
You said some colors are being changed if they have no meaning in 100% trasnparency
and my image still looks like this
So, are pixels being thrown away in this image?
Which ones if they are?
Why aren't all colors corresponding 100% tranparency changed?
And why did the saved non-premult image produce the same result as the saved pre-mult image?
Joey
Oh yes, and does "100% transparent" also mean the same pixels as you define by saying "transparency values of zero". You described 100% transparency as being the color pixels that were thrown away(that could only mean the pixels not comprising the ball) but you also descibe colors UNDER transparency values of 0. Colors under would insunuate that the colors are hidden, since colors over would be assumed visible. Though transparency value of zero could also imply 0% transparency or opaque. Can you please clarify this? Or is "transparency value of zero" another way of saying 0,0,0?
AdChoices