Excuse my ignorance (I never had the opportunity to use D3D11 since I'm stuck with XP for the time being), but wouldn't there be a D3DX function that loads various texture formats including .png files? I know it's good not to rely on D3DX when possible either way.
However it has been depreciated in windows 8 and therefore the future. Might as well learn the 6 or 7 lines it takes to load image data using FreeImage, and the few more to send it into directx. This allows you future proof and you could switch to openGL as well if you wanted.
Ah, that makes sense. Writing your own image loader or using an open source one has always been my choice for portability and such, especially when working with consoles (those of us who get that far).
though funny is I have usually written my own loaders (and other code as well), but admitting to this is one of those things which often causes people to start making accusations of "reinventing the wheel" and "making a standard of non-standard" and so on.
but, I am not really afraid of writing my own code, and consider it a reasonable tradeoff to avoid the annoyance of having lots of external dependencies (more so when targeting multiple OS's is involved).
granted, not all file-formats are equally simple, like it is a bit simpler to write a loader for something like TGA or BMP than for something like PNG, or JPEG (*1).
ultimately, there is little really "special" about file-formats, mostly just specific ways of representing various kinds of data, and code generally doesn't really care whose code generates or processes the data, so long as it basically matches the expected format.
*1: for example, TGA and BMP are basically a header followed by a glob of raw pixel data (may be RLE compressed for TGA though).
in contrast, PNG is a TLV format (sort of like a WAV or an AVI), with data-lumps for headers and image data, and with the image data stored using Deflate compression and with per-scanline filtering and similar. and, JPEG is a beast not easily explained in a short summary (basically, it is a stream of escape-coded markers representing headers and image-data, which consists mostly of Huffman-compressed DCT blocks representing typically 3 planes in the YCbCr colorspace, ...). (worse yet is video codecs...).
but, usually, most of this complexity has its reasons (such as smaller file-sizes, ...), and by playing around with things, one may discover why things are the way they are.
as far as complexity goes, PNG isn't really all that bad though. the most complicated bit is probably the Deflate compression, but this part is (usually) handled by Zlib, unless of course one also goes and writes their own Deflate code (...).
as in everything, there are pros and cons involved...