For instance, I dont know how I would store the data of each pixel. I'm wanting to do this because I plan to create a custom format for an OpenGL application. Also, I'm using the C++ language.

Yeah. The problem is that I wouldnt know how to turn an RGB/RGBA value into an unsigned byte.

Thanks for the info. For a second there, I thought you had to combine the r, g, b into one strange value (I'm thinking of something else though).

That's a Microsoft macro, and expands roughly into:

#define RGB(r,g,b) (((b & 0xFF) << 16) & ((g & 0xFF) << 8) & (r & 0xFF))

Yeah, you can just save the RGBA values directly to a file, probably with the width and height and format (RGB or RGBA, and color depth) as well. You might also want to preclude everything with a few "ID" bytes, so you can make sure you're loading a valid image. So your format might look like this:

ID String
width height
RGB or RGBA
color depth
pixel data

of course, this will almost certainly be in binary format, so it won't actually look like the above. But you get the idea.

Take a look at fstream in the stl.

Just don't do it.

There are lots of existing image file formats already, and one of them is likely to suit your needs just fine.

For example, there's JPEG for photographic lossy compression; PNG for pixel art lossless compression (with transparency) or paletted images; TGA for lossless images typically without compression but with full alpha channel, or paletted images; and DDS which supports pretty much any kind of uncompressed encoding you can think of (although only the DXT series of compression formats). There's TIFF to support storing pretty much any kind of bitmap data. There's PSD for storing multi-layered, tile-accessed complex image documents.

The benefit of using an existing file format is that you can view them in the Windows Explorer window; you can open them in Photoshop and change them around and save them out again; and you can mail them to your friends (or receive them from your friends) without any compatibility worries.

What possible reason could you have to create your own image file format, instead of using an existing format? Perhaps if you described to us what specific features you need of the file format, we could suggest an existing, well-supported file format for you to use instead of re-inventing the wheel.

Unless you're developing some wickedly brilliant compression scheme I would have to agree with the above posts, existing formats have most of the major bases covered. In the end you'll either have an index value pointing to a color table for each pixel, or you'll have so many bits dedicated to various color channels per pixel. Even with compression it will stil have to be converted to an array of color values at some point, so I would save my effort for more interesting problems.