FINALLY. I'VE FINALLY DONE IT! It took weeks of work, but I managed to exorcise D3DX from Gorgon. Behold my video playing an animated GIF using a 2D texture array:

I've provided extensive info after the jump thingy.
In case you're wondering (and you know that you are), I used the D3DX utility library to handle some horrible jobs in Gorgon. Namely saving and loading textures and importing GDI+ (System.Drawing) bitmaps into textures. But with the abomination that is Windows 8, and DirectX 11.1 (which, just to be clear, Gorgon is NOT using), D3DX has been left to rot. Fine by me, one less dependency (and hopefully no more d3dx4312318793728.dll was not found errors).
So, how am I performing texture loading/saving? Well, being the daft bastard that I am, I created a rather complicated (for me) imaging system to handle loading, saving and manipulation of image data. The last part is underlined because Gorgon 1.x had very limited capability in that area. It's all based on the toolkit code in SharpDX by Alexandre Mutel and the DirectXTex library by Chuck Walbourn. I seriously wouldn't have been able to get anywhere if those guys hadn't done as much work as they did.
That said, it was still no walk in the park. The SharpDX toolkit code is fairly basic, and the DirectXTex library is in C++ (I now remember exactly why I don't use that bastard of a language anymore).
With all that said, here's what's new with texture loading/saving:

• Image data is now manipulated through the GorgonImageData object. This allows us direct access to the pixels of an image on any texture array (or depth slice if using volume textures) index and mip map level. It breaks the indices and mips into parts that can be indexed like a collection and provides data streams to allow reading/writing of data into those buffers. All requisite information is included, such as row pitch, slice pitch (= image width * height * bytes/pixel). All in all, it makes accessing the data pretty easy.
  
  
  • Images can be loaded directly into the image data using FromFile/Stream methods. This is pretty straightforward. Image data can also be saved to a file/stream.
    
  • The image data object can perform conversion on several (but not all) formats. Plus it'll do resizing of images.
    
  • That's the image data object... is that a texture? No, it is not a texture. It is the data that a texture can use however. You may create textures by loading them directly from a file/stream, or into an image data object and then pass that image data object into the texture creation methods. Or even create an empty texture and copy the data in later. The two object types are related, but different. One is for low level image manipulation, the other is for dumping that image data into your video card.
    

Codecs... Gorgon now has several objects called codecs. These are used to decode/encode image data from a file/stream. Codec objects are passed to load/save methods whenever texture or image data objects are loaded/saved. Currently Gorgon has support for:

1. 
   
   1. DDS - This was a bastard to write.
      
   2. TGA
      
   3. GIF - This was a bastard too
      
   4. PNG
      
   5. TIFF
      
   6. BMP
      
   7. WMP
      
   
   

• Codecs are objects. Not enumeration types like the previous versions of Gorgon. Why? Because each codec has a set of properties which allow you to alter how images are decoded and encoded based on the codec you're using. This allows us to do transformation of image data as it's brought in.
  
• Codecs are custom objects. That is, you, yes you, can write your own by inheriting from GorgonImageCodec and you'll be able to save/load your very own file format. Because the world needs more file formats.
  

Currently GIF, PNG, BMP, WMP, and TIFF are using the Windows Imaging Component API to encode/decode the data for those file formats. This requires that WIC be installed on your system if you plan on using those formats. However, this shouldn't be an issue because Windows 7 should have it installed already. Also, because codecs can be created by users, you can always write your own PNG codec and not use my crappy version.
Anyway, that's about as much as I care to babble on about this.

Source