32 Bit TGA With Alpha Layer Not Showing Transparency

[Lyra Foxclaw]

Okay, so after fussing with this for a good hour, I cannot figure out what the issue is. 

I have a clothing texture I've been working on, and in order to keep from having a white line around the edges, I use an alpha channel in Photoshop and save it as a 32 bit TGA and still keep the transparency I want.  This has always worked in the past.  However, for some reason, this time it refuses to upload with the transparency.  Yes, the alpha channel is checked, yes I'm saving it as 32 bit and not 24 bit TGA.  No, the alpha channel is not reversed from what it should be. 

If anyone can offer help it would be much appreciated. 

[Chelsea Malibu]

You cant go to 32 bit for these.  it will not import the alpha also try a PNG and not a TGA.

[Lyra Foxclaw]

Yes, it will import the alpha.  I've done it plenty of times already with 32 bit TGA textures using alpha channels, and I just tested it again with a different file that I used the same method on.  So I know it SHOULD be working.  It just isn't. 

[Lyra Foxclaw]

Also, because a PNG has no way of recognizing the alpha channel at all, it won't help in eliminating the white edging that is the reason I want to use a TGA. 

[Madelaine McMasters]

Lyra,

I think PNG works as well as TGA, but TGA should work fine too. That's what I use. The fastest way to get to the bottom of this might be to share the .PSD file with one of us. I will be around a bit this evening. PM if you'd like me to take a look.

When I've had this problem in the past, it's been because I somehow got to saving the .tga in some odd place and was uploading an old one, or because I was actually saving the file as a PSD with a .tga extension.

[Lyra Foxclaw]

Okay, will do.  I'll be back later tonight after work and will message you then. 

[Josh Susanto]

Nothing I've evert tried to import as PNG has ever come through with a proper alpha layer, so I convert everything to TGA first and that seems to work when I use Converthub or Photoshop, but not when I use Irfanview.

If you post the PNG and TGA here, I'll be happy to fuss with them to try to get you a solution.

If I can get it to load as a TGA with a proper alpha, I'll send it to you for free in-world.

[Void Singer]

what on earth gave you that idea?

[Lyra Foxclaw]

I sent you a notecard in world Madelaine.  Just contact me and I'll send you the PSD file and hopefully you can figure out what I might have messed up. 

[Madelaine McMasters]

I didn't receive a notecard, Lyra. Try again? I sent you my e-mail address in a forum PM.

[Josh Susanto]

Please send me what you have in-world if you don't want to post it here, and I'll fuss with it until I at least have something to tell you about it.

[Chosen Few]

---

Lyra Foxclaw wrote:

Okay, so after fussing with this for a good hour, I cannot figure out what the issue is. 

I have a clothing texture I've been working on, and in order to keep from having a white line around the edges, I use an alpha channel in Photoshop and save it as a 32 bit TGA and still keep the transparency I want.  This has always worked in the past.  However, for some reason, this time it refuses to upload with the transparency.  Yes, the alpha channel is checked, yes I'm saving it as 32 bit and not 24 bit TGA.  No, the alpha channel is not reversed from what it should be. 

If anyone can offer help it would be much appreciated. 

---

Here are a couple of common alpha channel related pitfalls:

1.  What version of Photoshop are you using?  If it's 7.0, then that's your problem right there.  That version does not handle alpha channels properly.  Also, if you've ever installed any kind of autmatic alpha channel generator, chances are it's just a repackaged version of that same borked TGA saver from 7.0, and it WILL ruin your current version of Photoshop.  If so, the only fix is to completely uninstall PS, and reinstall.

I'll never understand why people feel the need for that auto-alpha garbage.  Making a real alpha channel by hand takes all of two clicks.  That autmated stuff never makes anything any faster, and only causes problems.

 

2.  How many channels are in the working PSD?  Is it four, and ONLY four?  If you've got any extra channels in there, you'll end up with an all white alpha in the exported TGA.  Delete any extraneous channels, and your PNG will come out just fine.

 

If neither of those issues are the problem, then as others have suggested, I'd need to see the file before I could determine what exactly is going wrong with it.

 

 

---

Chelsea Malibu wrote:

You cant go to 32 bit for these.  it will not import the alpha also try a PNG and not a TGA.

---

Not sure where you might have gotten that information, Cheslea.  SL has always been able to import 32-bit TGA files.  In fact, before PNG was added as an option a couple of years ago, 32-bit TGA was the only way to do texture transparency in SL.  That's how we all did it for years.  PNG was only added after an enterprising SL resident donated the import code to LL.

Nowadays, PNG works, of course, but there is a catch.   Because the PNG format supports multiple forms of transparency, there's a fairly wide margin for user error.  It's very common for one to end up with a 32-bit texture where one's intention was 24-bit. 

The workflow utilized when TGA is the intended output lends far more control to the user.  That's one of the reasons TGA has remained an industry standard for texturing for decades.

 

 

---

Josh Susanto wrote:

Nothing I've evert tried to import as PNG has ever come through with a proper alpha layer

---

Considering that there's no such thing as an "alpha layer", and that the PNG format doesn't even support layers in the first place, that's hardly surprising.

It's alpha CHANNEL, people.  There's a world of difference between layers and channels.

In any case, I'm not sure why you've had such trouble importing PNG's with transparency to SL.  Usually, when there's an error, it goes the other way around.  Unintended transparency in PNG-sourced textures abounds.

 

 

---

Josh Susanto wrote:

so I convert everything to TGA first and that seems to work when I use Converthub or Photoshop, but not when I use Irfanview.

---

I'm curious why you'd use a converter at all.  Why not just output a TGA in the first place, directly from your working document in Photoshop?

[Josh Susanto]

1)

I'm not particularly interested in the difference between channels and layers.

But the "channel", in any case, IS a "layer" inasmuch as the data behind it is still there and masked by it.

It is every bit as much a layer as the "color layers", which, actually being integrated to a single image, are not layers at all and should probably best be referred to as "channels".

So, yeah... I'm sorry I sometimes get momentarily confused by technical terminology that is totally ass-backwards to begin with.

2)

I don't export TGA from Photoshop, because 99% of the time, I'm not even using Photoshop.

Photoshop, not being free, is also not readily portable.

If I'm going to buy Photoshop just to do conversions, maybe I should also just hire someone else to press the button for me.

3)

The transparent component that appears after conversion to TGA is already present in the PNG. Otherwise it would not appear. So this crap about PNG not even supporting such data is... well... crap. Try it yourself if you like.

Here's Lunapic:

http://www.lunapic.com/editor/

Here's Convert Hub:

http://www.converthub.com/

Conversion to TGA is necessary ONLY because SL does not read the transparency in the PNG, and will only read it once converted to TGA.

[Chosen Few]

---

Josh Susanto wrote:

1)

I'm not particularly interested in the difference between channels and layers.

---

I'm sorry to hear that, Josh.  If you were to take an interest in the difference, you'd find it would aid you greatly in all your graphical endeavors. Without at least a cursory understanding of the fundamental characteristics and application of each, you're really flying blind in your approach to image creation and graphics manipulation.  That unfortunately translates directly to a tremendous inefficiency in terms of time and energy expended in the creation of each image.  A little understanding goes a long way toward making things MUCH easier and more time-effective.

 

---

Josh Susanto wrote:

But the "channel", in any case, IS a "layer" inasmuch as the data behind it is

still there and masked by it.

---

No, a channel is NOT a layer, and a layer is NOT a channel.  They are two entirely different things.  I cannot overstate how absolutely fundamental the differences between them are.

For an analogy, I usually put it like this.  If all the layers in an image were to get together to play football, the channels wouldn't be players in the game.  They'd be the force of gravity keeping the players feet on the ground, the warmth of sunlight illuminating the field, the push of the wind affecting the course of the ball .  Channels are the fundamental forces of the graphics universe.  You can have an image without layers in it, just as you can have an empty football field with no players.  But you cannot have an image without any channels in it, any more than you could have a football game without gravity. 

As for what you said about masking, the fact that layer masks and channels operate on similar principles doesn't mean they're the same thing.  Masks are not layers.  Masks are not channels.  Masks are masks.

 

---

Josh Susanto wrote:

 

It is every bit as much a layer as the "color layers", which, actually being integrated to a single image, are not layers at all and should probably best be referred to as "channels".

---

No, the layers in an image should not be referred to as channels, ever.  By making such a statement, you're only further underscoring your own admitted lack of understanding of the definition of each term.  They are NOT interchangeable in any way.

---

Josh Susanto wrote:

 

So, yeah... I'm sorry I sometimes get momentarily confused by technical terminology that is totally ass-backwards to begin with.

---

They're not "ass-backwards".  Each term has its own distinct meaning.  There's no overlap, no reversal, no interchangeability. 

I'm sorry you find it confusing.  I'm guessing you simply weren't taught this stuff before, and there's certainly no shame in that.

I do find it a little troubling, that despite you're having "no interest in it", you see fit to write about it anyway, thus injecting incorrect information into the duscussion, which can potentially hinder others who are legitimately trying to learn the subject for the first time.  If you truly have no interest in it, I'd ask that you refrain from commenting on it. That would only make sense, don't you think?

If, however, you would  like to take an interest in it, GREAT!  I'd be happy to help you learn, as I'm sure would many others here as well.

---

Josh Susanto wrote:

 

I don't export TGA from Photoshop, because 99% of the time, I'm not even using Photoshop.

Photoshop, not being free, is also not readily portable.

If I'm going to buy Photoshop just to do conversions, maybe I should also just hire someone else to press the button for me.

---

OK, then, export from GIMP, or Paint.NET, if you prefer free applications. 

As for portability, you can easily throw any of those programs on a laptop, and take it wherever you want.

---

Josh Susanto wrote:

 

3)

The transparent component that appears after conversion to TGA is already present in the PNG. Otherwise it would not appear. So this crap about PNG not even supporting such data is... well... crap.

---

I never said PNG didn't support transparency data.  In fact, I said just the opposite.  It supports multiple forms of transparency, which is why it's so prone to accidental inclusion of transparency.

What I did say PNG does not support is layers.  That is a fact.  PNG is a flat format, which means it's inherently layerless.  The same is true of TGA, BMP, JPG, JPEG2000, and many others. 

Some of the most commonly used raster formats that do support layers are PSD, TIFF, XCF, and PSP.  It should be noted that Second Life cannot directly make use of any of these.  They're meant to be used as working documents within source applications like Photoshop, GIMP, Paintshop Pro, etc.  The above mentioned flat formats are considred "output formats", to be imported into target platforms like SL.

As for the transparency "appearing" or "not appearing", that's irrelevant. While you're right that one method of creating an alpha channel is by first creating an image with visual transparency in it, and then converting that transparency to alpha channel data.  But that's only one method among thousands, and it's hardly the most powerful, most efficient, or fastest way to do it.  It's actually among the more clumsy and unreliable methods one could possibly choose.

Now that you've said Lunapic is your tool of choice, I understand why your thinking is the way it is. Because Lunapic is a web app, its functionality is pretty limited.  While I do have to give it props for being pretty decent at doing the few things it does, the fact remains that it simply can't do the hundreds of other things that desktop graphics apps do.   It's just not in the same league as professional, or even semi-professional, texturing tools. 

Lunapic doesn't offer access to channels, which I'm guessing is the reason you appear to be having such a hard time understanding what channels actually are, and how to use them.  It also doesn't support layers, which probably explains why you also appear to be a little unclear on what constitutes a layered vs. flat format, and how layer masks work.

I'll spare you the technical details about these things for for now (unless do you want to read them, in which case I'll be happy to stee you toward articles that I and others have written on the subjects), but suffice it to say your notion that the transparency couldn't appear if it weren't visually present in the working document is 100% false.  We don't need to actually see the transparency visually in order to map it in a channel. As a professional texture artist who makes images every single day, I can promise you, I almost never work with visual transparency.  I map my transparency in a channel, and that's that.  I do this because it's infinitely faster, and way more flexible than doing it the WYSWYG way.

The logic is very simple.  If we color a pixel white in the alpha channel, that pixel will be fully opaque in the assembled image.  If we color a pixel black in the alpha channel, then that pixel will be fully transparent in the image.  And if we color a pixel any of the other 254 available shades of gray that can exist in an 8-bit channel, then that pixel will be translucent in the image.  The darker the gray, the more transparent.  The lighter the gray, the more opaque.  That's really all we need to know.

This data mapping model is an extremely powerful tool (even if you couldn't care less about the actual math involved) which saves an incredible amount of time, if you understand how to use it.  For example, let's say you want your image to grade smoothly from opaque around the edges to transparent in the middle, like a pane of stained glass.  If you tried to paint such an image just by visually looking at the transparency itself, it could take hours or days to get it right.  But by working directly on the alpha channel, you can be done in literally two clicks.  Simply apply a black-to-white radial gradient, that's it and that's all, done, in less than a second.  

And that's just for one pane, by the way.  Imagine if you had an entire stained glass window to create, with hundreds of individual panes.  With the WYSIWYG work flow you described, it could take months to make it look good.  With alpha channel work flow, it would take a couple of minutes at most.

---

Josh Susanto wrote: Try it yourself if you like.

Here's Lunapic:

http://www.lunapic.com/editor/



Here's Convert Hub:

http://www.converthub.com/



Conversion to TGA is necessary ONLY because SL does not read the transparency in the PNG, and will only read it once converted to TGA.

---

I'm quite familiar with Lunapic, and its limitations.  The reason SL "won't read the transparency in the PNG" is not because SL can't actually do that with PNG's.  It's because Lunapic doesn't give you the option to save the file with the correct color mode.   This is a serious flaw in Lunapic, which has nothing to do with SL.

[WannaPiEcE Crabgrass]

I am also unable to upload alpha textures in the most current viewer.

Using Viewer 2 the Alpha layers show normally (same file).

Not sure what the problem is but I've done fresh installs of the new viewer and still no luck

 

EDIT: OK it's just the image uploader that shows it with a white backround, once the texture is applied to a prim it is then transparent. Strange.

[Chosen Few]

---

WannaPiEcE Crabgrass wrote:

Alpha layers

---

 

Grrr...

[Tazzie Tuque]

ack!!!!! I have been using CS6 photoshop since it came out;  I have always saved clothing with transparent areas using TGA, saving it with a black extra background layer to get rid of the white line..  I have no clue what the hell has changed or where but, saving TGA fies that way does not work anymore..   Photoshop hasn't changed,  but I am using the 64 bit version for the first time, and for the first time using a black background to save a targa with transparency just doesn't work..  I always get the black background in the save where as I never did before..  the whole purpose of putting a balck layer behind your texture image was to create a transparency and eliminate that dreaded white line that you STILL get with png..  So I don't know what the problem is but I am damned frustrated with it!

[Rolig Loon]

Using a black background should work if your image itself is black.  The whole point is to match the color of the background to the color of whatever is stitting on it. To quote from Chosen Few, who used to answer texturing questions here for ages and taught many of us old-timers ....

This is a very common problem caused by what’s known as anti-aliasing, which is the computer’s way of smoothing the appearance of jagged edges by combining colors along diagonals or curved lines. Just like with any other image element, the pixels where black meets white in alpha channels get anti-aliased so that they appear to blend smoothly together. This anti-aliasing results in gray pixels, which end up translating to a semi-transparent outline around the opaque parts of the image.

How this results in a white halo is pretty simple. If there’s white space (or blank space) surrounding the opaque parts of your image, those anti-aliased, semi-transparent edge pixels end up combining their coloring with the white around them. They become so lightened by the process that they appear to be a halo.

There are several other good ways to get rid of the white halo. Because a black or gray halo is usually less obvious than a white one, the method you have been using is pretty effective most of the time.  Another method is to make a copy of your image, set it under the original, and stretch it slightly.  That makes a background that really is well-matched in color and pattern to your image.  You can use your  smearing tool to do the same thing.  You can also get the Flaming Pear plugin that Robin Wood likes.  It does the smearing automatically. Any of those methods reuces --- maybe even eliminates --- the halo created by anti-aliasing.

Personally, I prefer to avoid making a white halo in the first place.  Then there's nothing to eliminate. Create a mask layer that you use to generate the alpha channel image but don't use it to cut out pieces of your "fabric" layers. Just leave the layers with your image on them intact, filling the entire canvas. If you have made your alpha channel image correctly, it will do all the work of cutting out all the pieces that are supposed to be opaque.  Because there is never any empty space behind the fabric pieces, there will never be a white halo.