I made this by gradually evolving a picture using only quads, but it doesn't help you at all :D
In all seriousness though, your problem may be a variation of the
packing problem which is, I think,
NP-hard.
edit: You should probably just try to implement pixel perfect collisions.
I actually remember reading about this in another thread and actually went looking for it before posting my original message.
Looks very nice!
I'm currently trying to make a program to do what I want. The algorithm I'm currently pursuing is dividing the image into a bunch of squares (4x4 pixels, as that's the collision movement resolution I'm using), then mark all squares that only have pixels with alpha > 0.5, and then connecting these marked squares into larger squares. I think this should work in theory, but time will tell.
As to pixel perfect collision: that will be too slow for what I have in mind (I'll have to do a
lot of collision checking). My multiple squares approach worked really well in the test I did (where I manually calculated the squares). It's really fast and I actually like it better than pixel perfect collision, as it doesn't always register the hit as soon as the bullet reaches a pixel, but sometimes further "inside" the image -- this almost gives it a 3D effect, as you seem to not just be hitting the edges of the sprite, but stuff
on the sprite.
It's not exactly what you're after, but I've previously had luck exporting a path from GIMP to svg and using the svg data to build collision geometry.
Sounds interesting, but also sounds slower than just checking the bullet X,Y coordinates against 10-12 squares...?