STATIC.SPR

FILE HEADER
	   bytes: value
----------------------------------------
HEADER
 1	 4 bytes: 0, due to absence of animation header section
 2	 4 bytes: 12, offset for the "image offsets" section
 3	 4 bytes: offset for the image section
IMAGE OFFSETS
   406 x 4 bytes: image offsets (from start of image section), the last one of these
		  offsets points to the end of the file.

IMAGES
ID	   bytes: value
----------------------------------------
IMAGE HEADER
 1	16 bytes: 0 (?), changing it doesn't seem to have any effect
 2	 4 bytes: image width
 3	 4 bytes: image height
 4	 4 bytes: nr. of starting empty columns
 5	 4 bytes: nr. of starting empty rows
 6	 4 bytes: nr. of columns (= width up to the last non-empty pixel)
 7	 4 bytes: nr. of rows (= height up to the last non-empty pixel)
 8	 1 byte : always 0xFD, seems to have something to do with the transparent pixels
		  (only those that are actually present in the image encoding, not the
		   "assumed" transparent pixels at the start/end of the rows/columns
		   of the image)
 9	 4 bytes: image body size
IMAGE BODY ([img header value 7] - [img header value 5] rows)
 1	 4 bytes: nr. of empty bytes~~
 2	 4 bytes: row data size (= N)
 3	 N bytes: row image data**
IMAGE FOOTER
 1	10 bytes: 0 (?)

~~ This number of bytes corresponds with half this number of transparent pixels (since the image is 16-bit, or 2 bytes per pixel).

** The image data is in 15+1 bit format (in Big Endian byte order that would be: 1-5-5-5). The first bit indicates whether the pixel's shade is changed to the civ color (1) or not (0). The other 15 bits are 5 bits each in the order R-G-B.
Transparent pixels are represented by magenta (Little-Endian 0x1F7C or Big-Endian 0111110000011111).



UNITXX.SPR

FILE HEADER
ID	   bytes: value
----------------------------------------
HEADER
 1	 4 bytes: 12, offset for animation header section. Since that section
		  isn't in Static.spr, it probably has to do with the animation aspect.
		  Such as telling which images belong together in an animation, and
		  how long each of those frames should be displayed.
 2	 4 bytes: offset for "image offset" section
 3	 4 bytes: offset for image section
ANIMATION SECTION
 1  32 x 4 bytes: offsets for per animation information.
		  (8 facing directions x 4 actions = 32 animations)
		  The actions are, in order: Attack, Die, Idle, Move.
		  The directions start at North, continuing
		  clockwise to end at Northwest.
		  The offsets indicate first all directions of Attack, then the animations
		  for Die, then Idle and Move.
		  NOTE: The offsets need not necessarily be in ascending order, or even
		  different. You could let the file contain only one animation, with all
		  actions and directions using the same one.
 2   X x 4 bytes: for each frame in an animation...
		  1.	points to the Nth (zero-based) image in the file.
			That means two things: there can't be more than 256 images in an
			animation file, and more interestingly, you can reuse frames.
		  2.	This seems to be a "flag" byte:
			..1. ....	marks a "start loop" frame
			.1.. ....	marks an "end loop" frame (loop back to last start)
			1... ....	mirrors a frame (horizontally)
			...x xx..	these 3 bits control transparency:
					000 = fully visible ... 111 = fully transparent
					(used for fading out dying units)
			[The remaining two bits are used in the resource file at least, but
			I don't know for what yet.]
		  3-4.	This seems to be a short integer/word also used as a flag of some
			sort. It is mostly 6.
		  It seems as if a fade-out animation must end with the sequence 0000 0001.
		  It doesn't seem to be possible to control frame rate, e.g. Die animations
		  often have two of the same frames following each other, which makes the
		  animation twice as "slow" as the others.
			
[...]
IMAGE OFFSETS
     X x 4 bytes: image offsets (from start of image section), the last one of these
		  offsets points to the end of the file.

IMAGES
As in Static.spr



RESOURCE.SPR

This one's pretty much the same as the units sprite files. Some extra notes:
If a resource doesn't have animation, the corresponding header value points it to an empty animation (hex sequence 0020 0001, 0001 probably means something to the effect of "don't display me", the 20 part is the "start loop" flag).
While the unitXX.spr has the first part of the animation header nicely in ascending order of offset, the resource.spr has that section in pretty random order. Plus, a lot of the animations are empty, so the animation "summary" points all of those to a final entry in the frame information part.

The first part of the animation header is obviously different from the units:
 1  88 x 4 bytes: (4 maps x 11 terrains x 2 resources)
		  In the following order: first resources of first map (following
		  regular terrain order from Desert through to Ocean), second resources of
		  first map, first resources of second map etc.