3 ms·
Honest questions: is this a complete re-implementation of libjpeg? (It was mentioned that this was originally based off libjpeg/SIMD, a libjpeg v6b fork.) If n
by devy 10y ago
Honest questions: is this a complete re-implementation of libjpeg? (It was mentioned that this was originally based off libjpeg/SIMD, a libjpeg v6b fork.) If not, why can't this be backported to upstream libjpeg?
- ploxiln 10y agohttp://www.libjpeg-turbo.org/About/FUD http://www.libjpeg-turbo.org/About/FUD > 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.) > 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.
- faragon 10y agov6 is the most widely used. v7 and later broke API compatibility. I'm glad of libjpeg-turbo using v6.
- 0x0 10y agoUpstream libjpeg after v6 has appeared a little... weird lately: https://github.com/LuaDist/libjpeg/blob/master/README#L353 https://github.com/LuaDist/libjpeg/blob/master/README#L353