Just out of curiosity, why don't you want to use standard image formats? If you go with a custom, you'll still need to write a tool to convert from a standard format to your own, which seems like a pointless complication to me. You could use a third-party lib like DevIL or SOIL to do the loading, and be done with it.

If you are dead set on rolling your own, you'll probably want to use a compression algorithm. Here, you have basically two choices: a lossy compression format such as what JPEG uses; the more you compress the image, the more data is lost beyond recovery, leading to the appearance of artifacts in the uncompressed image; or a lossless compression format such as what TARGA uses. Typical lossless schemes will use an RLE (run-length encoding) approach. In RLE, if you have a row of similar-color pixels that is 35 pixels long, for example, instead of storing 140 bytes to represent that row of pixels, you can instead store the color (4 bytes) and the length of the block (1 byte, maybe two if you want to allow runs longer than 255 pixels).

RLE algorithms are fairly simple to write and offer fairly decent loss-less compression, so you could easily devise a format that uses an RLE scheme and a tool that would convert from one to the other.

So, my question is, what's the best method of storing images/graphics for use with c++?
short of having easily editable images in formats such as .jpg, .png etc, whats the best way to store them for use in c++?
my thoughts are to use a custom format, but i dont know the first thing about image files

thanks

A custom image format is needless. In C++ there're several libraries to read certain formats. (uncompressed) TGA format is for example very simple and you could easily write your own loader for this format. PNG is an other good choise due to its freely available libraries over here.

I'd try implementing a TGA loader - it's quite a simple format with lossless compression via RLE (as JTippetts says). It'll give you a good grounding in the sort of things you'll need to consider if you decide to go with your own format.

Overall, though, I'd say you'll probably want to go with an existing format which offers a good balance between compressed size, image quality and loading time - good enough for your purposes. The benefits of using a common format are obvious.

Why would you write a custom format? Well I suppose you might want to store extra data along with the image (e.g. surface normal data, specular maps, etc.) which needs to be in a specific format for you to load and use efficiently - of course this adds extra complications, and extra work!

There's loads of good info about the Targa format (and a link to the actual spec) on the wikipedia page.

Yes, it is good practice. You want to ease the pathway between the artists and your game as much as possible by using standard formats (or at least well-supported ones; you can write custom exporters for the artists' software if you really need a custom format, but you ought to have a very good reason for needing the custom format because writing exporters can be a tricky process). Every conversion step from a standard format to a custom format opens up another injection point for possible bugs, extra work, and possible misunderstanding leading to wasted time, so unless you have a compelling reason to not use standard formats, it's best to not get too unconventional.
Many projects will use standard formats, but pack all of the data into some kind of data file. You can use third-party libraries like PhysFS, which will allow you to treat a ZIP archive as a filesystem; ie, you can pack your data into a ZIP rather than a more easily-accessible directory tree.

Some games might optimize their data into a format that is more quickly streamed from disk. You can write tools to crunch data (geometry, textures, etc...) into basically a large binary blob of data that you can just load from file and dump right into memory. For very large levels, this can speed load times, but the implementation of it can be tricky and if you're just starting out, you're not going to need that kind of optimization.

Now, some people want to use obscure formats solely for the purpose of protecting their valuable assets from "theft". This is a waste of time an resources. A portion of your players won't care about hacking out your assets, and the ones that do won't be stopped by a custom format, since the program code necessary to decode the format is right there where they can see it, inside the executable or DLLs. Just look at how easily Blizzard's MPQ format was spec'ed out and decoded by Diablo 2 modders. Introducing complication to the code-base and workflow solely for the purpose of obfuscation of assets simply is not practical.