I don't have one with me, but I use

typedef struct
{
 int width;   //pixels, not bytes per line
 int height;
 int color_depth; //in bytes, not bits per pixel
 int rgba;        //set to 1 for rgba (when color_depth == 4) or 0 for bgra
 int version;     //very helpful when you change this struct!
}TEXHEADER;

so size of image data is width*height*color_depth. You could also have another int for how many bytes past TEXHEADER the actual pixel data starts to make room for variable sized comment strings or something.

I just seen you want 5 frames, maybe add yet another int for how many times the pixel data is repeated?

[EDIT] I just remembered that the color_depth doesn't discriminate between 15/16 bits per pixel, but I don't use 15, or 8 for that matter.

Assuming for OpenGL:

rgba vs. bgra is the order the red, blue, green values are stored, Windows uses bgr and I've read on an Nvidia page that they've optimized bgr as opposed to rgb due to Windows. Some older cards may not handle the bgr order, check the flags. If you're worried about porting to other cpu's, you could either store/load the bytes individually or (probably faster) swap them around after loading from disk. I haven't had a big-endian computer (well, Motorola 8 bit doesn't have an endianness) but

union
{
 int a;
 char b[4];
}endian;

int is_small_endian = 0;

endian.a = 1;
is_small_endian = endian.b[3];  //little endian would set b[0]

That doesn't actually change the size of the struct in question (try a sizeof on it both ways, on any platform gcc supports today), and it breaks compatibility with some compilers.

edit: okay, I'm just whining pointlessly; the #define could be #ifdefed to something equivalent on another compiler to improve compatibility, and while packing it doesn't change this particular struct, it is vaguely appropriate for structs corresponding to formats on disk.

If you're going to be accessing the data of a struct manually, then specify the packed option. Don't do it and the god of coding karma will strike you down.

You might as well just use the struct name, unless you're trying to conform to an old C standard. typedef went out of style decades ago.

Different sized ints are always a problem.

It's gcc-only. There are equivalents in most compilers though. I don't know about Borland. Try looking up "packing" or "alignment", or anything about controlling the actual layout of structure members in memory in any docs you have.

Pretty much. It can effect the size of the struct in memory as well, but that's not usually important.

Some people find it easier to code / maintain / examine / debug / etc to let that happen automatically in a single fwrite call or whatever.

Some people use the structs with endian-independant integer types (ie plain ints on one endianness, #ifdefed to classes that emulate non-native endiannes ints on the other endianness). Not a very popular practice admittedly, but I know a few.