single-file public domain (or MIT licensed) libraries for C/C++
Most libraries by stb, except: stb_dxt by Fabian "ryg" Giesen, stb_image_resize by Jorge L. "VinoBS" Rodriguez, and stb_sprintf by Jeff Roberts.
说到图像解码库，最容易想起的就是 libpng 和 libjpeg 这两个老牌图像解码库了。
libpng 和 libjpeg 分别各自对应 png 和 jpeg 两种图像格式。这两种格式的区别如下：
png 支持透明度，无损压缩的图片格式，能在保证不失真的情况下尽可能压缩图像文件的大小，因此图像质量高，在一些贴纸应用中也大部分用的是 png 图片。
jpg 不支持透明度，有损压缩的图片格式，有损压缩会使得原始图片数据质量下载，也因此它占用的内存小，在网页应用中加速速度快。
要想在工程中同时解码 png 和 jpeg 格式图片，就必须同时引用这两种库，而且还得经过一系列编译步骤才行。
在这里，介绍一个简单易用的图像库：stb_image 。Github 地址为：https://github.com/nothings/stb ，目前已经有了 9600+ Star 。它的使用非常简单，看看 README 可能你就会了。
看看它的源码，你会发现全是 .h 头文件。这就是它的强大之处了，仅需在工程中加入头文件就可以解析图像了（实际上是函数实现等内容都放在头文件了而已）。 重点关注如下三个头文件：
stb_image.h 用于图像加载
stb_image_write.h 用于写入图像文件
stb_image_resize.h 用于改变图像尺寸
首先是调用 stbi_load 方法去加载图像数据，并获取相关信息。传入的参数除了图片文件地址，还有宽、高、颜色通道信息的引用。 变量 n 就代表图片的颜色通道值，通常有如下的情况：
1 ： 灰度图
2 ： 灰度图加透明度
3 ： 红绿蓝 RGB 三色图
4 ： 红绿蓝加透明度 RGBA 图
返回的结果就是图片像素数据的指针了。 stbi_load 不仅仅支持 png 格式，把上面例子中的图片改成 jpg 格式后缀的依旧可行。 它支持的所有格式如下：
png
jpg
tga
bmp
psd
gif
hdr
pic
格式虽多，不过一般用到 png 和 jpg 就好了。
除了从文件加载图片，stb_image 还支持从内存中加载图片，通过该方法 stbi_load_from_memory ，在后续文章中会用到它的。 加载完图片之后，stb_image 还提供了相应的释放方法 stbi_image_free，实际上就是把 free 封装了一下而已。
sbt_image_resize 加载完图片像素数据之后，就可以通过 stbir_resize 方法改变图片的尺寸。
// 加载了一张图片，并将它的宽高都缩小一倍，并保存缩小后图片。
#include <iostream>
#define STB_IMAGE_IMPLEMENTATION
#include "stb_image.h"
#define STB_IMAGE_WRITE_IMPLEMENTATION
#include "stb_image_write.h"
#define STB_IMAGE_RESIZE_IMPLEMENTATION
#include "stb_image_resize.h"
#include <string>
#include <stdio.h>
#include <stdlib.h>
#include <vector>
using namespace std;
int main() {
std::cout << "Hello, STB_Image" << std::endl;
string inputPath = "/Users/glumes/Pictures/input.png";
int iw, ih, n;
// 加载图片获取宽、高、颜色通道信息
unsigned char *idata = stbi_load(inputPath.c_str(), &iw, &ih, &n, 0);
int ow = iw / 2;
int oh = ih / 2;
auto *odata = (unsigned char *) malloc(ow * oh * n);
// 改变图片尺寸
stbir_resize(idata, iw, ih, 0, odata, ow, oh, 0, STBIR_TYPE_UINT8, n, STBIR_ALPHA_CHANNEL_NONE, 0,
STBIR_EDGE_CLAMP, STBIR_EDGE_CLAMP,
STBIR_FILTER_BOX, STBIR_FILTER_BOX,
STBIR_COLORSPACE_SRGB, nullptr
);
string outputPath = "/Users/glumes/Pictures/output.png";
// 写入图片
stbi_write_png(outputPath.c_str(), ow, oh, n, odata, 0);
stbi_image_free(idata);
stbi_image_free(odata);
return 0;
}
| library | lastest version | category | LoC | description |
|---|---|---|---|---|
| stb_vorbis.c | 1.16 | audio | 5486 | decode ogg vorbis files from file/memory to float/16-bit signed output |
| stb_image.h | 2.22 | graphics | 7547 | image loading/decoding from file/memory: JPG, PNG, TGA, BMP, PSD, GIF, HDR, PIC |
| stb_truetype.h | 1.21 | graphics | 4882 | parse, decode, and rasterize characters from truetype fonts |
| stb_image_write.h | 1.13 | graphics | 1617 | image writing to disk: PNG, TGA, BMP |
| stb_image_resize.h | 0.96 | graphics | 2630 | resize images larger/smaller with good quality |
| stb_rect_pack.h | 1.00 | graphics | 628 | simple 2D rectangle packer with decent quality |
| stb_ds.h | 0.5 | utility | 1691 | typesafe dynamic array and hash tables for C, will compile in C++ |
| stb_sprintf.h | 1.06 | utility | 1860 | fast sprintf, snprintf for C/C++ |
| stretchy_buffer.h | 1.03 | utility | 262 | typesafe dynamic array for C (i.e. approximation to vector<>), doesn't compile as C++ |
| stb_textedit.h | 1.13 | user interface | 1404 | guts of a text editor for games etc implementing them from scratch |
| stb_voxel_render.h | 0.88 | 3D graphics | 3806 | Minecraft-esque voxel rendering "engine" with many more features |
| stb_dxt.h | 1.08b | 3D graphics | 728 | Fabian "ryg" Giesen's real-time DXT compressor |
| stb_perlin.h | 0.4 | 3D graphics | 366 | revised Perlin noise (3D input, 1D output) |
| stb_easy_font.h | 1.0 | 3D graphics | 303 | quick-and-dirty easy-to-deploy bitmap font for printing frame rate, etc |
| stb_tilemap_editor.h | 0.41 | game dev | 4161 | embeddable tilemap editor |
| stb_herringbone_wa... | 0.7 | game dev | 1221 | herringbone Wang tile map generator |
| stb_c_lexer.h | 0.10 | parsing | 964 | simplify writing parsers for C-like languages |
| stb_divide.h | 0.92 | math | 421 | more useful 32-bit modulus e.g. "euclidean divide" |
| stb_connected_comp... | 0.96 | misc | 1049 | incrementally compute reachability on grids |
| stb.h | 2.34 | misc | 14453 | helper functions for C, mostly redundant in C++; basically author's personal stuff |
| stb_leakcheck.h | 0.5 | misc | 190 | quick-and-dirty malloc/free leak-checking |
Total libraries: 21
Total lines of C code: 55669
These libraries are in the public domain. You can do anything you want with them. You have no legal obligation to do anything else, although I appreciate attribution.
They are also licensed under the MIT open source license, if you have lawyers who are unhappy with public domain. Every source file includes an explicit dual-license for you to choose from.
Are there other single-file public-domain/open source libraries with minimal dependencies out there?
No, because it's public domain you can freely relicense it to whatever license your new library wants to be.
stb_image will either use SSE2 (if you compile with -msse2) or will not use any SIMD at all, rather than trying to detect the processor at runtime and handle it correctly. As I understand it, the approved path in GCC for runtime-detection require you to use multiple source files, one for each CPU configuration. Because stb_image is a header-file library that compiles in only one source file, there's no approved way to build both an SSE-enabled and a non-SSE-enabled variation.
While we've tried to work around it, we've had multiple issues over the years due to specific versions of gcc breaking what we're doing, so we've given up on it. See nothings#280 and nothings#410 for examples.
Generally they're only better in that they're easier to integrate, easier to use, and easier to release (single file; good API; no attribution requirement). They may be less featureful, slower, and/or use more memory. If you're already using an equivalent library, there's probably no good reason to switch.
You can use this URL to link directly to that list.
Just to give you some idea of the internal complexity of the library, to help you manage your expectations, or to let you know what you're getting into. While not all the libraries are written in the same style, they're certainly similar styles, and so comparisons between the libraries are probably still meaningful.
Note though that the lines do include both the implementation, the part that corresponds to a header file, and the documentation.
Windows doesn't have standard directories where libraries live. That makes deploying libraries in Windows a lot more painful than open source developers on Unix-derivates generally realize. (It also makes library dependencies a lot worse in Windows.)
There's also a common problem in Windows where a library was built against a different version of the runtime library, which causes link conflicts and confusion. Shipping the libs as headers means you normally just compile them straight into your project without making libraries, thus sidestepping that problem.
Making them a single file makes it very easy to just drop them into a project that needs them. (Of course you can still put them in a proper shared library tree if you want.)
Why not two files, one a header and one an implementation? The difference between 10 files and 9 files is not a big deal, but the difference between 2 files and 1 file is a big deal. You don't need to zip or tar the files up, you don't have to remember to attach two files, etc.
No, they are just the initials for my name, Sean T. Barrett. This was not chosen out of egomania, but as a moderately sane way of namespacing the filenames and source function names.
If people submit them, I generally add them, but the goal of stb_image is less for applications like image viewer apps (which need to support every type of image under the sun) and more for things like games which can choose what images to use, so I may decline to add them if they're too rare or if the size of implementation vs. apparent benefit is too low.
Yes. https://github.com/nothings/stb/blob/master/docs/stb_howto.txt
I prefer it over GPL, LGPL, BSD, zlib, etc. for many reasons. Some of them are listed here: https://github.com/nothings/stb/blob/master/docs/why_public_domain.md
Primarily, because I use C, not C++. But it does also make it easier for other people to use them from other languages.
I still use MSVC 6 (1998) as my IDE because it has better human factors for me than later versions of MSVC.