When compressing a file, you generally get some degree of compression, that is true. But you can never GUARANTEE compression in a lossless compression algorithm. Think of it like this. If an algorithm can guarantee compression and no loss of information, you could just keep on compressing the data over and over again until you have reduced the size to one single bit. But you can''t uniquely recreate any possible set of data from a single bit of information.
this is a great place to learn about texture formats.
Also, I''d like to point out that the TGA format does support compression. It depends upon your graphics program, but in addition to rl encoding as mentioned earlier (run length encoding) it also supports Huffman and Delta encoding techniques. That doesn''t necessarily mean they''re lossy - but it does mean you''ll need processing time for the decompression.
Personally I use OpenGL, so I need an image format who''s "image data feild" (you''ll learn about that later) can be easily changed into RGBA format. That format is so the OpenGL graphics chips in all those computers out there know how to read the texture into their memories.
The best thing about OpenGL is the hordes of documentation and tutorials out there. Endless. Seriously. But also, it ports to Macs! So what the heck.
BrotherBob: Zipfiles do guarantee lossless compression. But one thing to know with that kind of compression is that you can ''only go so far''. You Cannot recompress again to get a smaller file! So no you won''t end up with a single bit in the end... This is why twice compressing a zip file increases the size: You get the maximally compressed file plus some header info necessary to the zip... Which gets compressed the second time round along with the data, adding size.
This is how it -essentially- works: Let''s say in a text file, you have a long series of spaces. Thirty two of them. A lossless compressor will save a tag that says ''32xSpace'' Let us say we use the @ character to oversimplify... Well, rather than 32 bytes you get one byte for the tag, another to say ''32'' and a third one to indicate the space ascii code. Get it? Compressed file is three bytes long, but when the program returns the data to normal, it''ll give you thirty two spaces, same as the original file: Lossless compression!
Now I suspect you to be more used to JPG-style compression, which doesn''t hesitate to damage the data -a little- provided it doesn''t apparently damage the picture. (Ideally speaking, of course) By contrast, GIF format uses a lossless compression algorithm.
This is all basic algorithmics, folks.
=^.^= Leaders and teachers should remember: It is best to offer others what they Need, not what they Want.
quote:Original post by Spacecat Zipfiles do guarantee lossless compression.
No, they don't. Zip files guarantee that the compression (if any) will be lossless. But they do not guarantee that there will be a compression. That's what Brother Bob meant (I guess). Lossy algorithms, on the other hand, do guarantee that a compression will take place. But they don't guarantee it to be lossless (obviously).
And the reason why 3D hardware doesn't support GIF/PNG/etc in hardware is simple: Huffman/Lempel-Ziv based compression does not allow random access to the data. You have to decompress the entire image to access an arbitrary pixel. JPEG/S3TC/etc do support more random access: you only have to decompress a small part of the image (typically a small rectangular area) to get access to an arbitrary pixel. HW assisted JPEG decompression on texture mapping units will probably be available pretty soon. If it's a good solution in terms of visual quality is a different question. Lots of people argue that JPEGs should never be used as textures, as they remove frequency parts of the image that are essential to give a good result when resampling the texture onto a 3D polygon.
/ Yann
[edited by - Yann L on October 23, 2002 5:33:52 PM]
quote: You Cannot recompress again to get a smaller file
... so it cannot guarantee compression, since there are cases where it won''t compress.
And there''s also cases where uncompressed data can''t be compressed. Try download a piece of random data from www.random.org and compress it. You should be happy if you can compress it even a few bytes. I have tried a few different 4k blocks of data, and none of them was compressed even a single byte. Again, if there are cases where it can''t compress, it can''t guarantee compression.
