SpriteGen

SpriteGen - Implementation Part 1

Admin — Tue, 20 Nov 2007 06:39:49 GMT

Alright, well I've reached a point now in the implementation of the JHeidt.Utilities.Web.CssSpriteGen library where I feel comfortable not only sharing my implementation details, but hopefully some starter code to get down to the idea of the design behind it. If you haven't been following my posts on the subject, SpriteGen is an extensible library of which the goal is to take a series of images from a given input source and generate a packed raster representation of those images along with the requisite CSS rules and XHTML examples to showcase them, for your use however you please.

There currently exist a few services for creating CSS sprites, but the whole goal of CSS sprites is to allow for quicker loading of images/styles on the client side, by cutting down on request calls / upstream network bandwidth. So here is the first unequal size inputs packed image example and result, showing how I minimize the image output size by using bin packing techniques:

These images were taken, (without express written consent, but in the hopes of promoting them) from http://microformats.org/wiki/buttons. Please learn about microformats and help spread the word as well about helping make the web a contextual, and data rich environment.

Well - Here are the source images.
Note the varying height and width:

Source Image Zip: Source Images.zip

The total area for these combined input images is 89442 pixels. A perfect packing of these images (which is quite probably not possible for these inputs) would yield an image of that area.

Below we get the image that was created by SpriteGen. The ImageLoader for this case was the DirectoryImageLoader, with the default options. Image loaders provide a set of base image searching, preparation, and validation functions, and there are more options and specifics for the base and custom image loaders.

The DirectoryLoader has options for max input file size, max directory iteration file processor count, cutoff at combined total input area, max binary result size, file mask, and even more - the reason for these configurable settings was the expectation that people could use the spritegen online, perhaps forgetting to shrink an image, or upload an invalid zip file, or just downright abuse. It's important to note that I've created 3 ImageLoaders for SpriteGen so far, but the fully functional ones right now are the DirectoryLoader and the ZipFileLoader.

I can see creating a UrlScrapeLoader that could parse images from a remote web site and it's css to generate the packed images and CSS for that site as just a dead-lazy gimmegimme sprites hookup, but that's further down the road ;). Also, additions that I think would be useful would be the ability to generate output images grouped by input type, or to detect non-alpha & per-pixel alpha images and group them in with gif/JPEG raster groups as required, again to save bandwidth, so these will be looked at.

So - without further ado, here is the pack image result (output: PNG/full alpha - this can be adjusted or even broken down to separate outputs from a set of input images) This output doesn't showcase the SmartBackGround functions ability to determine repeated/repeatable background images, such as vertically aligned 1px wide, 2px+ high images as repeat-x backgrounds and vice versa for repeat-y via 1px high, 2px+ wide images. Using the smart bg function these qualifying images would optionally be generated in a separate image file, to allow repeatability and also to maintain minimum file size, however options like these are fully customizable depending on how you prefer your output images in case you wanted them included in the packed image. (More on this later)

Final image: 72.4K.

Final image area in pixels is 93120 (240 * 388)

*Please note that my blog post software doesn't seem to like the PNG alpha in these images, but I assure it's there - click the image to open it and see for yourself. Also of note here is the detection of per-pixel alpha in the source images and producing the correct image format out.

Here is the resultant image from a similar online sprite generator:

Final image size: 84.8K. Final image area: 482880 (240 x 2012) - also note there seems to be some unexpected behavior around a few alpha-blended buttons, but I'm sure this is being addressed, or is already addressed, at the time of this post, stuff like this is relatively minor.

So you can see how this packing can be beneficial - the whole idea here is to clamp down on extraneous client requests to the server, but also to reduce the overall bandwidth (and subsequent load times) for images from our sites. The packing saved 12.4k for the same set of input images.

Example CSS and XHTML gets generated as well, with some good comments and recommendations to those might be a bit confused about this code, or how to use it in their project. I'll discuss this aspect of the SpriteGen next.

SpriteGen Update

Admin — Tue, 13 Nov 2007 05:13:47 GMT

Alright, well I've implemented everything necessary, including all of the configuration code, for the base SpriteGen to work. So, as soon as I get some ghetto pages together to allow you to upload a zip and process it, I'll let you know via an update here. However, the way the SpriteGen queues work items and notifies you that 'your sprites are ready' will likely be changed, due to the fact that I eventually expect some decent traffic coming through and using it. The packing algorithm is pretty slim and easy, but who knows how hard it would make my web server work with 20 concurrent requests.

Stay tuned for the URL to the SpriteGen.

Creating CSS Sprites, An Intro

Admin — Mon, 05 Nov 2007 02:55:24 GMT

If you are not familiar with CSS sprites, I can think of no better place for an introduction than this article on A List Apart. In short, you place many images into one image file, and then use that image as a background image and modify its position using background-position attributes. The only problem with the process is that its quite laborious, and really is robot work. While I was working on some html design a few weeks ago I became frustrated at this process, so I decided to figure out a way to automate it.

Now, admittedly, there already exist a few CSS sprite generators on the Internet, but in my opinion they left something to be desired. The big reason to create CSS sprites is to cut down on relatively sizable http requests (in comparison to the small images they may be requesting), in favor of one image that will be cached on the client side. A sweet side effect of this is that rollover images states don't require any JavaScript client-side code to preload any images, the browser takes care of it in the original image download. The problem is, in my experience, the existing generators don't actually save any bandwidth. By inefficiently placing the images into the output image they actually end up adding a bit too much to the final image output size. While doing research as to how to minimize the output of such an image placement algorithm I ran headfirst into a fun computational challenge. The problem is a NP-Hard computation that is known as the bin packing problem. Fortunately, placing images that I have a list of is known as an 'offline' bin packing problem, meaning that I have the full set of inputs and I can generate a relatively decent output image from it.

When I was researching how to place the images, I read a great series of e-mails from a mailing list in which Clive Tooth explains an intuitive algorithm:

The new method works by sub-dividing the remaining part of the original rectangle into sub-rectangles and then, when a new square is to be inserted, choosing one of the subrectangles which will completely hold the square and then positioning the square at the top left hand corner of the rectangle. The remaining L-shaped part of the rectangle is then partitioned into two rectangles. Occasionally one of the two new rectangles may have a zero height or zero width, but this does not matter. Thus at each stage one rectangle is used and replaced by two smaller rectangles. Thus, just before inserting piece n, the remaining space will have been split into n rectangles. So, we would need to prove that at that stage at least one of the rectangles had a short side of least 1/n.

In short, as long as you have the correct size to output to, you can place a rectangle inside that output with decent efficiency. In further research I found that the output image was proven to never be more than 70% inefficient, but in practice in my tests it's actually been much closer to 20% or so. I also created my own algorithm for generating an estimate output rectangle size for containing a list of images, that seems to correctly guess the output size.

Within a few days I hope to show some code, but for now here is a little taste of the output of 16x16 images from the awesome silk icon set:

Note that this doesn't show any of the more intricacies of the algorithm, but it does show where I'm going with it.