# How can I handle sprite sheets with nonuniform sprite dimensions?

For a spritesheet with non-uniform sprite dimensions, how can I get the bounding-rectangles for each individual sprite (i.e. the blue boxes in the following image / I only drew a few examples)?

What I would like to determine are: offset_x, offset_y, width, height

So far, I have only used spritesheets on which all sprites have identical dimensions. In that case, one simply needs to specify the x- and y-offset to get a particular sprite. However, for spritesheets of non-uniform dimensions this doesn't work.

EDIT: Having read through the comments and answers, I rephrased my question to make it more inclusive wrt. the actual process of using a spritesheet in a game. Previously, the question contained the points why people produce spritesheets of non-uniform dimensions and how I can deal with that.

• It looks to me they all have identical sizes, the space that isn't being filled in by colour is just pixels with the alpha set to zero. – Derek Jan 22 '12 at 16:23

Most sprite sheets of non-identical dimensions usually have some kind of meta data with where the anchor of the sprite is. There are a lot of tools that do things like strip out full alpha pixels and give you the data you need so that this data isn't manually generated.

If you don't have this meta data you have to author it yourself. The most accurate way is the one you said in your question, which is to just do it by hand. It may take a while, but it's probably faster than making new sprites.

• This - while approaches based on auto-detection have their uses, in practice they're finicky and error-prone. You already need metadata for the origin of the sprite (your sprites do have an origin, right?), so extra data is hardly too much of a burden. The artist should always know better than your app what the size of individual sprites is. – Steven Stadnicki Jan 24 '12 at 19:15
• +1. Supplying metadata with the sprites is guaranteed to solve it sanely. – Bartek Banachewicz Jul 31 '13 at 11:16

You can perform analysis on the image to locate the bounding rectangles of each sprite, sort those bounding rectangles (perhaps by increasing minimum X, then Y) and you'll have a set of bounding regions that correspond to the frames of the sprite sheet.

Because this process can be relatively expensive, you will probably want to do this offline, for example as part of the build process for your game. You can then serialize the bounding region information into a file that you store with the corresponding sprite sheet image. At runtime you load both the image and the boundary definition file and you have the information you need to access each individual sprite.

That is easier said than done, though. Essentially you'll want to do feature detection and specifically blob detection which are machine vision problems. You could also threshold the image (to black and white) and use an edge detection technique. The relevant math behind those techniques is explained far better on those links than I could, and in the case where you don't feel up to implementing that math yourself, there are a few libraries available that can assist you. The following set of links seemed the most promising to me:

• +1. I agree that it's going to require some computer-perception/image-manipulation skills to find the correct sprite bounds. Sometimes it might even be impossible, for example if you look at the turtle to shell animation. It's going to be hard to determine the correct position for that relative to the other animation frames. And as for the why: It's most likely because of optimal use of texture space. And usually a file with the coordinates should be supplied with such a spritesheet, but if you're simply grabbing it from Google image search, it might lack this information. – bummzack Jan 22 '12 at 17:51
• You raise a good point: my answer doesn't address the issue of sprite origins; it would just lead to finding tight-fitting bounding rectangles, and for a sheet with nonuniform sprites, knowing the origin of each frame is fairly important. This would be hard to do automatically unless you made some (likely domain specific) assumptions, for example that the origin would always be (width / 2, maximum Y) or something. – user1430 Jan 22 '12 at 18:04

I made my own tool for that kind of non-uniform spritesheet. It allows editing offsets, et cetera. Here's a screenshot to give you an idea:

• That looks like you create a uniform spritesheet containing only one animation from the non-uniform one? Or am I misinterpreting this? – Ben Jan 22 '12 at 21:14
• no, i open a non-uniform spritesheet and draw a rectangle around the sprites (which auto-shrinks to the correct size). Once ive created an animation by repeating that i can play each animation and adjust the offset according to my needs. – Anonymouse Jan 22 '12 at 22:55
• Seems like a very neat tool you made there. Mind to share the tool? – eckyputrady Jan 24 '12 at 1:06
• @eckyputrady, im sorry but it's far from being complete but i recommend another tool (which basically inspired me). You can find it here: colourclash.com/sprite_buddy/sprite_buddy.html – Anonymouse Jan 24 '12 at 6:48

Check out texturepacker

http://www.texturepacker.com/

It outputs a file like this (depending on your preffered settings)

    {
"filename": "image_front_1",
"frame": {"x":1,"y":160,"w":34,"h":52},
"rotated": false,
"trimmed": false,
"spriteSourceSize": {"x":0,"y":2,"w":36,"h":40},
"sourceSize": {"w":36,"h":40}
},
{
"filename": "image_front_2.png",
"frame": {"x":36,"y":160,"w":34,"h":52},
"rotated": false,
"trimmed": false,
"spriteSourceSize": {"x":0,"y":0,"w":36,"h":42},
"sourceSize": {"w":36,"h":42}
},
{
"filename": "image_front_3.png",
"frame": {"x":71,"y":160,"w":34,"h":52},
"rotated": false,
"trimmed": false,
"spriteSourceSize": {"x":0,"y":0,"w":34,"h":52},
"sourceSize": {"w":36,"h":42}
},
{
"filename": "image_front_4.png",
"frame": {"x":106,"y":160,"w":34,"h":52},
"rotated": false,
"trimmed": false,
"spriteSourceSize": {"x":0,"y":0,"w":34,"h":52},
"sourceSize": {"w":36,"h":42}
}


Using this data, you can easily grab the seperate rectangles from the image.

• This isn't a which technology to use question. Simply answering with a link to a tool and an example of its output isn't enough in my opinion. – MichaelHouse Jul 31 '13 at 5:31

spritebuddy.com has worked great for me. Couldn't find any help on the site itself, but this Google Groups post explains it really well. It auto-guesses the bounds for your sprites, lets you adjust it, AND lets you arrange them into animation sequences. Then it spits out a metadata file for all this in either JSON or XML. Then all you have to do is parse that data file in your game to get the correct bounding rectangles.

• This isn't a which technology to use question. Further, this tool was already suggested in one of the comments. – MichaelHouse Jul 31 '13 at 5:29
• I updated my answer, but I disagree that it doesn't answer the OP's question: "What I would like to determine are: offset_x, offset_y, width, height." Whether or not this must happen at game run-time (which would be terribly non-performant) or before is not specified. As to the "EDIT: [...] I rephrased my question to make it more inclusive wrt. the actual process of using a spritesheet in a game," this is my process. I generate the appropriate JSON file using spritebuddy then parse it in my game to obtain the data I need. – CletusW Jul 31 '13 at 6:08
• @CletusW: good answers would explain why that tool works so well for your process, what it does and how that helps, etc. I should be able to read your answer and then know how to select a tool or write my own. If you link to your favorite example, that's just a bonus, not the meat of the answer. – Sean Middleditch Jul 31 '13 at 6:58