HEAD's UP!! LL slipped in PNG file formats!

Maybe this has been coming for some time and has been announced or something, but I don't see it in the blog or anywhere, but the optional viewer today contained support for importing PNG's as textures.

What does mean? I'm really not sure, I'm playing with it right now, but with PNG there is no alpha channel. You set your file up to to show through to the little blocks where you want skin. You can even use semi-trans areas and the clothing will be sheer!!

This seems kind of like the 'automatic' feature of Photoshop 7.0, so there may be some pitfalls, although so much can be done in photoshop. It sure is nice seeing the sheer and not guessing at the alpha channel levels.

Anyone have any comments about the use of PNG as opposed to TGA?

Hat's off to Pennie Strauss for tipping me off on this one!

I think you should throw away your photoshop and buy paintshop, I have never had a problem with seeing how sheer this outfit is going to be, either before i save it as a TGA or when I am putting it in game.

Transparency information *is* the alpha channel.

In a cad/architectural rendering program duo I use I'm able to get transparency and semi-transparency using 24-bit PNGs. Does this mean smaller, faster loading texture files are now a possibility? Or does bit depth not matter for that? (I need to re-read the appropriate sticky)

Careful there, Emap. Before you go telling people (even in jest) to throw away incredibly powerful software in favor of what can best be described as fairly okay software that happens to work pretty well for SL purposes, you might want to read up a bit. Whether or not you can see the transparency as you go depends entirely on what technique you're using to create your alpha. This is equally true whether you're using PS or PSP. However, since Photoshop offers about a thousand different ways to make an alpha channel, and PSP only offers a couple, you're potentially more likely to stumble upon a WYSIWYG method in PSP than in PS, just as you apparently have. Less options means increased odds of finding any one option, but it also means way less power at your disposal.

In PSP, seeing the transparency as you work depends upon putting your mask mask in the right place. Well guess what? You can do exactly the same thing in Photoshop if that's how you choose to work. I don't personally feel that that's always the best way to go about it, depending on what you're doing, but the option is certainly always there.


Thanks Blaze. Just so you know, it was mentioned on the blog last week, but they didn't make a big deal out of it, just one little bullet point in the Changes section of the notes. I've been having serious computer troubles or I probably would have written something about it here myself. I'll definitely be amending the Transparency Guide to talk about PNG when I get a chance.


Well, id you want to get technical, there absolutely is an alpha channel. You just don't usually see it. A better way of putting it than "there is no alpha channel" would be "you don't have to edit the alpha channel; you can just work directly with visible transparency on the canvas."

Of course, you can do that with TGA too by using a mask, and with much greater precision, so there's not much benefit other than saving a couple of clicks (one to create the mask, and one to copy it to alpha).


Okay, a few things to answer your questions. First, yes, this type of functionality is what Adobe was trying to do with PS 7.0. However, as you know, they royally screwed it up.

Second, PNG is a great format. Lossless compression, transparency support, all good. It was created to compete with GIF on the web, but it never really caught on all that well. In fact, one interpretation of what the letter's stand for is the recursive PNG's Not GIF, just like GNU's Not Unix, although Portable Network Graphics is the official name.

Those who know about PNG swear by it. Those who don't use it seem to just to prefer to wonder what it's doing in their Save As menu, rather than take a minute to learn about it. I'm not sure why that is. It's kind of funny, actually.

In any case, here's my opinion on PNG vs. TGA. While PNG is a really good format, I still recommend using TGA for a couple of reasons. I'd call the visible transparency in PNG a mixed blessing. It's certainly more intuitive and easier for people to understand, which is great, but it's also less powerful than direct editing of alpha channels, so people who use WYIWYG transparency will have to work a bit harder in many cases to get the same results as people who use alphas.

Working solely with visible transparency can get messy. It can be destructive, making it harder to undo things or make changes later, and it makes creating things with much variance in transparency difficult. For example, let's say you've got a complex image like a mosaic pattern or something, with lots of layers and tons of complicated imagery all packed into a single image, and you want to give the whole thing a transparency gradient from top to bottom. If you're only using visible transparency, how would you do it?

You could spend all day subtly going over the image with a stronger and stronger eraser, or you could simply spend two seconds applying a gradient to an alpha channel. Me, I'd go with the latter. Not only is the alpha channel method infinitely faster, but it's also completely non-destructive.

And there's always a risk of haloing when using only visible transparency. The pixels along the edges will be anti-aliased. If they're blending against white, hello halo. With normal alpha channel workflow, that's easy to correct. With visible transprancy, it's very difficult. Of course, it's preventable either way, but you have to be a lot more careful when working with visible transparency than when working with alpha channels.

Also, I'm not sure whether or not going from PNG compression to JPEG2000 compression will cause any more artifacting than usual. In theory it shouldn't, since PNG is lossless, but somehow the idea doesn't sit quite right with me. I know that's not much of a line of reasoning, so take it however you want. I'd like to see some real test results so I can speak more intelligently on this.

Bottom line, it's wonderful that PNG is an option for SL now, and I suspect a lot of people will use it. For simple transparency effects, it's a great way to go. For more complicated things though, you'll get better and faster results using the TGA workflow we've been using all along.



I'm not sure how SL will interpret bit depth from a PNG. I suspect though that as long as you can see the transparency in the PNG, SL will pick it up. I'd play around with it and give you a better answer, but I've been in computer hell for the past week. Everything's literally in pieces here, as I've had to replace a burned out motherboard, a leaking liquid cooling system, and a failed RAID array. Years and years of data destroyed, not to mention expensive hardware. Not fun.

I'll come back with more definitive answers when I'm back up to full speed here.

Anyway, as for smaller files, that's yes and no. PNG's will be smaller on your local hard drive than TGA's will, but that's where it stops. Once the texture gets to SL, it's no longer a TGA or a PNG, but a JPEG2000. It matters not from what kind of file the JPEG2000 was sourced. It will always be the same size.

Well, I know you meant it as a hypothetical, but heres how I would do it (in PSP, no less, I'm sure PS can do the same thing...)

I'd make a new layer, set up a transparency gradient, apply it, select the gradient, switch to the layer(s) with the image I wanted to modify, and delete the selection. Works great, I do it often. Takes about 10 seconds if I have a pre-made gradient that works, a minute or so if I have to actually make a gradient.

Thats fantastic news, I was making PNG images with my web-based sculpty generator but I had to convert them to BMP so I could upload them (all in the name of accuracy, the JPG compression on the web-side followed by further JPEG2000 compression SL-side left some pretty ugly alterations to my sculpties).
Now it'll be a shorter route from web-page to SL

As I was explaining to a friend earlier, transparency in PNG is one of those things that most graphics professionals don't rely on, it's more like how you'll work on an image as a psd file and save the optimized jpeg to use on your webpage or whatever. Similarly, most 3D artists I know will still do the alpha channel explicitly while working, and then turn that into a transparency mask and save to png if that is the file format needed for final output. Using PNG makes a difference for a lot of game development purposes mostly for reduced filesize when transferring the data over the internet, but I don't think will make any difference to SL since the file is converted to JPEG2000 on upload.

So basically what Chosen said.

Incidentally, while I don't know this for a fact, it appears that Photoshop avoids the white halo problem when saving transparent PNGs by extending the color of pixels on the edge out into the transparent area. An exact explanation of why the white halo occurs could be confusing, but long story short the problem happens when transparent pixels are interpreted as white and then there is anti-aliasing to the transparent edge. As Chosen explained, even if you never manipulate it directly, there actually is an alpha channel, so imagine an alpha channel making white pixels transparent. Thus, if transparent pixels are assumed to be the color of the opaque pixel right next to them, you don't get the white halo.

I'll go one easier for you. Rather than making a new layer, simply apply a mask to the layer you're on, and fill the mask with a gradient. It takes 2 seconds instead of 10.

Anyway, you're right, of course, that there are plenty of ways to do it, and not all of them are time consuming. My point though (which maybe I didn't explain clearly enough) was that all of those methods employ at least the same amount of you'd utilize to make an alpha channel anyway, and many of them demand far more. So what's the point in not making an alpha if you're gonna do at least the equivalent work, regardless?

That works too. Although if its not something that I'm planning to modify repeatedly in the future, I prefer my way, as the resulting image is slightly smaller. Less reversable, I'll grant you.

I just wanted to point out things weren't quite as dire as you seemed to be implying... as someone who has used PSP for the better part of ten years and only recently switched to Photoshop, I get a little touchy about it it.

I still use PSP for basic/quick stuff... Far more comfortable with the interface.

As I understand it, there is a user who really wanted PNG. So, he/she took the Open Source viewer software and coded a patch to allow PNG uploads. I think it converts the PNG to a JPEG2000(lossless) and uploads that.

Anyway, then it was subitted as a patch. LL did a code review, said, sure, why not, and now, there it is.

See

jira.secondlife.com

for details.

Unfortunately, not the case. The degree of compression used on PNG source files is identical to that of other source formats.

yeah after i went to all this trouble of converting everything to tga and stuff now i can use the png and i'm not longer used to using png so now i dont use it and well it will be good if i use fireworks for something *not sure what though maybe a sign?*

I have a feeling they are introducing PNGs for the purpose of lossless sculpty textures, so they don't have to mess with the existing code that handles JPG compression.

Correct me if I'm wrong, but aren't PNGs also animation capable? or does that change the format again?

Imagine the possibilities using animated textures ^_^

If you're talking about something like GIF animations, no, PNG doesn't do that. Even if it could though, it wouldn't matter. As has been said here many times now, every texture in SL is saved in JPEG2000 format. The addition of PNG only gives us another option for saving texture files locally on our own hard drives before upload. The moment you hit the upload button, SL makes a copy of the file, saves it as a JPEG2000, and sends it to the server.

From there, it doesn't matter what the source file format was. The only thing that matters after upload is what JPEG2000 can do, and animation is not one of its capabilities.

However, there's no reason you can't use a PNG as your source file for the same kind of scripted texture animation SL has always used.

Oh, thanks. Didn't realise that (I'm still a designer n00b)...

Hmmm... guess I will stick with standard clothes, then when I get better, start learning to script and work on the possibilities from there...

We should wait and see if it is just another option, or if it will be another path for use with sculpties that avoids the jpeg2000 compression altogether. They may limit the size of PNGs to 32x32 for example to prevent abuse.

Nope, PNGs don't do animation. You are getting PNG confused with the older, similar GIF file format.

That's an interesting supposition. They're certainly trying to come up with ways to combat JPEG artifacting in sculpt maps, and PNG could be a good solution for that. I'm not sure that allowing PNG as a source format for textures can directly relate to that, but it's possible it's a start toward that end. I guess we'll have to wait and see.

The compactness and lossless compression algorithm of .PNG is ideal for storing small images with gradients in them. Which what most sculpty textures are.

But I could be wrong. Maybe someone in LL was just bored, and decided that today, he wants to incorporate yet another graphic format to occupy his timesheet. Linden Lab zen and all, you know.

yay almost all the non standard software i use saves as png (and since almost everything i do is with non standard software...)

happy happy joy joy

Just a comment on PNG's transparency support.

PNG enables transparency in two different ways. The first way is by using a full 'alpha channel', just like TGA. So, anything you can do with TGA in this regard, you can do with PNG.

The second way PNG enables transparency is by designating one or more "colors" in the palette as transparent. This is how 'visible transparency' works: simply "paint" any area with the special color, and it will be rendered transparent (hence the term "simple transparency.)

With the second method, there is no separate 'alpha' channel (* but see below.) Instead, PNG just stores a few bytes of data about which color(s) should be rendered transparent.

There are some 'pros' and 'cons' with either method:

Using the full alpha channel gives you the most amount of control. The biggest difference is support for "partial transparency"... any pixel can be made fully opaque or fully transparent or anywhere in between (great for gradients.) But it is also more complex and can lead to subtle issues, such as haloing.

Using "simple transparency" is more intuitive and straightforward. What you see is what you get. As a bonus, the resulting file size is smaller since there is no alpha channel (only 24-bits need to be saved, not 32.) You can't, however, make semi-transparent images this way: a pixel is either fully opaque or fully transparent (aka binary transparency.)

The nice thing about PNG is you have both options available to you. If you create an alpha channel, PNG will fully utilize it. Otherwise, simple transparency "just works."

PNG is a nice alternative to TGA, especially if you're working with other mediums, such as the web. It also enjoys wide support among tools (even the "Windows Picture and Fax Viewer" can open it.) I hope the patch will be useful to the community.

-peekay

when uploading a PNG image with "simple transparency", internally the SL client decodes the file as a four-channel (RGBA) image, so an 'alpha' channel is created "on the fly" before conversion to JPEG2000 occurs. This is because the client itself has no concept of simple transparency.

Just a comment on PNG's transparency support.

PNG enables transparency in two different ways. The first way is by using a full 'alpha channel', just like TGA. So, anything you can do with TGA in this regard, you can do with PNG.

The second way PNG enables transparency is by designating one or more "colors" in the palette as transparent. This is how 'visible transparency' works: simply "paint" any area with the special color, and it will be rendered transparent (hence the term "simple transparency.)

With the second method, there is no separate 'alpha' channel (* but see below.) Instead, PNG just stores a few bytes of data about which color(s) should be rendered transparent.

There are some 'pros' and 'cons' with either method:

Using the full alpha channel gives you the most amount of control. The biggest difference is full support for "partial transparency"... any pixel can be made fully opaque or fully transparent or anywhere in between (great for gradients.) But it is also more complex and can lead to subtle issues, such as haloing.

Using "simple transparency" is more intuitive and straightforward. What you see is what you get. As a bonus, the resulting file size is smaller since there is no alpha channel (only 24-bits need to be saved, not 32.)

The nice thing about PNG is you have both options available to you. If you create an alpha channel, PNG will fully utilize it. Otherwise, simple transparency "just works."

PNG is a nice alternative to TGA, especially if you're working with other mediums, such as the web. It also enjoys wide support among tools (even the "Windows Picture and Fax Viewer" can open it.) I hope the patch will be useful to the community.

-peekay

when uploading a PNG image with "simple transparency", internally the SL client decodes the file as a four-channel (RGBA) image, so an 'alpha' channel is created "on the fly" before conversion to JPEG2000 occurs. This is because the client itself has no concept of simple transparency.

Cool. Thanks for the explanation, Peekay. I never knew about simple transparency before. I had always assumed that there was an alpha channel being created behind the scenes. Good to know.

By the way, I saw on the Open Source Community Update post on the Linden Blog that PNG support was your doing. Nice work. Thanks for helping us all out.