We’re using Targa images for games work and need precise control over alpha levels.
In Photoshop 7, it seems that grey levels in the alpha channel are transferred directly to that Targa. For example, a grey level of 50% in the alpha channel produces an alpha value of 128 in the Targa file, as you would expect.
In Photoshop CS3, I’m getting 105 for 50% grey. And in order to get 128 I have to set my Photoshop colour to #959595.
This is a serious incompatibility for us. We can no longer generate correct alpha using Photoshop gradients. Also, some of us are using 7 and some CS3, and we need automation to work! There seems to be some sort of curve being applied to the alpha.
Firstly, does anyone else see this? I’m beginning to doubt my sanity.
Is there a way to fix it? When I say 128 I want 128!
(I’ve searched the forums and knowledgebase for "targa alpha" and Google for "photoshop targa alpha" and turned up nothing relevant.)
Learn how to rescue details, remove flyaways, add volume, and enhance the definition of hair in any photo. We break down every tool and technique in Photoshop to get picture-perfect hair, every time.
While not a direct response to your concern, I highly recommend that you upgrade all Photoshop 7 users to CS3. Not only is it older software with lesser capabilities that may behave differently, but it is also your last chance to move to CS3 at an upgrade price.
Richard, I don’t use Targa much, but I do use PNG for realtime projects.
I’ve never had a critical need to control alpha channel gamma, but my first thought is that may be getting caught up in some sort of color management that is not appropriate for your workflow.
How do you have color management set up? Do ht Ps 7 machines and the cS3 machines use the same color management set-up?
Are you creating your alphas as channels, or are you creating them as layers then somehow transferring them to channels?
Neil, I appreciate your advice, but in this case it’s PS7 that is behaving as we want, and CS3 that’s been changed to throw away information. With CS3 it’s impossible to get certain alpha values because it’s applying some sort of curve to the alpha channel when it saves it. This is undocumented. If PS7 worked under Mac OS X Leopard I’d be back there in a heartbeat. CS3 has added no new useful functionality for us, only bloat and cost so far.
Jean, I suspected colour management. It’s switched off ("Don’t colour manage this document") on all files concerned. But I also tried switching it around and it had no effect on what happened to the Targa’s alpha channels as far as I could tell. We need to create special alpha on hundreds of files, using Photoshop gradients and layers with vector masks. Therefore we create a Photoshop file with layers which builds the necessary grey-level image, then use "Copy Merged" to paste the result into the alpha channel of the Targa. However, this doesn’t really matter — you can inspect the result and check that pixels report 50% grey in Photoshop but aren’t 50% alpha when saved.
When Adobe changed how the Alpha channels were handled in Targa files they didn’t bother to notice how the files were actually being used in the real world. Everyone bitched about it and their initial response was that the original Targa behavior was wrong. Thankfully, they relented and posted a Targa "fix" which restored the original alpha channel functionalitiy. You should still be able to download that from the Adobe site. Sorry that I don’t have a link for that at the moment.
I thought the Targa fix was for wether the alpha information was recorded in a separate channel, or actually knocked out of the RGB channels. Peter, did it also address gray levels of the alpha?
Richard, when I get today’s deadlines met, I’ll test this a bit. Photoshop handles PNG images in a way that makes them unusable for my 3d work, so I use fireworks instead. But Fireworks does not write Targa…
Jim, Peter, thanks for your replies. In 7.0 Adobe changed the Targa export to use Photoshop’s own transparency as the Targa’s alpha channel. This would actually be quite a useful option to have, and is how PNGs are saved, so I can see why. But then they realised they’d messed up compatibility and changed it back in 7.0.1. We know about it and we’re using 7.0.1. I don’t believe it’s relevant to my current problem. I just wish they’d kept both behaviours as an option on save. It would’ve been handy.
no, I don’t see this. I made a grayscale image with a broad swath of 128, 128, 128 (808080, or 50% B ) on a layer, copied it and pasted it into a new alpha, saved as TGA, and closed.
Upon reopening, the values were the same in the alpha as in the original color layer.
Rather than disabling (or attempting to disable) color management, I have color management fully enabled, and am using sRGB all the way through.
Jean, thanks for trying this. When you say "on re-opening" do you mean that you reloaded the TGA into Photoshop? If so, you will see the same values. The problem is that the 50% gray (128, 128, 128) isn’t being encoded as 128 in the file itself, so that other tools don’t see the same values. Here is a hex dump of a 1 pixel by 1 pixel TGA image with white in the colour channels and 50% grey in the alpha, as created by my CS3:
On the second line you’ll see "ff ff ff 69". The "ff" are 255 in the R, G, B channels, and the "69" is 105 in the alpha channel, not 128. This messes up our toolchain!
However, I’m now pretty convinced it’s a problem with the colour management. Photoshop 7 (the _best_ Photoshop) had a useful setting called "Color Management Off". CS3 has no such setting. The help talks about "color managed workflows" but doesn’t really give any help for making sure your workflow _isn’t_ colour managed.
Does anyone know how to ensure that CS3 does _not_ re-interpret the colours encoded in files, but instead shows me the _exact_ RGB values encoded?
I think it is the gray gamma value that is tripping you up. When I enter a custom gray gamma of about 2.23 or 2.24 for gray gamma in Color Settings, I start to get the correct value for 128 gray. I don’t know of any way to actually fully disable color management in Photoshop.
Well, I’ve found a workaround. In "Color Settings" set your RGB working space to "Monitor RGB". Reading the description below, it says "this setting causes Photoshop to behave as if color management were turned off". This appears to make the colour values shown by Photoshop match those saved in the Targa, _including_ the grey levels in the alpha channel. We can work with this.
Now the questions is whether this is a bug. I might want my colour channels colour managed, but I can’t think of any reason to colour manage the alpha channel. Surely that has to be wrong in any situation. Does anyone have an example where it might be right?
It impresses me as a bug. I can’t think of any reason why Photoshop shouldn’t record the actual color numbers you enter, or why it shouldn’t give you a readout of the actual numbers it will be recording to the file.
Channels and or Spot channels need to be color managed. They are grayscale data and need a color space descriptor just like any other image. If you had no color management you would not have an image to look at. No color management more or less means that you are unaware of the color space that is assigned to the image – and most of the time that would be sRGB or Monitor RGB.
Again – if you truly had no color management you would have a blank file.
color management doesn’t mean that a different number is recorded into the file than what is put into the channel. color management means the file is displayed or converted according to profiles, but not that the numbers are transformed when the file is written.
Mike, I think we’re talking about slightly different things. I think most people understand the difference between colour management being "on" and "off" as being to do with whether the colours are transformed automatically between colour spaces to produce the same perceptual results in different media and situations. Colour management being "off" means not performing such a transformation. Adobe uses the phrase "off" to mean this. I don’t think anyone would agree that it meant "no colours at all".
I agree that colour and spot channels need colour management. However, the alpha channel is not one of those — it represents transparency — see <http://en.wikipedia.org/wiki/Alpha_channel>
There might be some sort of argument for it to go through colour management of some sort, but I can’t imagine why applying the grey dot gain to it can be right in any circumstances. But I’ll wait to see if anyone can come up with one before I pester Adobe about it.
The black channel should be used and not the 20% generic dot gain to describe Spots. You CAN load a CMYK profile into the alpha and spot channel portion of the color settings to use just the black, but it’s not a default behavior.
Typically you want to have alpha channels a linear as possible and not have some proportional curve to describe them.
We frequently use targa’s placed in Illustrator files and we need to be able to silhouette them with an alpha channel. We recently moved to CS3 for both Photoshop and Illustrator and of course the alpha’s do not function the way they used to.
What I found in experimenting for a workaround is that Illustrator CS does see the alpha’s in .tga files. We can open the Illustrator CS files in CS3, and the transparency is preserved. We can also copy and paste the placed .tga’s into a new CS3 doc and they stay silhouetted.
So for our purposes, it appears the problem lies with Illustrator and not Photoshop, though I realize this isn’t exactly what others here are having a problem with.
I’ve also found that Illustrator (either version) does NOT see the alpha’s in .png’s, .psd’s or .tif’s. But I don’t think that’s changed from previous versions afaik.
Richard, did you ever get any resolution for this issue? i have a similar issue with the way that CS3 handles channels. We use channel operations to make customs channels for a printing process that we created in PS5 it will no longer return the same values when done in CS3. same issue as you had, it tells you that it is the same but it is not. Anyway i don’t mean to talk your ear off but our problems seemed very similar and wanted to know any solution that you had might be applied to ours.
No, no resolution. I pestered Adobe support for a while but they just tried to get me to go away, then gave me canned irrelevant replies, then told me not to use whatever it was that was causing the problem, then closed my call. It seems to be a pattern.
Hello Chris. When you say "writes the exact values to the channel" I presume you do not mean "writes the exact values to the file" since this is clearly not the case. The file ends up with values which have gone through the colour settings. The assertion is that "interpreting" the grey values in an alpha channel is always wrong. An alpha channel is not colour, but transparency, and the "grey values" are not greys at all, by alphas, and have nothing to do with perceptual greys.
We have a workaround for this (turning colour management off) but it means we can’t colour manage TGA files and still get the alphas we expect. Anyway, we no longer have an urgent problem.
progress, I know that the values are often the same when you look at them in Photoshop, but they are not stored in the TGA as those values. Also, because the range 0-255 for alpha is mapped through a colour management curve, the values are NOT always preserved by save/open, but rounded.
Proof: using colour settings "North America General purpose 2" make a small (e.g. 32×32) image with white background. Make an alpha channel. Set your foreground colour to 62, 62, 62. Fill the alpha channel. Save, open, check the alpha channel. It’s now 61, 61, 61.
If you save a TGA with alpha channel 61 grey, then try to change it to 62, then save it, you get an identical file.
But really the point is this: alpha is not colour. It is transparency. It should not be subject to colour management. You say "the visual is maintained" but alpha is transparency, not colour, and the visual is _not_ maintained if it is transformed through colour management. This is because we are trying to manipulate images where "128 alpha" means exactly 50% transparency, as you would expect. But with Photoshop this is not what you get _in_the_file_.
Ramón, if Chris means that Photoshop writes "128" in the file for "grey 128" in the alpha channel then he’s wrong, as shown by my hex dumps earlier in this thread. This is why I wonder what he means.
I’m not sure what RGB space North US uses, but you need to pick a grey gamma that matches it, then all your problems go away. It’s not because Alpha’s are CM’d, it’s because RGB is CM’d and 128 grey is not the same as 50% RGB, unless you have the same gamma point.
I’m not seeing any values shifting on saving at all… I would look to see how your profiles are being handled if that’s the case.
Alpha is just that, however if you are using alpha in a CM’d document the application will make an appraisal of the intended % when you fill in RGB.
Try it… see what happens.
I’ve found bugs in 3dsmax where TGA values can shift when saved out of that application, so we use TIFF, but I haven’t come across it inside PS at all.
Hi progress. I have tried it. I chose RGB: sRGB and set Gray: Gray Gamma 2.2 exactly as you suggested. Photoshop continues to mess up the alpha channel. Setting the alpha to 62 results in it being read back by the dropper tool as 61, and stored in the TGA file as 0x3f (63). Setting alpha to 128 results in it being stored in the TGA as 0x7f (127).
I’m not sure how I can "see how [my] profiles are being handled". Any suggestions?
I put 128, 128, 128 in the alpha channel. Photoshop does NOT write 128 into the TGA file. If I poke 128 into the TGA file, Photoshop does NOT read 128, 128, 128 into the alpha channel.
Photoshop is _definitely_ messing with _my_ values.
I’m just wondering, how are you reading alpha values as values out of 255?
Even when I pick the colour picker up and open the values as RGB they hold…
You haven’t got the colour picker to work on an area larger than 1px have you?
I assume your working in 8 bit and have your eye dropper working in 8 bit… i seem to remember a rounding bug in 16 bit using the eye dropper set in 16bit.
I can’t help any further, because my macs and pc’s all report accurate numbers in and out of the file after saves and reopoens… with RLE on or off. Xp, Vista 64, OSX 10.4 and 10.5… CS2-3…whatever I try I can’t get them to shift. Apart from what i’ve mentioned above, I can’t see it happening.
further up you mentioned you have CM off, but use copy merged… have you got any profile warnings/decisions set up for conflicting profiles on copy/paste?
CM is bad… PS makes assumptions, and doesn’t warn you of the consequences. See if anything flashes up when you have all the mismatch etc and profile handling switched on.
128-105 is a hell of a jump and not a rounding error.
I’ll do a test via another app and see if i’m seeing any effect when looking at alpha in a 3rd party app.
1. Launch Photoshop 2. Edit -> Color Settings 3. Choose "North America General Purpose 2" (i.e. sRGB etc.) 4. File -> New 5. 32 x 32 pixels, white background 6. Channels tab, create new channel. All black "Alpha 1" channel appears. 7. Set foreground colour to 62, 62, 62. 8. Edit -> Fill with foreground colour, Normal blending. 9. Eyedropper, point sample, anywhere in the alpha channel. 10. Check foreground colour: it’s 61, 61, 61. First evidence! 11. File -> Save As, TGA, with alpha channels. I called it "test.tga" on my Desktop. 32 bits per pixel, no RLE. 12. Examine the TGA file. I use "hexdump"
Richard, If possible i would like to send you the process for doing what we do through channel operations as it is similar and MAY lead to some insight for the both of us. If you are interested you can email me at Thanks Richard!
But you must have missed the vital bit I said about Gamma.
Goto your colour prefs, and where it says " Gray : Dot Gain 20% ", change the drop down menu to " Grey Gamma 2.2 "
Then try it, and I think you should find no problem. Values report as per expected.
The way I see it, is that dot gain 20% is not a match for the RGB gamma, therefore mid point grey in greyscale does not corroborate with mid point grey in your RGB space because the two are not the same. (However I can’t account for why 62 is filled as 61…)
Yes, I think that’s part of it… the colour dropper is reporting RGB, but the assumption is that these are converted linear when in greyscale… which they aren’t (sRGB and gamma 2.2 just happen to work)
Further confusioning because specifying K as ink % carries the dot gain with it.
Hi progress. I did that several days ago, and reported the results in this thread when speaking to you. Although the gamma value does come closer, it does not fix the problem. For example, 128, 128, 128 is still stored as 127 in the TGA file.
Chris, you may well be right that I am confusing something with something else, but in an RGB mode image, how else can I edit the alpha channel accurately? Is there something I’m missing? To quote the Photoshop manual: "Masks are stored in alpha channels. Masks and channels are grayscale images, so you can edit them like any other image with painting tools, editing tools and filters."
Clarifying that… the ink values aren’t changing, the RGB equivalents are.
Actually… sussed it… I need to assign the same RGB profile when I open it as I was working in… now it works.
That’s probably the problem… targas cant carry a profile, so when the file is opened using CM off it defaults to a different profile, which gives you different numbers…
Try assigning the same sRGB profile, and the numbers read ok.
My conclusion from this thread is that Photoshop CS3 cannot edit alpha channels accurately. It does not provide a means of directly seeing or editing the alpha values. Furthermore, colour management makes some alpha values inaccessible. There is still a real problem for us which Photoshop does not solve, so we must use other tools to work with alpha.
Thanks to everyone who has attempted to solve this problem.
Photoshop can edit alpha channels accurately, and can set the values accurately. If there is a problem with the values, the user does need to make sure that they are specifying what they think they are specifying – which is mostly likely related to their color settings.
Thanks progress, you have been very patient and helpful.
There must be some mysterious setting or method or documentation that we have not yet found. I have limited time for the next few weeks but I will fiddle with it. Meanwhile we use another tool because we have deadlines.
Hello…I create and play in a few 3d VR games and use PS cs3 exclusively for artwork, but I deal mainly in .png’s, although the games do have clothing made in .tga, of which I do not understand or know well. Recently PS cs3 asked for a update for RAW, I told it to install it, it cancelled it part way through saying it couldnt while PS was running and now all my clothing items that I bought in the games that are in .tga format do not show properly, creating a grey paper effect where there should be alpha…any help on this? Thanks
Learn how to optimize Photoshop for maximum speed, troubleshoot common issues, and keep your projects organized so that you can work faster than ever before!
Related Discussion Topics
Nice and short text about related topics in discussion sections
