Little CMS is a full ICC implementation in a small C library

Full ICC 4.4, and what that claim covers

The conformance statement is short and specific. Little CMS is a full implementation of ICC specification 4.4, it fully supports all kind of V2 and V4 profiles, including abstract, devicelink and named color profiles, and the README points to the tutorial for an exhaustive list of features. The three profile kinds in that sentence are the ones that separate a real implementation from a partial one, because each requires different handling inside the engine, and a library that claims V2 and V4 support but not named colour profiles cannot round trip every file a printer driver is handed. The underlying standard is the International Color Consortium specification, described as the modern standard for colour management and widely used, referred to in many international and other de facto standards, approved as an International Standard, ISO 15076-1, in 2005. So the standard being implemented is itself a published one rather than a company format.

The small footprint is the whole design goal

The stated intent is to be an open source small-footprint colour management engine with special focus on accuracy and performance, and the two are treated as compatible goals rather than a trade. The history in the readme explains why that combination is unusual. Since the initial release in 1998, Little CMS has grown to become one of the most popular open source colour management libraries, and it has been used in a large number of production projects, in areas such as printer firmware, monitors, digital cameras, RIPs, publishing and scientific work, among others. Firmware is the constraint that matters. A printer or a monitor has kilobytes of memory to spend, so an engine that is merely accurate is useless there, and the fact that the same library is found in most Linux distributions and inside device firmware is the evidence that the two goals are met together.

The build system is offered three ways on purpose

The repository root shows a project that supports several ways of being built, which is what a library embedded in other projects needs. There is the autoconf and automake path, with configure.ac, aclocal.m4, Makefile.am, Makefile.in, config.guess, config.sub, depcomp, install-sh, missing and ltmain.sh, plus an autogen.sh to regenerate them, and a compile wrapper script. There is a CMakeLists.txt with a cmake/ directory and a meson.build with meson_options.txt, so a distribution packager or a project with its own build can use whichever it prefers. The public interface lives in include/, the implementation in src/ and Lib/, and lcms2.pc.in is the pkg-config template, which is the piece that lets a consuming project link against the library without hardcoding paths. The MIT licence covers the library, and the topic list carries a mit-license tag for the same reason.

The test infrastructure is part of the source tree

Three directories show that this is not a library with a single test script. There is a testbed/ directory, a fuzzers/ directory and a utils/ directory, and the presence of a fuzzers directory in a C colour library is the notable one, because a profile transform parses untrusted binary ICC files, and a parser that reads files an attacker controls is exactly where fuzzing belongs. The utils/ directory holds the command line tools that live alongside the library, and bin/ and Plugins/ suggest that the shipped binaries and the format-specific helpers are kept in the tree rather than in a separate tools repository. The Projects/ directory rounds out the layout, and there is a SECURITY.md alongside the AUTHORS file and the ChangeLog, so vulnerability reports have a defined place to go rather than landing in a general issue tracker.

What this library is not

The limit is the scope of the word engine. Little CMS does transforms between ICC profiles, and it does not ship a colour management application, so there is no UI for choosing a monitor profile, no soft proofing workflow and no print pipeline driver. The README points at the site and the documentation for that wider world, and this repository is the layer underneath. The second limit is the constant, and it is a real one. A profile transform has to be correct to within a tolerance that depends on the profile type, the rendering intent and the colour space, and the readme does not state numeric accuracy targets, so a project that needs a documented error bound has to measure it against its own workflow rather than take a figure from the documentation. The third is the version ceiling. The specification implemented is 4.4, and when the ICC moves on, a library that targets the published version needs a maintenance cycle to follow it, which is what the release cadence and the security file are for. The fourth is that the library only knows about profiles, so anything that needs a colour space the ICC does not define, or a custom rendering intent, needs code on top of it.

Editorial conclusion

Little CMS suits a team that has to do colour transforms on a device with limited memory, because the same library runs in printer firmware and in a desktop publishing pipeline, and it suits anyone who needs a real ICC implementation rather than a partial one. It is the wrong tool if you need a colour management UI, since it is an engine rather than an application, and it is the wrong choice for a project that needs a scripting language to drive the transforms at runtime. Before adopting it, read the doc folder and the tutorial the README points to for the exhaustive feature list, and check the profile kinds your pipeline actually uses, because support for abstract, devicelink and named colour profiles is a claim worth verifying against your own files. The last push was on 2026-10-18 and the current release is lcms2.19.1 from 2026-05-06.

Frequently asked questions

Official sources

1. License: MIT
2. mm2/Little-CMS on GitHub
3. Project website
4. README
5. Releases