Mark Allen Neil.com

Posted 2009-10-23 in Web

Exploring the limits of SVG

While writing the last article, I wondered just how complex and arbitrary an image could be “handled” successfully by SVG. I didn’t want to get overly complex in my “introductory” article, so I’ve split the topic out into this second short discussion.

Rendering a bit-mapped image

Obviously any bit-mapped image can be represented as a vector image… at the extreme limit one could represent the image as a series of squares of different colors, each representing a single pixel in the original image. This would be rather silly however, as the memory and processing requirements of handling such an image would far exceed those of simply sticking to the more sensible bitmap form. Still, I thought it worth investigating.

So I took the picture of myself I use in the header of this website and found a few approaches to map it into an SVG image.

Vector Magic - mixed results

The first hit in a Google search for “convert bitmap to vector” identified a commercial solution called Vector Magic. The site offered to convert a few images online for free, so I had nothing to lose. After fiddling with settings for a bit, making trade-offs between time and size and quality, I produced the following:

The approach taken by Vector Magic is to render the image by identifying non-overlapping colored regions. While it isn’t a “bad” result, there are a few issues with this image… one obvious and one I’ll just have to explain. The obvious problem is that the border around each colored region isn’t explicitly defined… when I examine the SVG file I see that the “stroke” (border) for each region isn’t defined. As a result, if a region is slightly undersized, the background for the image bleeds through and each colored region seems to have a weird outline.

The second less obvious problem is the size of the image… this image as stored on the server is 745Kb… about twice the size of the original JPEG image. However as mentioned in the last article, with compression the image actually sent over the wire is only 240Kb… so smaller than the original, but not by much. In my opinion, given the less-than-acceptable quality of the image and the marginal improvement in storage/transfer requirements, it just wouldn’t make sense to save an image like this as SVG. Well, at least not using the approach chosen by Vector Magic. Note that I think the approach Vector Magic took to rendering this image wasn’t a bad one… a clever algorithm with just a minor flaw (the missing stroke). Rather the result is such that I believe that storing this sort of image in vector form is a poor idea.

Inkscape - no happy feet

So I repeated this exercise using Inkscape, the vector graphics program I mentioned in my last article. Inkscape has a function which can convert a bitmap image into vector form. The configuration options weren’t all that clear… and quite poorly documented… so it is possible that I set the conversion up incorrectly. But I doubt it. So experimenting with different settings I was able to produce the following:

Suboptimal to say the least. I could make the image better… a much better match to the original… but only with rather explosive growth in file size. One attempt yielded a 2Mb file, took a few minutes to convert, and was quite slow to draw. This last observation starts to factor-in when one considers that the browser has to read, interpret and draw an SVG file… a large file can put quite a strain on the local CPU. And I’m sure I wasn’t just seeing file transfer time, as I’m running both the browser and server on the same dual-CPU computer… internet bandwidth wasn’t a factor. I can say it was interesting to see the approach Inkscape chose to render the images. Rather than dividing the image into different colored XY regions, Inkscape appears to stack image planes up to render the image. More like an oil painting than paint-by-numbers.

Closing

So while it was interesting to explore representing bit-mapped images in vector form using SVG, I can’t say this approach makes much sense.

• Not much saved in bandwidth as the vector file isn’t much smaller than the bitmap file.
• Final images aren’t very good… not nearly as good as the bit-mapped originals… and not good enough for public consumption.
• Can put quite a load on the client’s browser… as a huge SVG takes local CPU to render.
• Finally, there is compatibility to consider. A bit-mapped image will display in virtually any browser. No such guarantee is true for an SVG image.