Then:
In Flare3 we used 'tabled' images, like so.
[0,0][1,0][2,0]
[0,1][1,1][2,1]
[0,2][1,2][2,2]
with all of the frames in a single image, this made referencing an image simple, using an ordered pair (x,y) and you only had one image to worry about. Each 'action' would be it's own image, with frames as columns and directions as rows.
The problem?
The big issue with this method, is that the size and shape of the actual image is very determined on what you are planning to do with it.
For instance, imaagine a 128x128 frame size and a set of 20 images.
[0][1][2][3][4][5][6][7][8][9][10][11][12][13][14][15][16][17][18][19]
to store this image it would require a 2560x128 sized texture. Which does not play well with 3D hardware, and under some cards may not be possible at all.
Now:
The alternative to this, is to provide an interface of similar ease (rows and columns), but with a more free-form storage system, namely, induvidual frames.
So in order to do this we use XML to define an ImageTable, it works much like an HTML table, whering the table cells contain the information of what image file to use.
Or will you keep, for example, all frames of an attack cycle in a single image? That should keep the image size in working bounds without having to do lots of additional, performance eating, texture switching.