PNG just plainly sucks. I has no support for animations, timing or delta compression and sequence names. Also, PNG is slow at random access (you have to decompress image before use). Proprietary formats (like Diablo 2 DCC) are much better, but highly specialized for their games: some have no true color, other have no directions.
Name:
Anonymous2011-09-10 16:56
>>79
Doesn't matter. At or over 2/3 jewish either way.
>>80
"Performs" WRT compression algorithms usually means compression ratio. DEFLATE compresses better but is slower than LZW. There's nothing wrong with that.
DEFLATE performs sufficiently in fast in practice for most applications. Many web pages are transparently compressed using it, for example (including all HTML served by this domain).
In fact, seeing recent developments, it'd be appear there's a demand for better yet slower algorithms, a demand the Russians are filling.
Name:
Anonymous2011-09-10 17:04
>>81 Doesn't matter. At or over 2/3 jewish either way.
The basic distance-length idea was on surface. LZ were just first to write some crappy paper on it. Nothing original. Tomorrow some jews will write paper on ass wiping.
>>82 DEFLATE compresses better but is slower than LZW. There's nothing wrong with that.
It's wrong, if you want realtime speed. Compression rate isnt proportional to compression speed.
>>87 you can do a lot better than LZW.
We all would like to know how.
Name:
Anonymous2011-09-10 17:18
I think, I will use LZW compressed SEXPs for my sprite format. It will allow bignums for width and height, unlimited extensibility and instant Lisp support. Of course, I'll have to do something other than plain ASCII.
Name:
Anonymous2011-09-10 17:23
>>92
Sounds super fast. Way faster than straight 32-bit RGBA.
Name:
Anonymous2011-09-10 17:32
>>93
Loading compressed file from HDD is faster than loading uncompressed. And you can transfer it on internet without zipping.
Name:
Anonymous2011-09-10 17:38
>>92
It should also allow storing sounds and creature/projectile parameters. Hope to use it for storing resources ripped from various video games. Today sites like spriters-resource.com use crappy sprite sheets with missing frames and without palettes, sounds or any animation structure.
Name:
Anonymous2011-09-10 17:52
>>94
Yes, this is important since the best sprite renderers always load in the sprites from disk every frame and decompress pixel by pixel during rasterization.
LZW uses variable length codes. Anything that doesn't use them will trounce it in speed. Five seconds in Google: http://www.quicklz.com/
Of my personal knowledge, recent versions Windows use similar stuff for compression in the kernel (for NTFS, cache files, and the hibernation file) and for some userspace components (remote desktop protocol and a few others). Basically you have a bitmask every once in a while telling you which bytes are literals and which ones are matches.
Hint: Outside GIF, basically nobody uses LZW. What does that tell you about its compression/speed tradeoff? It has the performance disadvantages of variable length encoding without its main adaptability benefit.
Name:
Anonymous2011-09-10 18:37
>>99 LZW uses variable length codes. Anything that doesn't use them will trounce it in speed.
Anything that doesnt achieves far worse compression ratio. Still they are faster than huffman codes and bit-shifting isnt an expensive operation.
Outside GIF, basically nobody uses LZW.
Because LZW was patented and open source crowd makes a drama from this.
Name:
Anonymous2011-09-10 18:38
>>99 asically you have a bitmask every once in a while telling you which bytes are literals and which ones are matches.
I've seen it used in Stonekeep sprites. Had to disassemble .exe to get algorithm.
I created sprites in LoseThos by concocting a SVG-like scheme that can include bitmaps. LoseThos has LZW compression routines. If you save a bitmap to a file (with name ending in "Z") then it will be compressed. LZW is not good compression, normally, but since LoseThos is limited to 16 color, it's not as bad as it sounds.
That's LZW compression. Files with names ending in "Z" are automatically compressed and uncompressed when written to disk. In other words, LoseThos files look strange and corrupted because they are compressed.
God says...
Line: 61344
risen upon thee.
60:2 For, behold, the darkness shall cover the earth, and gross
darkness the people: but the LORD shall arise upon thee, and his glory
shall be seen upon thee.
60:3 And the Gentiles shall come to thy light, and kings to the
brightness of thy rising.
60:4 Lift up thine eyes round about, and see: all they gather
themselves together, they come to thee: thy sons shall come from far,
and thy daughters shall be nursed at thy side.
>>100 Anything that doesnt achieves far worse compression ratio. Still they are faster than huffman codes and bit-shifting isnt an expensive operation.
You trolled me real good, you made me actually check.
I used a LZW compressor I found somewhere which performs about 10-30% better than the classical compress, which also performs better than a textbook LZW implementation.
On the other side of the ring we have LZO (the free, old and busted version) since it's what I had at hand.
The test corpus is a bunch of files (about 45% text, 25% executables, 15% uncompressed images, 15% random crap) totaling 300MB. LZMA compresses this to less than 90MB.
Now that I think about it, an easy way to test LZW as used in GIF is to compare the resulting GIF with a raw uncompressed image, and with a PNG that does not use filters (of course all of them using indexed 8-bit color).
Benchmarking image (de)compressors is hairy though because they're too fast, so I'm not going to try.
LoseThos can handle other compression algorithms pretty easily. I don't enjoy fiddling to get better results as much as I used to. I don't give a fuck, basically. Nothing seems to matter much.
God says...
Line: 3616
36:39 And Baalhanan the son of Achbor died, and Hadar reigned in his
stead: and the name of his city was Pau; and his wife's name was
Mehetabel, the daughter of Matred, the daughter of Mezahab.
36:40 And these are the names of the dukes that came of Esau,
according to their families, after their places, by their names; duke
Timnah, duke Alvah, duke Jetheth, 36:41 Duke Aholibamah, duke Elah,
duke Pinon, 36:42 Duke Kenaz, duke Teman, duke Mibzar, 36:43 Duke
Magdiel, duke Iram: these be the dukes of Edom, according to their
habitations in the land of their possession: he is Esau the father of
the Edomites.
Name:
Anonymous2011-09-10 20:00
>>107
PNG does row subtraction and LZO compresses palette and header, which may consist of redundant data. You're biased as the whole Israel of jews.
>>109
Maybe you missed a PNG that does not use filters I disabled these specifically.
In fact, I just tested with them enabled, and the compression ratio decreased (resulting size 89130), which is not surprising since they're meant for true color data.
The palette data is 768 bytes out of 2074368. I suspect it doesn't compress very well either, since LZO has no delta filter or entropy coder, and all palette entries are different.
However your analysis makes me think you understand what's going on and are just trolling at this point (if not all along), and therefore I will refrain from posting further.