Open Bug 586320 Opened 15 years ago Updated 3 years ago

Disable system JPEG library support

Categories

(Core :: Graphics, defect)

Product:
Core
Component:
Graphics
Type:
defect

Tracking

()

People

(Reporter: justin.lebar+bug, Unassigned)

References

Details

As discussed in bug 584652, perhaps we want to disable system JPEG library support if and when we move to libjepg-turbo. Although libjpeg-turbo doesn't change libjpeg's API/ABI, it does add features which we'll probably want to use (see e.g. bug 584652). We could ifdef those features out when the system JPEG library isn't libjpeg-turbo, but since we don't test with that configuration, that might be asking for trouble. Another alternative would be requiring a libjpeg-turbo system library. Of course, this makes it harder for us to push a security update to the library if necessary. We'd also want to require a very new version of libjpeg-turbo, since currently only tip of SVN trunk renders JPEGs correctly.
Depends on: 573948
For now I think we should disable system-jpeg. Mike Hommey can re-enable support for system jpeg-turbo when it gets to a stable release tag.
> We could ifdef those features out when the system JPEG library isn't > libjpeg-turbo, but since we don't test with that configuration, that might be > asking for trouble. Linux distros do test. Anyways, the best would IMHO push to have the libjpeg-turbo changes merged with the ijg libjpeg. Mozilla could have enough weight for that.
Aren't there copyright issues with that?
(In reply to comment #2) > Anyways, the best would IMHO push to have the libjpeg-turbo changes merged with > the ijg libjpeg. Mozilla could have enough weight for that. libjpeg-turbo is based on version 6b of libjpeg, while ijg is at version 8b. (Mozilla currently ships version 6b.) I don't know how hard the merge would be, but it appears nontrivial at best.
We have an open tracker item regarding syncing jpeg-8b into libjpeg-turbo: http://sourceforge.net/tracker/?func=detail&aid=3017214&group_id=303195&atid=1278161 The basic issues there are: (a) ABI incompatibility. If we merged 8b into libjpeg-turbo, then applications built to use 6b would no longer be able to use libjpeg-turbo. We'd have to ship two different versions of the library or (more likely) #ifdef around the jpeg-8 code and require developers to configure the build to use that code. (b) Referring to http://www.mail-archive.com/devel@lists.fedoraproject.org/msg08644.html and http://www.mail-archive.com/devel@lists.fedoraproject.org/msg08451.html, there are patent concerns with some of the jpeg-8 features. I am taking my cues from the Fedora project. As soon as they're comfortable using jpeg-8, I'll be comfortable using it. The message from Thomas Lane above is very insightful. Apparently, the IJG developers have kind of gone off in their own direction. In particular, jpeg-8 is not being developed in an open manner, which is a large reason why we decided to form a separate project with libjpeg-turbo. That being said, there are already some projects that standardize around jpeg-8, including certain Linux distributions, so I think that the LJT project will have to address this eventually.
FWIW, Fedora 14 (and later) doesn't ship libjpeg at all. The system libjpeg has already been moved to libjpeg-turbo. We'd be in favor of requiring libjpeg-turbo instead of libjpeg in order to build against a system library.
Out of curiosity, what version of libjpeg-turbo ships in Fedora 14? Did you get the bugfix from bug 573948 comment 110? The wiki page I found [1] didn't give me a version number, but its last updated date suggested it might have missed that important fix. [1] https://fedoraproject.org/wiki/Features/libjpeg-turbo
I'm pretty sure Fedora is using 1.0.1 with some patches (they incorporate arithmetic decoding, for instance, which wasn't included in the upstream code base until 1.1 beta.) Note that the jpeg-8 API is now fully supported in libjpeg-turbo 1.1, and all of the jpeg-8 features except the DCT/IDCT scaling extensions and fancy downsampling in the compressor should work. There will be a 1.0.2 bug fix release soon.
It's a 1.0.1 based build, which does indeed have the jsimd typo fix in bug 573948 comment 110
Yeah, that bug fix was incorporated into the upstream 1.0.1 release. It's also in 1.1 beta. Also, I wanted to add some further insight as to why a merger with IJG isn't likely anytime soon. The maintainer of IJG has unfortunately expressed open hostility toward our work (see Comment 7: https://bugzilla.redhat.com/show_bug.cgi?id=639672). I'm not sure the source of his resentment, since our code base forked from libjpeg years before he took over the IJG and released jpeg-7. That's why we're based on jpeg-6b. I have attempted to support the jpeg-7 and jpeg-8b enhancements as much as possible in libjpeg-turbo 1.1 (jpeg-7 or jpeg-8b compatibility is optionally enabled with a configure switch-- it is not the default.) The remaining unsupported features would be impossible to support without essentially creating and maintaining two libjpeg-turbo code bases. Supporting the DCT/iDCT enhancements in jpeg-8 would also require a significant rewrite of our SIMD extensions, which would be a monumental exercise for me, given that those extensions were developed by several people over a period of about 10 years. This is a big reason why we chose to create a separate project for libjpeg-turbo. I figured that it would at least be useful to developers who were still using the jpeg-6b code base, which happened to include Fedora. Another company paid me to include jpeg-7 and jpeg-8b, so we can now mostly support other projects that have moved to those newer APIs as well. The other reason why we didn't pursue a merger with IJG was that we were unclear as to the development or contribution model for libjpeg, since we were unable to locate a source repository or developer's mailing list for the jpeg-7 and jpeg-8 code bases. I'm not sure how all of this will shake out in the long term. In the short term, however, I feel that libjpeg-turbo is fulfilling a need that wasn't otherwise being fulfilled.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.