There is no public-domain decoder for .LSI images, so you would not be able to actually open the files, but when converting models it shows me the size of the .LSI file as a percentage of the original file.
Here are some results.
TGA/BMP files can offer significant size decreases (on the second screenshot there was a TGA amongst all the PNG’s compressed to 0.804009% of its original size (1,048,620 bytes to 8,431 bytes) but I did not include it in the shot).
[attachment=9648:LSTGARes.png]
Here are .PNG files recompressed as .LSI. When the .LSI file is larger than the .PNG file (or whatever the source format is), the converter uses the original file, so the percent is 100%. That means .PNG won.
[attachment=9649:LSPNGRes.png]
With .PNG it is often close, and .PNG sometimes wins, but .LSI wins often as well, and sometimes by quite a large margin (as low as 25% in this case).
L. Spiro
Image compression
Here are some images and their ratios.
.PNG = 40,725, .LSI = 45,094 = 110.72%
[attachment=9654:CORVETTEZ06 RIM.png]
.PNG = 32,865, .LSI = 29,990 = 91.25%
[attachment=9655:CORVETTEZ06 BADGING MASK.png]
.PNG = 14,460, .LSI = 5,209 = 36.02%
[attachment=9656:TIREBACK.png]
.PNG = 55,564, .LSI = 44,546 = 80.16%
[attachment=9657:TIRE BUMP.png]
.PNG = 99,420, .LSI = 130,098 = 130.86%
[attachment=9658:CORVETTEZ06 BRAKELIGHT.png]
Photographic images tend to be larger than .PNG, but I haven’t seen any go above 175% yet, which is still quite acceptable given how small .PNG’s are.
On the other hand cartoony images and masks compress very well compared to .PNG’s.
Normal maps are generally similar in size.
L. Spiro
.PNG = 40,725, .LSI = 45,094 = 110.72%
[attachment=9654:CORVETTEZ06 RIM.png]
.PNG = 32,865, .LSI = 29,990 = 91.25%
[attachment=9655:CORVETTEZ06 BADGING MASK.png]
.PNG = 14,460, .LSI = 5,209 = 36.02%
[attachment=9656:TIREBACK.png]
.PNG = 55,564, .LSI = 44,546 = 80.16%
[attachment=9657:TIRE BUMP.png]
.PNG = 99,420, .LSI = 130,098 = 130.86%
[attachment=9658:CORVETTEZ06 BRAKELIGHT.png]
Photographic images tend to be larger than .PNG, but I haven’t seen any go above 175% yet, which is still quite acceptable given how small .PNG’s are.
On the other hand cartoony images and masks compress very well compared to .PNG’s.
Normal maps are generally similar in size.
L. Spiro
Since nobody bothered to do so till now, I ran a simple pngcrush -brute over some of your pictures.
(I only compressed the pictures that are "bigger" than your self-compressed ones.)
The results are:
25.800 Bytes
[sharedmedia=gallery:images:2462]
10.155 Bytes
[sharedmedia=gallery:images:2463]
47.562 Bytes
[sharedmedia=gallery:images:2464]
So, your own algorithm does not fare that well against a more correctly use .png.
Even though 2 of the examples are still bigger than yours (even though we have to belive that you don't lie to us since you neither posted one of those pictures or any other proof.) png still wins in most cases and has the benefits of being a free specification.
EDIT: Sounds a little bit provocative, don't take it too seriously, I just like the topic.
(I only compressed the pictures that are "bigger" than your self-compressed ones.)
The results are:
25.800 Bytes
[sharedmedia=gallery:images:2462]
10.155 Bytes
[sharedmedia=gallery:images:2463]
47.562 Bytes
[sharedmedia=gallery:images:2464]
So, your own algorithm does not fare that well against a more correctly use .png.
Even though 2 of the examples are still bigger than yours (even though we have to belive that you don't lie to us since you neither posted one of those pictures or any other proof.) png still wins in most cases and has the benefits of being a free specification.
EDIT: Sounds a little bit provocative, don't take it too seriously, I just like the topic.
I haven't heard of pngcrush before, but apparently it has lots of room for improvement. I ran the images through pngout and optipng, and this is the result:
18,022 bytes
[sharedmedia=gallery:images:2465]
4,303 bytes
[sharedmedia=gallery:images:2466]
32,768 bytes
[sharedmedia=gallery:images:2467]
18,022 bytes
[sharedmedia=gallery:images:2465]
4,303 bytes
[sharedmedia=gallery:images:2466]
32,768 bytes
[sharedmedia=gallery:images:2467]
also aimed to try it with optipng, similar to what L.spiro does, it 'losslessly' reduces the images to as few colors as possible before it starts the binary compression.
in cases where this is not possible (photography), png was better anyway. which leads to: the lzw algorithm used in LSI is not reaching the compression ration of deflate in png, which shouldn't be of a surprise, the way it combines lz77 with huffman is very smart, IMHO.
in cases where this is not possible (photography), png was better anyway. which leads to: the lzw algorithm used in LSI is not reaching the compression ration of deflate in png, which shouldn't be of a surprise, the way it combines lz77 with huffman is very smart, IMHO.
Even though 2 of the examples are still bigger than yours (even though we have to belive that you don't lie to us since you neither posted one of those pictures or any other proof.) png still wins in most cases and has the benefits of being a free specification.
EDIT: Sounds a little bit provocative, don't take it too seriously, I just like the topic.
I admit that I just used the .PNG images as they were in the model packages I got. I assume these represent the average use case.
I am not too disappointed at slightly losing to .PNG in lossless form (lossy compression still wins handily with pretty nice results). I will have to update my posts and blog, but the main point is that these are practical and easy-to-implement ideas for getting small image files while maintaining losslessness.
I have a few more ideas that were more complicated to implement so I have been putting them off, but maybe I will implement them soon and see how they fair against aggressively optimized .PNG files.
Also, my images will be “free specification” soon. I am not keeping secrets etc., which is why I documented the algorithms roughly in the first place. I will get around to making Photoshop plug-ins and an official specification eventually.
L. Spiro
yeah, you are right and it's sad that most tools don't have even minimal optimizations for png, just vanilla libpng mostly!
I admit that I just used the .PNG images as they were in the model packages I got. I assume these represent the average use case.
I am not too disappointed at slightly losing to .PNG in lossless form ... but the main point is that these are practical and easy-to-implement ideas for getting small image files while maintaining losslessness.it's easy, but from the algorithm point of few it's also inferior as you use very basic compression ideas. you should read how to combine LZ.. algorithms with entropy encoded algorithms like huffman and artihmetic encoding. additionally some transformations like burrows wheeler transform, move to front, prediction coding etc. are very simple to implement and can be done as a pre-step to optimize the data for better compression ratios.
beside compression ratio, it's also important how fast it is to compress/uncompress and how much memory you need. png is very memory friendly, it works in tiny chunks of 64kb, which can be implemented on SPUs of the CELL (PS3), and also on embeded boards, even on GBA some games used it.
...(lossy compression still wins handily with pretty nice results). ...feel free to post a png image of a previously lossy compressed LSI. I'm sure png will win once again.
I have a few more ideas that were more complicated to implement so I have been putting them off, but maybe I will implement them soon and see how they fair against aggressively optimized .PNG files.[/quote]you should first find out how exactly png works, to not reinvent the wheel, because the first few times, you will be inferior if you don't learn from previous work of others,my 2 cent.
Also, my images will be “free specification” soon. I am not keeping secrets etc., which is why I documented the algorithms roughly in the first place. I will get around to making Photoshop plug-ins and an official specification eventually.
[/quote]
may I suggest that you stop writing a proprietary format that probably nobody will ever use beside you and invest your time into a good png optimizer? your quantitization algorithms will probably work just as good if afterwards compressed with png, as they would work with LSI, but the ratio is probably better. Beside that, png has still a lot of potential to reach higher compression ratios and if you do it, your png-L.spiro plugin might be used by a lot of people. Isn't that the whole point of making something public?
I don't wan to kill your fun or motivation, just some suggestions ;)
I think we have a misunderstanding.
My goal was never to beat .PNG. I know how it works (I wrote the decoder I am using for it) but that was too much trouble considering my goal: A format suited specifically for games, but still small in size for mobile devices and lossless for quality.
That means direct support for a lot of common formats used in games such as R5G6B5, A8, A8L8, R8G8, R16B16G16A16, etc.
That also means embedded mipmaps.
As for who may or may not end up using my plug-in or format, the goal of my engine is commercial and if it does well enough I will use it to start a middleware company. So it would be unhealthy for me to doubt whether or not people will end up using it.
Right or wrong, everything I make is made with the assumption that people will be using it someday.
Maybe someday I will get around to writing an encoder for .PNG and start applying it to my format, but I have a lot to do—I haven’t even had the time to finish my DXT compressor and make a release—so it is not a high priority right now.
L. Spiro
My goal was never to beat .PNG. I know how it works (I wrote the decoder I am using for it) but that was too much trouble considering my goal: A format suited specifically for games, but still small in size for mobile devices and lossless for quality.
That means direct support for a lot of common formats used in games such as R5G6B5, A8, A8L8, R8G8, R16B16G16A16, etc.
That also means embedded mipmaps.
As for who may or may not end up using my plug-in or format, the goal of my engine is commercial and if it does well enough I will use it to start a middleware company. So it would be unhealthy for me to doubt whether or not people will end up using it.
Right or wrong, everything I make is made with the assumption that people will be using it someday.
Maybe someday I will get around to writing an encoder for .PNG and start applying it to my format, but I have a lot to do—I haven’t even had the time to finish my DXT compressor and make a release—so it is not a high priority right now.
L. Spiro
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
