There are a bunch of tools available:
With data uris, you're putting the image data in your css file. This creates two performance differences to images.
Firstly, the user will download the image data even if it isn't used on the page, an external image is only downloaded if it's element is present & visible.
Secondly & more importantly, browsers completely block rendering while CSS downloads (with the exception of Opera, which unblocks after about 3 seconds), CSS does not render progressively. A 10k CSS file with 60k of imagery will load slower than a 70k CSS file due to HTTP overhead, although it'll be perceived faster as the user sees things happening after 10k rather than looking at a blank screen until the full 70k has downloaded. Small numbers, but noticeable on flakey wi-fi and mobile connections.
In terms of image size, when you base64 encode an image you're using 8 bits of data to represent 6. Gzip deals with a lot of this, but it's still an extra ~10% per image. That's compared to separate images, with a sprite image you get further benefits by sharing a PNG palette and compression across all sprites.
Neither sprites or data uris are the "correct solution" in all situations, it should be considered on a case by case basis. Sprite Cow itself uses both techniques, the toolbar icons are in a sprite, some smaller tiling assets are data uris.
In general, this is a process best curated manually, with a maximum on converted file sizes and hand-picking images that are "must-haves" for the initial page load.
The app gave you that message because Mobile Safari doesn't have a file picker. That'll change in iOS 6, which will be released within the next few months.
"Sorry, it isn't working out between us
It's not you, I just can't get along with your browser. Maybe if things change in the future... maybe if you bring Chrome, Firefox, Opera or even IE10 to the party... not promising anything, but give me a call.
pass <canvas> element
fail File & FileReader
pass addEventListener on elements"
However, I still up-voted this article because of all the good suggestions other people added for good sprit generators.
For example, I had to generate a 100+ icons sprite (24x24px, 48x48px and 96x96px). All I had to do was:
1. Zip these icons
2. Upload the file
3. Define the offset (in this case 2px in order to have round numbers)
4. Choose a CSS Class prefix (using the icon size is quite handy)
Set the VM's network to a bridged adapter and can easily access it from my browser.
I don't remember if It comes with css output, but if not it should be really easy to plug it in as it was designed for that. It does come with an ant target. (http://opensource.cego.dk/spritemapper).
The primary benefit of this tool is that it automatically lays out your images for you and, since it's all client side, doesn't require you to share your images with an untrusted sprite generator.
I found the following site a lot easier if you just export all the individual icons in bulk, it then auto generates the sprite and the positions needed for your CSS:
[Firefox 14.0.1 - Windows 7]
Of course, it's open source, any optimisation suggestions will be gratefully received. The calculation of sprite boundaries happens in two steps, first a contraction https://github.com/jakearchibald/sprite-cow/blob/master/www/... then an expansion https://github.com/jakearchibald/sprite-cow/blob/master/www/...
Solving these kinds of problems and optimizing things makes me happy. I'll take a look at this when I get home from work and see if I can speed it up.
CPU time is super expensive where I live.
>Let me guess, you're the guy who bitches when the WiFi is down on the airplane.
We will no longer have to deal with all this BS once browsers implement CSS3 image values. (http://www.w3.org/TR/css3-images/) Syntax would be like: `background-image: image('sprites.png#xywh=40,0,20,20');` Share single image across your site/stylesheets. No need to set a fixed width/height. No background-repeat restrictions etc