I just need to say this: - The internet is pretty freaking amazing. If you want some utilities or source code to read virtually any file format, don't waste any time and go to http://myfileformats.com/. There are multiple resources at this site that, at a minimum, document the file format. Most of the resources actually provide source code to read and write graphics files.
Most file formats have the flexibility to store art in a wide variety of bit depths. The contents of each piece of art will dictate whether you should use 8-bit, 16-bit or 24-bit formats. The only format to watch out for is 16-bit, because not every video card uses the same pixel format for 16-bit modes. Most video cards on the market use a 565 format for storing RGB in 16 bits: 5 bits for red, 6 bits for green, 5 bits for blue. Some video cards, such as old 3Dfx cards, use a 555 format.
There's a great interview question I asked for many years that asked the interviewee to write the code to convert a 555 rectangular video buffer to a 565 buffer. Anyone who answered the question knows that there's an optimized solution for this question, but it still requires a few adds and shifts for each pixel, and therefore it wasn't too incredibly speedy. This means that you don't need to be converting your 565 art to 555 art every time you draw it; that would bring your game to a complete halt.
Since you can't count on either the 565 or 555 video card, you have to make a choice about how your art assets are stored, and what you want to do when your assets are stored in one format but the video card is the other. There are really three solutions and one fake solution:
Choose one format and convert if needed on loading the asset.
Choose one format and convert if needed on installation.
Store both formats.
Store every asset in 8-bit, and convert to 16 bit at load time.
The first solution is a pretty good one but you'll find that the conversion process will increase your load times. This actually got pretty bad on one project I was on because not only were we converting from 565 to 555 but we were also decompressing the asset as well, and it was a multiframe animation. The load time was pretty dismal on-low end machines, but there wasn't anything else we could do. The asset had to be compressed due to CD-ROM space constraints and we didn't want to penalize the vast majority of players that had 565 video cards.
If you ever thought about using Microsoft's BMP format to store graphics data, think again. The 16-bit format is a 555 format which will require conversion for quick display on most video cards. Of course, you can cheat and use the format for convenience and simply store 565 pixel data. You'll get some funky looking art if you load that munged BMP into MS Paint!
The second solution is really a non-solution, especially if your game runs in windowed mode. If your game player decides to change their desktop to a different pixel format you'll have to reinstall your whole game and reconvert everything to the new pixel format. That's just plain stupid. The third solution is a great solution if you have enough space on your CD-ROM and you've got some reasonable mechanism for keeping all these art assets in sync. If you rely on some manual process, you'll have thousands of bugs proclaiming that the art looks wrong, and you'll waste tons of time figuring out why.
The last solution is a good one too, if your art looks good in 8-bit. This can be a judgement call and can require a picky art director to lead you in the right direction. Look carefully at your largest art assets such as backgrounds, and convert them to 8-bit in something like Photoshop. If you still like what you see you can store it in 8-bit. Remember that storing 8-bit art is really storing art using 256 24-bit colors, so in many ways it's a better art format than 16-bit which uses two or three fewer bits. Also, you get the added benefit that if you want to support 32-bit resolutions your art will support that easily and you'll get the full monty! Converting the art to either 16- or 32-bit resolutions can be done with a simple lookup table, since you're only worried about a maximum of 256 different values for each asset.
The first solution is a good compromise, and it's the method I've used on every game I've worked on since I had to worry about it. We chose this solution because our backgrounds looked terrible when palettized, and the artists were really happy going to 16-bit art. There's no hard and fast rule, as with many things in game development, only tradeoffs.