Rationale

Rationale

dlib is primarily a collection of libraries for different tasks. Some of them depend on others, some are autonomous. So you wonder, what's the point of putting together several libraries with completely different fields of application? Why violate KISS principle? Here's some considerations.

• dlib is somewhat biased towards computer graphics domain and tends to provide a comprehensive feature set in that field. For example, any 2D/3D game engine or scientific simulation rely on three fundamental components: vector/matrix algebra, computational geometry and color/image processing. These include such common functionality as performance-optimized matrix inversion, geometric shape intersection tests, image file formats decoding, etc. Geometry obviously depends on vector math, and usually so does image processing (consider color-vector interoperability, FFT, convolution matrices and so on). Breaking these up to separate projects would cause nothing but a mere unjustified dependency mess. Though dlib itself is clearly not a game engine or scientific platform akin to Matlab, it is supposed to serve as a backend for building one. You can think of it as a "batteries" for OpenGL, for instance.

• dlib follows the idea of generalization. Specialized image loading libraries usually are file-based, and dlib's I/O capabilities are all stream-based. This yields necessity to include stream library and filesystem abstraction as a core part of the project. The same is true for memory management: major part of dlib utilizes dynamic memory allocation, and relying on GC for that is not the best idea for performance-critical tasks, so we decided to abstract memory allocations as much as possible (though work on this is still incomplete). In fact, dlib is the only known D library that includes fully GC-free image decoding. Memory-related functionality makes dlib a great base to build GC-free applications.

• dlib is not a single general purpose library of its kind: there is a project with the same name in C++ world, that includes numerical algorithms, image processing, data compression, threading, networking, XML, GUI and much more. We, of course, hadn't heard about it when started dlib, otherwise we would have choosen another name.