libjpeg-turbo | About / FUD

A Message From the Maintainer of libjpeg-turbo

I have no interest in engaging in open source holy wars. Unfortunately, however, a statement recently appeared in the README file for libjpeg v8d, which appears to be directed at our project and which, if so, bears addressing:

From the libjpeg v8d README file:

There are currently distributions in circulation containing the name
"libjpeg" which claim to be a "derivative" or "fork" of the original
libjpeg, but don't have the features and are incompatible with formats
supported by actual IJG libjpeg distributions.  Furthermore, they
violate the license conditions as described under LEGAL ISSUES above.
We have no sympathy for the release of misleading and illegal
distributions derived from obsolete code bases.
Don't use an obsolete code base!

Everyone's entitled to their opinion, but referring to another open source project as "illegal" is an extraordinary claim and requires extraordinary evidence. At no point has the current IJG maintainer approached us regarding perceived violations of the libjpeg license, and had he done so, I assure you that we would have worked with him to address any perceived issue immediately. libjpeg-turbo has undergone extensive review by multiple lawyers as it has been integrated into a variety of commercial products and high-profile open source projects, and no issues have been found during this process. libjpeg's license is a fairly standard three-clause BSD-style license. We have taken great care to ensure that the all of the libjpeg documentation is included in our distributions, that the authors of the upstream code are properly credited, and that all source files that we modified are clearly marked. Our methods for modifying and using the libjpeg source code are in line with methods used by other projects, both proprietary and open source, that incorporate libjpeg. Furthermore, as far as we can tell, our methods for modifying and using the libjpeg source code are in line with the methods that the current libjpeg maintainers have used to modify the legacy libjpeg v6b code base.

Our code is not a fork of libjpeg v7/v8 but rather a fork of libjpeg v6b, although we do incorporate some of the libjpeg v7/v8 code in order to emulate the backward-incompatible ABI introduced by those more recent releases. libjpeg-turbo originally spun off from the TigerVNC Project, which was using a modified version of libjpeg/SIMD in its source tree. As our in-tree implementation of libjpeg/SIMD began to improve, I began to field requests from other video-related projects that wanted to leverage our codec. I decided to create The libjpeg-turbo Project in early 2010, both to make it easier for such projects to build the code as well as to allow the codec to evolve independently of the needs of TigerVNC. libjpeg/SIMD predates libjpeg v7 by several years, which means that our SIMD extensions are not compatible with some of the new features in libjpeg v7 and v8. Thus, merging with the upstream libjpeg code would have been very difficult, if not impossible (more recent comments by the current maintainer of libjpeg indicated that our SIMD extensions would not have been accepted, anyhow.) Furthermore, since our project was originally more of a focused implementation and needed to evolve more rapidly and openly than libjpeg, we needed to develop it using a rich content management platform such as SourceForge.

In its early days, libjpeg-turbo was targeted toward the specific needs of video and remote display projects, but the fact that it has developed a life of its own since then is not something I will apologize for. It wasn't anything that I actively pushed for, but rather, it simply occurred because libjpeg-turbo filled a need that was not otherwise being filled. We never set out to do anything other than to provide an accelerated implementation of baseline JPEG encoding/decoding, but that was apparently what most of the community wanted. Our implementation supports all of the other variations on the JPEG format that are supported by libjpeg v6b, in addition to arithmetic encoding/decoding (which was not included in libjpeg v6b because of a software patent that has since expired), but only baseline encoding/decoding is accelerated. By accelerating baseline JPEG and thus allowing it to be used in applications for which it may have previously been too slow, libjpeg-turbo dovetails with the original goal of the IJG, which was to encourage the industry to adopt a common standard JPEG format.

The development of libjpeg-turbo is driven entirely by community demand, so whether or not we will eventually support the non-standard format extensions implemented in libjpeg v8 (SmartScale and the lossless RGB JPEG format based on it) is largely up to the community. With respect to SmartScale, our own research has not shown it to provide any functionality that can't already be provided using other means, and since it is not an official standard, the community has no confidence that the format won't change arbitrarily in the future. In all likelihood, SmartScale images will not ever be supported by our project unless they become commonplace enough that, for instance, web browsers would want to decode them. The IJG is not a standards committee, and they do not get to decide what is "compatible" and what isn't. In fact, since jpeg-7, every new release of the IJG's software has broken backward ABI compatibility with prior releases (needlessly, in the case of jpeg-9), and both jpeg-8 and jpeg-9 introduced new, non-standard image formats that couldn't be decoded by previous IJG releases or by other JPEG codecs. In short, it is the IJG's software that has become incompatible with the rest of the community's, not vice versa.

As far as "obsolete", both the IJG and our project have built upon the excellent work of Thomas Lane, the author of libjpeg v6b. We simply chose to build in a different direction.