Allow import of PNG image format

Currently SL allows texture upload of BMP and TGA lossless formats. PNG (Portable Network Graphics) is increasingly popular, smaller than TGA, offers an alpha layer, royalty free, and has a free reference library. I would expect it would be straight-forward to put in since multiple graphics formats import is already supported. But is it popular with more open source purists?

In preparation to putting in a proposal to vote on, I figured I would put it up here to be torn apart, and commented upon. Has it already been proposed? A text search in here did not find "png"...

Thoughts anyone?

I believe all image are converted to a form of JPEG on upload anyway. So, uploading anything but a lossless file, such as targa (.tga) is double-compressing your image.

Recently, a friend uploaded a jpg compressed at the highest quality, and asked why it appeared blurry in SL. She had created it in PS, so I suggested that she save it as targa and re-up. She did, and the quality was noticeably better.

but PNG is lossess too, isn't it?

Yes, and it would make it easier on people using PS versions that don't deal with alphas very well for TGAs. Also, I believe that Windows can display PNGs in the slideshow view, which would make it more convenient for Windows users.

As a Gimp user on a Mac none of the above concerns me personally, but it seems like the appropriate format to use generally if you want a lossless one.

I whole-heartedly endorse this product and/or service.

LeSeul.

me too

There is already a vote, please add to it.

http://secondlife.com/vote/index.php?get_id=452

Thank you. There were so many proposals to go through that I tried search, and it did not find anything. There we go.

I never say "me too" but "me too".

Your welcome. Its hard to find votes on there, they need a proper search function, what is there now, doesn't really work. So many votes could be consolidated, I can understand why its all so daunting to the Lindens, right now its all fractured.

Hmm, here's a question - since when converted from jpeg it uses lossy compression, I assume the data on the server is much smaller compared to a lossless jpeg2000 file... wouldn't it follow that the data sent back and forth would be much smaller too, since encoding and decoding is done on the client side?

Sooo... would a lossy encoded 1024x1024 jpeg look better (even accepting the 'blur' factor) and load faster than smaller lossless textures compressed as lossless? Maybe I should run some tests, hehe.

png is both ways, since it quite old it supports intelacing, indexed color palletes, and heavy compression.... in photoshop 7.1 there is effectivly no options for controling these options.

so eventho i have good faith Photoshop is on the up and up with 24 and 32 bit modern png, i think it still compresses the image and loss would happen

on the other side, more of your open source / prject applications have every option in the book availible on save ... gimp for instance allows these choices

Adam7 Interlacing (puts black lines in the image, simmilar to a projection TV)
Save Background Color
Save Gama
Save Layer Offset
Save Res
Save Creation Time
Save Comment
Save Color Values From Transparent Pixels
and compression level

now for the most part, those options are aicent history, or have to deal with the network part of Portible Network Graphics, but something really handy about it is ....

You can use it to kill halo on alpha images

best case:
you make a image 100% from scratch on a transparent background in your favorite editor, i would suggest saving in psd format... go to the gimp open the file, and save it as PNG with all of the above unchecked (value 0 for compression), but leave save resolution on, im not shure if thats just a header or valued data (doesnt matter becuase SL with jpg it anyway)

close the image, and while still in the gimp load the png file (so it just reading the new data) then save as TGA (RLE compression off)

Upload, ill bet you the aplha is exactly where you put it, no white or color blured edges.
www.cheesefactory.us/samples/things_with_png_trick.jpg

So since i already use PNG alot direct upload of the format would save me 2 steps, since it doenst, the extra seconds doesnt kill me

PNG is always lossless. The lossy and animated variant MNG is not PNG.

It should be noted that in a (semi) recent comparison that Kakadoo, the jpeg2k library that SL uses, scored the worst across the board, in both speed and encoding efficiancy & quality.

If it's lossless, then it can't really be a smaller file size than a TGA then can it? (one of the reasons given for implementing it in the initial post).

TGA is an uncompressed file format. You can open your TGA image in notepad and see the basic image. PNG, JPEG2000 and other lossless formats, use complex math and analisis of the images entropy to represent it. The lower the entropy the better the compression (a cheep way to messure entropy in a file is to see how well it compresses).

zip and rar are good example of lossy compression

So PNG is compressed but still lossless?

http://en.wikipedia.org/wiki/PNG

...

More info: http://www.libpng.org/pub/png/pngintro.html

I like png!

I voted.

>If it's lossless, then it can't really be a smaller file size than a TGA then can it?

One way of loss-less compression is Run Length Encoding.
Instead of storing each color, you store a count, followed by the color.

An elementary example of RLE:

Original line in an image:
RRRRRGGGGGGGGGBGBBBBGGRRRRRRRRRGGGGGBBBBBBBBBRRRRRRRRGGGGGGG

The RLE version:
5R9G1B1G4B2G9R5G9B8R7G

The original took 60 cells, the RLE takes 22 with no data loss
and compressed to a little more than one third the size.

Of course, it works best when there is a high number of repeats.

--

I hope that lossy is a typo and you meant lossless, zip would be a disaster if it destroyed your info!

There are complicated ways to do compression, but run-length-encoding as Lumpy points out, along with much more complex methods all look at the data and identify common patterns. Some methods look at an image and create a sort of 'dictionary' of image pieces, assigning them a code depending upon how common they are. So, the most frequent part of an image (say big red chunks) may be assigned the shortest code, the next most common a slightly longer code.
Once you've broken it all down properly the end result is that repeated elements are shortened, and only included once.

Almost everything that goes through your modem now is compressed in one way or another, the trade-off is that compression requires your computer to do work, both in compressing the image, and then in re-building the image so it can be displayed when it reaches the other end. But computers are now fast enough that you don't really notice it

.png I think is even more complicated than the dictionary methods, but the fact remains that it's not only lossless, but tends to be compress most large images VERY well. Depending on your image you may get significantly better results using .png than you would with .jpg.
For example, if you have an image with horizontal lines of red and green, one or two pixels thick and one or two pixels apart, if you compress this as .jpg then the two lines end up getting blended together into a completely different colour, requiring you to use high-quality .jpg compression in order to keep it looking good, but ramping up the file-size. Whereas .png preserves the lines perfectly, and will be much smaller than a high-quality .jpg for the same sized image.

There's a lot of compression schemes out there other than "lossless" and "lossy", so "lossless" doesn't imply "not compressed". TGA can be compressed, but typically it isn't because there's so many TGA options and variants that it's not safe to assume that a reader can handle anything but the most straightforward and common compression... which is either "none" or a fairly vanilla LZW compression if I recall correctly... and PNG's compression is very good.

Alright, lets throw up some comparisions between the formats just so people who haven't worked closely with these have an idea of the difference. In the following images I used Jpegs with Progressive rendering, and varying levels of loss, as listed. for the Gifs, I used 256 colors, adaptive with interlacing, the 8bit Pngs used similiar settings.

...

JPG, 10% Loss: 42.0KB http://www.zatzai.com/ztz/SLF-A-JPG-090.jpg
JPG, 20% Loss: 27.2KB http://www.zatzai.com/ztz/SLF-A-JPG-080.jpg
JPG, 30% Loss: 20.3KB http://www.zatzai.com/ztz/SLF-A-JPG-070.jpg

GIF, Lossless: 59.0KB http://www.zatzai.com/ztz/SLF-A-GIF-100.gif
PNG, Lossless: 43.9KB http://www.zatzai.com/ztz/SLF-A-PNG-100.png

...

JPG, 10% Loss: 60.5KB http://www.zatzai.com/ztz/SLF-B-JPG-090.jpg
JPG, 20% Loss: 42.2KB http://www.zatzai.com/ztz/SLF-B-JPG-080.jpg
JPG, 30% Loss: 33.0KB http://www.zatzai.com/ztz/SLF-B-JPG-070.jpg

GIF, Lossless: 54.8KB http://www.zatzai.com/ztz/SLF-B-GIF-100.gif
PNG, Lossless: 37.5KB http://www.zatzai.com/ztz/SLF-B-PNG-100.png

...

JPG, 10% Loss: 74.0KB http://www.zatzai.com/ztz/SLF-C-JPG-090.jpg
JPG, 20% Loss: 49.5KB http://www.zatzai.com/ztz/SLF-C-JPG-080.jpg
JPG, 30% Loss: 40.1KB http://www.zatzai.com/ztz/SLF-C-JPG-070.jpg

GIF, Lossless: 29.3KB http://www.zatzai.com/ztz/SLF-C-GIF-100.gif
PNG, Lossless: 17.2KB http://www.zatzai.com/ztz/SLF-C-PNG-100.png

...

These images show what PNG is good for, lossless compression. So its far better for graphics, than say photographs. It was made to replace GIF due to the patent issues that came up with GIF, which I believe are no longer relevent (They expired worldwide). However, it is a better compression format than GIF, and in addition to the 8bit mode that competes directly with GIF, there is a 24bit and 32bit mode that compete with formats like TGA.

But not everything supports output to TGA, and regardless, there is not much tweaking we can do to make said TGA smaller, whereas with a PNG, we can do alot. But maybe thats pointless as it will get converted to a Jpeg2000 anyway.

Still, this is a convenience issue, it should not be hard to have SL handle PNG on upload.

TGA has an RLE based compression in its specifications. Most programs will support it (it's extremely trivial to implement). There are no other official options to compress TGA within its spec.

I've uploaded TGA's with RLE and even though people thought the decompression would happen client side (nullifying the advantage of RLE) I've the impression that the RLE is decompressed on the server side (uploading large TGA's which have a lot of repeat looked a lot faster when using RLE).

Off course in the end I'd rather see PNG implemented too as it would save a lot of bandwidth and it's a quite reliable format.