OpenJPEG: the reference JPEG 2000 codec, and a project that says it is unmaintained

The README opens by saying the project is unmaintained

The second heading in the README is a section titled Unmaintained repository, and the text is direct. The repository should be considered unmaintained, commits may appear from time to time depending on committer interest and mood, and no committer currently feels responsible to regularly review tickets or pull requests. That statement sits above everything else, so it is the first thing to weigh. The metadata records the repository as not archived with a last push on 2026-09-05, and the release list shows 2.5.4 from 2025-09-20, 2.5.3 from 2024-12-09 and 2.5.2 from 2024-02-28. The practical reading is that this is a mature codebase in maintenance mode, where security-relevant fixes still arrive but new features and prompt review do not.

It is the reference software for a standard, which is the real guarantee

What OpenJPEG is, is an open-source JPEG 2000 codec written in C, developed to promote the use of JPEG 2000, a still image compression standard from the Joint Photographic Experts Group. Since April 2015 it has been officially recognised by ISO/IEC and ITU-T as a JPEG 2000 Reference Software, under the T-REC-T.804 amendment. That designation matters more than the code volume, because a reference implementation is what other implementations are tested against. It also sets the expectation correctly, that this library is the thing you compare yours to rather than a rapidly evolving product, and that its slow release cadence is a consequence of the standard being stable rather than a sign of abandonment by users.

The tree separates the library from the applications that use it

The folder hierarchy in the README describes the architecture. Under src/lib sit openjp2, the sources of the library itself, split into Part 1 and Part 2, and openjpip, described as a complete client-server architecture for remote browsing of JPEG 2000 images. Under src/bin are the applications, with common files, a basic codec in jp2, the OpenJPIP server and decoding server in jpip along with a Java client viewer for JPIP, and a wxWidgets-based OPJViewer for displaying j2k files. The wrapping directory holds a Java JNI binding so openjpeg can be used from a Java program, thirdparty holds libraries used by some applications and are built only if not found on the system, and the note that libopenjpeg itself has no dependency is worth remembering when you package it.

Only a limited subset of the API is exported, and that is deliberate

OpenJPEG strives to provide a stable API and ABI for applications, and as a result it only exposes a limited subset of its functions, using a mechanism of exporting and hiding functions. The README tells you what to do if you are unsure which functions are safe to use, and to compile with something similar to the gcc visibility hidden flag. On Windows, MSVC directly supports export and hiding, so the only API available is the one OpenJPEG supports. An API and ABI timeline is maintained automatically on the project site, which is the reference to check before binding to its symbols. The same section explains that the API documentation needs a major refactoring, and points to the installation and codec documentation on the wiki in the meantime, which is a fair signal of the state of the developer-facing material.

Three components were removed after 2.4.0 and their state is unknown

The deprecated components section records that openjpwl, openjp3d and openmj2 have been removed after the 2.4.0 release, with their building and working state described as unknown, and advises that anyone interested in them should start from the 2.4.0 tag. That is a genuinely useful warning for two reasons. It means the current master no longer contains those pieces, so a project that found references to them in older documentation will not find them here. And it means the 2.4.0 tag is the last point at which the whole historical tree is intact, which matters if you are trying to reproduce an old build.

Licence, contributors and the build system

The code is released under the BSD 2-clause Simplified License, and the README spells out what that means in plain terms. Anyone can use or modify the code, even for commercial applications, and the only restriction is to retain the copyright in the sources or in the binaries documentation. Sharing modifications back is encouraged, through a pull request or an issue, but it is explicitly not a requirement. The development is led by the Image and Signal Processing Group at the Université catholique de Louvain, with support from CNES, the CS company and the intoPIX company, and the JPWL module came from the Digital Signal Processing Lab of the University of Perugia. The build is CMake with a CTest configuration, and the root carries INSTALL.md, NEWS.md, HOWTO-RELEASE, AUTHORS.md, THANKS.md and a CHANGELOG.md, along with a separate openjpeg-data repository holding the test images for the test suite.

Editorial conclusion

OpenJPEG is a reasonable choice for a project that must read or write JPEG 2000 images, because it is the reference implementation, its public API is deliberately small, and the BSD 2-clause licence makes embedding it in a commercial product straightforward. It is a poor fit for a project that needs active maintenance from upstream, because the README states plainly that no committer currently feels responsible for regularly reviewing tickets or pull requests, and the last push was on 2026-09-05 with the most recent release 2.5.4 from 2025-09-20. Verify first which codec implementations are vendored in your platform or product, since OpenJPEG itself is now the fallback rather than the default, and read the API/ABI timeline before you bind to its exported symbols.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. uclouvain/openjpeg on GitHub