Have you considered using GLI?
I saw it, but I wrote my own instead. I did so for several reasons:
1: GLI has too narrow of a focus. It centers around the `texture2D`. That's great... unless you're not working with 2D textures. I see no need to have that restriction. Why are 3D textures, cubemaps, arrays, etc forbidden? I know that GL Image currently only implements 1D and 2D textures, but I'm going to start cubemaps soon.
2: Relative difficulty to use. There is no quick and easy way of just telling it to upload a `texture2D` to OpenGL. My GL Image library takes of 3 lines to go from a file to an OpenGL texture. And the last one is just a deletion of the glimg::ImageSet object, so if you stick it in a smart pointer, it only takes 2. The SDK is intended for new users. And while I'm totally fine with new users seeing the details of how texture uploading actually works, I would rather they do so in a proper, structured learning environment. IE: my tutorials.
3: Undocumented. This is a deal-breaker for me. The SDK is for a relatively new user, so clear and strong documentation is absolutely paramount.
The other issues are just personal pet-peeves of mine. I don't get why you needed the GTX vs. core concept here. In GLM, that made sense, as you want a demarcation between what GLSL provides (GLM core) and what additional convenience functions you've added.
Also, it's header-only. Again, in GLM, that made sense, as most of the functions were tiny and templated. `texture2D` is not a template. `gli::load` is not a template. I just don't feel that I should have to compile the entire C++ source to a DDS loader, in every .cpp file that I include it in, just to be able to load DDS's. This is what static libraries are for, after all. Not everything needs to be header-only.
Overall, I just felt that it wasn't ready for the SDK. GLM is a much more mature tool, while GLI seems to be simply whatever you needed for your examples. Plus, writing an image loader wasn't that hard.