What sort of tools/processes are used for setting up hitboxes and make them move/resize/appear/disappear to match the character animations? I'm working in 2d, so attaching collision volumes to the character in a modeling program are no good for this case :).
This may be much heavier than you need, but here's how we do it. We stick to AABBs for simplicity... (The terrain is more arbitrary than AABBs, but almost all objects stick to AABBs. They might be bigger or smaller than the sprite, but it works quite well with some tuning!)
The pipeline supports several types of box:
Each of these boxes is per-frame, per-animation. If they don't change across an entire anim we only store them once with the first frame and a note that they repeat.
The artist/designer-facing tool, which aggregates all the sprites and a bunch of metadata, will help you with the collision box. In automatic mode it will simply snap the collision box to the "outermost non-transparent pixels" in a given sprite frame. In manual mode you can tweak the box however you like. There's a "magic wand" button for snapping it back to the outermost non-transparent pixels again.
You don't have to have any given box for any given frame if you don't want it.
(Note: it's also useful to track a "reference point" for sprite placement -- you can treat your character coordinates as bottom-center, or maybe you're dealing with a button and you want to place based on the center of the sprite, etc... Helps with setting up UIs and uniformity in moving characters around -- characters are usually hauled around by bottom-center.)
This info is exported into an intermediate xml-based format, and then baked by a subsequent tool into a binary format appropriate for the target platform.
All of these reach the game and then use a simple quadtree-like space partition system to do their testing vs. one another.
It's definitely possible to add a deeper pass to do pixel vs. pixel tests after the AABB pass if you need it.
What tool are you using for authoring your sprites? If you're using GIMP or Photoshop, you can easily have the artists paint hit areas as a separate named layer. You would then write a tool as part of your content pipeline to:
The PSD format can be found here: http://www.wotsit.org/list.asp?search=PSD&button=GO!
Of course, you could always have the artists export the layer manually to a standard file format that's easier for your tool to read, but we all know how artists love having manual processes forced down their throats :)
One easy/semi-hacky solution is to not use hitboxes but instead do a pixel test for you given sprite. Basically you set up some alpha threshold and if the alpha value of a given pixel closest to the area you need to test against is greater than that, you've collided with it.
A better approach I've used in the past is to just set up an array of points per tile (in your case, per frame) that signifies where the edges are. You generate line segments out of that and do arbitrary n-gon testing for your collision.
Barring that, you'll probably have to write your own solution to save out exactly what you're suggesting, i.e. bounding volume type x with properties y at location z for sprite w. It heavily depends on what your specific needs are.
I would use an aabb-point test to single out which model(s) that I'm potentially hitting, and then do a pixel-test on those models.