Just after posting the previous article, I did a new experiment. Obviously, the quality of the resulting image was very, very bad. And the method described to improve quality, had such a low result in file decrease, where you could question whether this method is worth its while. But an important thought is, that you must know how to use your tools, to get the best results for both compression and quality.
The first article used option “Smooth” checked, for the “Trace Bitmap” function in Inkscape. This option obviously decreases the quality of the result. Also, in the first tests of the first article, the function “Simplify” was used to decrease the amount of vector points, but making quality even worse.
How to get better quality with less points? The answer is, use the Simplify function in Inkscape, but this function must remove lesser points. As the Simplify function in Inkscape does not have an options screen, where you can program this function to remove lesser points, we will need to influence this desire from the outside.
The character in the original PNG is actually a 3D model. Animation-frames are outputted at 40x40 pixels, and then concatenated in the vertical direction. For this experiment, I outputted animation-frames at 80x80 pixels and concatenated them. The image is now twice the size of the geometry which I intend to use in my Silverlight game.
This image was used as input for the whole Inkscape process:
1) Import Bitmap;
2) Trace Bitmap, Smooth=unchecked, Scans=11, Remove Background;
3) Simplify;
4) Save as XAML;
Because the input image in this process now contains more detail, the simplify function in step 3 will decrease less quality, than if we’d used this simplify in the original, smaller image.
After the result was saved as XAML, my compressor created an XZ file, with the compression 2 method, and then showed it with my Silverlight decompressor. The first result was very bad. With a larger picture, the factor=100 overflowed some values beyond the Int16 borders, breaking the image. I used factor=10 instead and to my surprise, this lower precision didn’t affect the quality of the image very much.
This is the result for my decompressor, with factor=10 and the result being scaled to 0.5 (because the original is twice the size we want to use).
This is the visual output:
Well, that quality is not very far from the original PNG with 40x40 frames, 16KB.
These are the file stats:
The name of the files used is “MrA_Large”. Compressed and then zipped, it only takes 8KB, while the original PNG was 16KB. These values may be compared, because the 40x40 animation frame is my target in the game, while the path to achieve this, is of lesser importance, as long as we can use the method for all or most of the images.
By using an image twice the size of the image we want to use, we put more detail into the picture. In Inkscape, the simplify function now worked on this more detail, leaving enough detail after its execution. As far as the simplified image has glitches, these were hidden when the end result was scaled down with factor 0.5. The end-result is quite statisfactory, and the compression/decompression algorithm hasn’t even been optimized to make even smaller files.
A compression of 50%, well, for my testcase that is.
As we’re now using factor-10, to convert floats to short, the numbers in the vector data must be between -3276 and 3276. With larger numbers, the numbers will overflow and corrupt the image. However, this limitation is relative. How many images need a resolution larger than 3200x3200? If there are such images, perhaps further optimization of the compression algorithm might overcome this limitation.
One thing is for sure, this method works for this image. The next step is testing more images and study the results.
The graphics in the game Slengo occupy 2.04 MB. If I could slash that with only 40%, while keeping an acceptable image quality, then this method would definitely be my choice.
Subscribe