In the previous article, I investigated the file sizes of two compression methods. But compression is nothing, when you can’t decompress.
I took the next step. What does the image look like when decompressed in Silverlight?
Well, here are the results:
To the left is the image decompressed according to compression method 1. To the right is the same image decompressed, now with compression method 2.
As described before, compression method 1 is just the conversion of text-floats into binary floats.
Compression method 2 is more interesting. The text-floats are converted to binary short (Int16). In this experiment, it became clear how important precision is. When floats are casted to short, all numbers behind the decimal point are discarded. The first result looked bad.
In the second test, I multiplied every float in the data with 100, and then casted it to short. With the factor 100, you gain 2 decimal numbers extra precision, before cutting everything off. In the decompression, the input short is divided by 100 again and the resulting float is then used for the path data. The result of this factor-100 test is displayed at the right side. The multiplication factor can’t be too high though, because an Int16 is limited to -32,766 until 32,767.
In my image, the largest number is 318, which fits in the Int16 range with factor 100. Most numbers lie somewhere between -15 and 15. Also, the larger numbers are used for the M command, while the other commands use lower values. So to improve this compression technique, we should sometimes allow floats to be converted to floats, while the lion-part of floats is converted to short, with the best precision factor. As long as the results give better compression than PNG, it is the right way to go.
Other considerations
Make sure you have read the previous article before reading this paragraph.
In the previous article, I used the Simplify function in Inkscape. Also, for every test, I scanned the original bitmap with option “Smooth” checked, and scans=12. One also needs to consider these options, because they affect quality.
Unchecking the Smooth option in Trace Bitmap, gives a better quality vector image, for the image I’m testing with, making the saved XAML and the compressed XZ file much larger. But hey, the amount of scans does not have to be 12. Perhaps it could be 11, discarding one color layer and lots of floats.
The above shows an interesting result. To the left is the original PNG of 16KB. To the right is a decompression result in Silverlight. The right result was produced with Smooth unchecked and scans=11.
The compressed XZ file is 46KB. Zipping this XZ file results in a 14KB file, still a little smaller than the original 16KB file. So the lesson to learn is that this compression technique might indeed work, but when used incorrectly, it will produce larger files than the PNG original.
Subscribe