PNG V TGA regarding transparencies

I'm building a simple window frame, so the gaps in the windows are transparent. I can save as TGA and try and not get a headache over how to save alpha channels or I can save as PNG and it deals with them. However as that seems too straight forward and I'm always suspicious, what's the catch with PNG?

I'm too tired to get into another skirmish in the holy war between PNG and TGA partisans, so I'll simply point you toward one of the more enlightening discussions on the topic in this forum ....... It's a little over a year old, but these things don't change. It should give you a bit to chew on. BTW, if you haven't read through the sticky thread about alpha channels and transparency at the top of this forum, please do.

if you're dealing with layers and masks for the original file (say psp format), and only saving out a copy for uploading to SL, it doesn't matter at all.

Short lecture, as I understand it. Since my understanding is simple, so is this explanation.

When you are working on an image in Gimp or Photoshop or any other tool, it is in some internal format that you don't really care about. It is only when reading or writing (saving) your work that the format comes into play.

Images need three "channels" for the color, red, green, and blue. For transparency, they need a another channel, often called the "alpha" channel.

For some purposes, more advanced, it is useful to add more channels for other things. For example, the file that is used to landscape a region has 13 channels.

Channels are not the same as layers. Each layer has its own channels, and can have many channels.

Now, you save your work to disk. JPG will only save three channels, so everything has to be merged/flattened or whatever. When you open it later, there will only be the three, RGB.

If you save to PNG, it saves 4. If you have more than 4, I am not sure how you decide which 4 to save.

The main advantage of TGA is that it saves all the channels.

When you upload to SL, it is all converted to jpeg2000, so it is all the same in the end.

Here's a short list of comments/corrections, if you don't mind.



Yes, and no. For the kind of imagery we use for SL, yes, it's three channels for color, and a fourth channel for transparency (if transparency is present). But to be complete, no, that's not all there is to it. There are other kinds of images, which do not adhere to this simplistic explanation.

It's good enough for our purposes here, though.




Technically, this is true. Each layer is itself an image, and as such, is comprised of channels. But not all programs organize things in a way that makes this obvious, or even necessarily useful.

Photoshop, for example, shows channels for the entire image composite, accounting for all visible layers in the stack. The workspace does not isolate channels to a per-layer breakdown by default. You can certainly view and edit the channels of a particular layer if you want to, but that's not something that would probably occur to most people when first looking at the way the interface is set up.




Yes, JPG only supports three channels. But that's not why the image ends up flat. It's flat simply because JPEG does not support layers. One has nothing to do with the other.

Also, I'd be careful about phrases such as "everything has to be flattened". This could be misinterpreted to mean the user must flatten the image prior to saving out as JPG, which of course is not true. I would imagine some inadvertent wording like this is probably what gave rise to the myth that used to be quite popular on this forum, that flattening was a necessary step prior to saving as TGA. Thankfully, that one seems to have been squashed by now.

Here's the deal, with respect to saving. If you save to a format that supports layers (PSD, PSP, TIFF, etc.), you get a layered image. If you save to a format that does not support layers (TGA, BMP, PNG, JPG, etc.), you get a flat image. That's it. In neither event are you required to do or not do any deliberate flattening.




That's not entirely accurate. Not all PNG images have 4 channels. The PNG format supports a wide array of color depths. RGBA is just one of many.

For SL purposes, PNG images will end up as either 3-channel or 4-channel textures, depending on whether or not transparency is present. But having 4 channels is not a necessity of the PNG format itself.





TGA supports up to four channels, no more. For SL purposes, three-channel (RGB) and 4-channel (RGBA) are the usable options.

Examples of formats that support unlimited numbers of channels are RAW, PSD, and TIFF, among others.





True, but different output formats tend to lend themselves to different work flow styles, which is what these kinds of discussions are typically about. In most cases, if you know you're going to be mapping transparency with an alpha channel, your approach and procedures are going to be different, from start to finish, than if you're working strictly with what-you-see-is-what-you-get. As learners and educators on this forum, methodology is the fodder for practical discussion, far more than any under-the-hood technicalities.

The 'gotcha' with PNG I see implied on these forums stems from applications not uniformly implementing support for its features.

In Photoshop - at least from PS 5 to CS3 (haven't used CS4) - PNG transparency is generated from layer transparencies. That is, via masking, or actually erasing to transparent in a layer. When Photoshop then saves transparent PNGs the RGB data in the transparent areas is given a simple fill color. If you erased to get transparency this loss should not be at all unexpected, but if you used layer masks it can be disconcerting to step down to a 24 bit image and realize you have lost data, especially if you are used to tga workflow which is non destructive in this regard.

Keep in mind this is not an issue with the PNG format itself. Other applications can save PNGs with an alpha channel that keeps the RGB data just like TGA (as well as the Photoshop way too). With Photoshop you have to use 3rd party plug-ins to get this functionality. Why does the industry standard image editor limit your choices this way when you can get free editors that work both ways with PNGs? I have no clue.

If this isn't a big deal to you, then use whatever format doesn't induce headaches. As Void Singer points out, if you save in .PSD, .PSP, XCF, or whatever your application's native format is (provided it saves out layers and transparencies), then it's not really an issue anyway. I would argue best practices should be archiving your work in that format, not SL compatible image formats, making it a non issue for the most part.

I use both formats myself, but in a side by side comparison I would argue that PNGs actually have greater overall utility, especially outside the context of SL development and Photoshop imposed limitations.

The up thread 'partisan' pejorative would seem to insinuate even comparing the two makes me somehow biased on the order of a religious zealot. I'll leave it to the reader to draw their own conclusions if suggesting being able to choose a higher range of bit depths, better compression, multiple transparency schemes, and an ability to index colors, as the PNG format allows, is a qualitative difference, or if it is merely rabid, unreasoning hatred.

Not at all, Pygora. That's a good, rational presentation. I made the "partisan" comment on what was a bad day, but I was thinking back over several times when the PNG/TGA discussion has been tinged with unpleasant rhetoric, similar to the "My Apple (PC) is better than your PC (Apple)" nonsense that people used to get nasty about. My tired brain was trying to avoid going there. Guess I missed.

It's more important to use targas when there's NO transparency as .png files can wind up 32 bit accidentally-ish. In transparent images either is ok. That, to me, is the .png "catch."

I'm not sure where you're getting that, Pygora. Photoshop has been able to implement a WYSIWYG work flow for PNG since the time the format was first invented. Masked or erased areas come out transparent, end of story. That's the main reason why people use it for SL textures. Those who don't want to learn to create alpha channels gravitate toward the WYSIWYG methodology that PNG makes possible.

Are you perhaps getting PNG and TGA mixed up? The behavior you described is more in keeping with how Photoshop handles TGA's. Visually transparent areas end up filled with white, since the TGA format itself does not support visual transparency.




I'm really not sure what you're trying to say here. The PNG format does not support layers, so layer masks cannot exist in it. That means, whether you originally erased or masked to create transparency, it will be just as gone either way, if you reduce the image from 32-bit RGBA to 24-bit RGB.

I fail to see how this would be "unexpected" or "disconcerting" in either case. By "stepping down", as you put it, from 32-bit to 24-bit, you're deleting the transparency map. So OF COURSE the transparency data is lost, by your own choice.




How so? TGA does not support layers any more than PNG does. In fact, it's arguable that it's even more destructive, since it doesn't even support simple background transparency, whereas PNG can. All areas that had been visually transparent in the working document will be filled with white in the TGA. So unless you've created an alpha channel beforehand, or preserved your layered working document in a layer-supportive format (which you ALWAYS should), your transparency will be completely gone. In the context by which you've defined the word, this is about as "destructive" as it gets.

If you're using Photoshop 7.0, it's a different story. That version was highly flawed, and tried to change the nature of the TGA format. When you save a 7.0-type TGA, it does preserve visual transparency, but does so at the cost of flexibility, compatibility, and stability. (See the FAQ section of the transparency guide for further explanation on this, as I don't feel like diving into all the details again at this time.)

The only way a version of Photoshop other than 7.0 would behave in this manner is if its TGA save utility had been stripped out and replaced by the one from 7.0. Perhaps this is the "third party plugin" you were referring to?





Again, I'm not sure where you're getting this. Photoshop can save a 32-bit PNG just fine, with three color channels and alpha channel, just as it's supposed to be. It can also save a PNG with transparency as an indexed color (simple transparency), for those who would rather not use alpha channel methodology.



No, you don't. Again, it sounds like you've got PNG and TGA reversed. 32-bit TGA workflow in Photoshop is alpha channel work flow, period. But for PNG's, Photoshop can ultilze either alpha channel work flow or simple transparency work flow, whichever the user prefers.




It doesn't.

Assuming you meant TGA, not PNG, then the answer is because Photoshop is actually a bit smarter than some of those other programs. It knows that alpha channels are not always used for transparency, so it makes no guesses as to what the user might want any particular alpha to be for. It waits for the user to tell it what is meant for what.

Programs that do make assumptions can appear slightly more convenient in the short term, if all you ever want to do is the one thing they're assuming you'll be doing. But if you ever want to do anything else, you're screwed.





I'm not sure "greater utility" is the best way to put it. I'll agree that PNG does have a wider range of purposes and capabilities than TGA. But more options doesn't always mean more usability. Sometimes less is more. The biggest reason TGA has been the staple of the texturing industry for decades is precisely because it's so simple. It's just a bitmap, nothing more, nothing less.

PNG can be a little too variable for its own good at times. There are a lot of bells and whistles in it that aren't at all useful for texture work. This creates a relatively large margin for error. There's nothing worse than spending hours or days baking a texture set, only to realize afterward that the specifics of the format you chose are incompatible with whatever platform you made them for. Sure, you can just do a batch conversion to fix the problem (usually), but if you've already delivered the wrong files, you not only look like an idiot, but you can end up slowing down an entire content development pipeline while everyone's waiting for you to fix your mistake. Not cool.

With TGA, that's never an issue. You deliver a texture pack in TGA format, and you know for a fact it's going to be usable.

This is what I accidentally discovered. When I take a pic in SL, it will save to my hard drive as bmp, jpeg, or png. My understanding was that for editing and re-uploading to SL, the png format was best. I don't have Photoshop and have not mastered Gimp yet, and right now, I only need simple photo editing anyway. My computer already had Microsoft Picture It for photo editing, so that is what I started using since it was able to edit png format. Upon uploading the photos though, I discovered that I was getting an alpha channel, which I did not need nor want. I have since started using Gimp or Paint.net just to re-save the final image to force it to 24-bit rather than 32-bit.

My question/confusion on the formats and usage: If I am taking a pic inworld, like modeling, and I want to edit it and then upload the image to use on a box for selling an item, should I do that initial SL photo save as png or bmp? The more I look at things, I'm guessing bmp because with a larger file size it is likely higer quality. Then, after editing, save as tga for uploading.

I use BMP most of the time but PNG is, at least, equally as good. Any lossless format that you have a imaging program to open with is good........JPEG is not lossless, so I don't use that.

Yeah, the only time I use jpeg is to save an image for uploading to a web photo site that only wants jpegs.

I'm guessing there's a slight degree of transparency somewhere in each image. This is a common issue with PNG. If so much as a single pixel is less than 100% opaque, you'll end up with a 32-bit texture in SL.




I'd suggest BMP, because it's a simpler format. I'll bet anything that you wont' end up with the unwanted alpha channel if you start with BMP, rather than PNG.




They'll both be equal quality, since PNG utilizes lossless compression. The reason the BMP file is larger is simply because it's uncompressed.

.........

I probably should test this before I mention it but I can't without rebooting to my Linux OS (my GIMP is on that drive, not this Windows drive). When I save an image to BMP using GIMP I have a dialog pop up verifying the image format with an advanced option. Expanding the option there are two bit depths available......RBG (24 bit) and RBGA (32 bit). So it appears BMP supports 32 bit (or transparency)? The save defaults to 24 bit so it should not give any unexpected results since you have to purposely select the 32 bit option.

Just mentioned this to ask if anyone has tried it and does it actually save transparency? I'll find out myself later when I reboot but curious right now..........I'm a brat!!! Tell me now, dammit tell me.

Editing........
I couldn't wait so I tested it. It's a 32 bit texture but the areas which should be transparent are black. So for SL use that option is useless as far as I can see. About the only use I can think of for it would be so save as 32 bit for more editing later.....which is so much more limiting than GIMP's native format (XCF). Well, I know now anyway.

It does that sometimes but it's really a bug. It doesn't always happen, but it's pretty easy to repro if there are unrasterized paths in the PSD. It's not always a solid fill, sometimes PS will fill in those areas arbitrarily with streaks.

I now remember why I was using PNG rather than TGA for most of my pics before uploading to SL, so now a question that is only sort of related. My OS is Windows XP Pro and I usually have my folder view setting at "thumbnails" for all of my picture folders. Is there anything I can download or enable that will let the TGA thumbnails be viewable in Windows Explorer?

You could try
http://greggman.com/pages/thumbplug_tga.htm

Awesome - I'll see if it works for XP.

YAY - it works. Thank you !!!!

32-bit BMP is a relatively new option, as graphics formats go. It was introduced with Windows NT, if I remember correctly. It has remained fairly obscure ever since.

Not all programs can create 32-bit BMP's, and not all can read existing ones as 32-bit. SL is an example of one that does neither. If you try to upload a 32-bit BMP, it will totally ignore the alpha channel, and will create a 24-bit texture. So even if LittleMe's problem were to persist with BMP, as a quirk of the particular software she's using, it wouldn't affect the resultant in-world texture, at least in theory.

If anyone's curious about Photoshop's handling of BMP, it is almost the same as its handling of TGA. Visual transparency becomes white with both formats. And with both, if you haven't created an alpha channel yourself, you'll end up with a blank alpha channel added on if you save a 24-bit image as 32-bit. The only difference is that the alpha will end up black with BMP, whereas it would be white with TGA. I'm not sure why this difference exists. Other than that, it's the same.

PS also gives you some extra encoding options with BMP that you don't get with TGA, such as the ability to flip row order, and some other advanced options. I haven't experimented to see how SL handles things if you go with any of the non-default options.

I'm not able to reproduce this bug. Can you elaborate, Viktoria? What are the exact steps to make it happen?

Greggman's thumbplugs rock. They also work with Vista, and presumably would work with Windows 7 as well, since 7 and Vista are so similar.

The downside is they're 32-bit only. If you're using a 64-bit version of Windows, they won't work. (Unless he's updated them recently. I haven't checked.)


An alternative is to download and install the DirectX SDK from Microsoft. That will add TGA thumbnail support to 32-bit and 64-bit versions of Windows.

Ahhh, nice to have this extra info since my laptop is Vista 64-bit. Thanks

(This is under PS CS4.)

1. New image, 8 bit RGB color, transparent background

2. Pick the rounded rectangle tool, tick the shape layers option.

3. Plop a roundrect onto the canvas, make it red for contrast.

4. Save As... a PNG.

5. Upload to SL and then download a copy as TGA. This is to separate out the alpha channel and see what happened to the RGB.

6. For a "second opinion", try ImageMagick, convert file.png file.tga

7. Open the TGAs in PS and admire the fancy fringe on the corners of the red box.

----

This really isn't a huge problem in most cases. The original PSD will still be intact, and the alpha covers it up anyway. It's only going to be a big deal if people are redistributing the affected PNGs with the intention that others would modify them.

I'm running Windows 7 64bit and had the no tga problem in Explorer. I'm also running PSP rel. X as a 32bit app. and seemed to have a problem opening jp2 files so d/loaded the thumbplug and also found an install called FastPictureViewerWICCodecPack.msi on the web. Not sure which one did the trick but tga's now appear in xplorer

Thanks for explaining. What you've outlined here is not only NOT a bug, it also has nothing to do with Photoshop at all. I'll explain.

Steps 1-4 are all well and fine. You end up with PNG with transparency in it, just like you're supposed to. At this point, Photoshop has done its job. End of story, as far as that goes. You'd get the same results using any other image editor.

Now, step 5 is where you start to change things. When you upload the image to SL, you introduce the viewer's JPEG2000 conversion utility, which intentionally bleeds the coloring, in order to prevent haloing. This is NOT a bug. Think of it as SL's version of the Solidify filter. It exists for good reason. It's the ONLY reason PNG's with simple transparency end up halo-free when converted to SL textures.

SL textures are JPEG2000 files, which utilize alpha transparency. When you convert to alpha transparency from any type of visual transparency, be it the layer transparency in a PSD or TIFF, or the indexed transparency in PNG or GIF, (hey, that rhymed!) the visually transparent areas will be filled in with solid color, usually white. If you don't first bleed the coloring from the opaque areas into the transparent areas, you inevitably will end up with a halo. The person who wrote the PNG-to-JPEG2000 converter for SL (who was not a Linden, by the way) was smart enough to account for this.

As for your alternate step 6, I don't use ImageMagik, so I've never tried it. But by the sound of it, the exact same process in play. It bleeds the edge coloring of the opaque elements into the transparent areas, in order to prevent haloing. Again, this is a good thing. Without it, converting from simple transparency to alpha transparency would produce a halo. It can't work any other way.

Your mention of unrasterized vectors in the working document as a trigger for this behavior could not in any way be possible. First, the working document is not the PNG, the PNG is not the JPEG2000 that SL uploads, and the JPEG2000 is not the TGA you download. (Or skip the JPEG2000 part, if you're doing the ImageMagik thing.) There's simply no way that ANYTHING present in the working document inside Photoshop could possibly affect how a third party program converts the outputted PNG to any other format. SL and ImageMagik have no way of knowing or caring what techniques you did or did not utilize in Photoshop before you spit out the PNG file. Second, as soon as you output to a flat format like PNG, all vectors are rasterized anyway. There's no such thing as a vector in a PNG file.


None of this is what Pygora seemed to be describing. He said, "When Photoshop then saves transparent PNGs the RGB data in the transparent areas is given a simple fill color." The implication was that Photoshop itself was solidifying the transparency. He didn't say anything about using other conversion programs to do it.

Pygora, I have a theory about what you've been seeing. Sorry I didn't think of it earlier. If you uncheck the Include Transparency box in the Save For Web dialog, then the transparent areas will indeed be solidified to opaque coloring. If that's what you've been doing, then just stop unchecking that box, and the problem will go away.

As I said, lots of options with PNG, so large margin for error.