Bug#602034: jpeg8 vs jpeg-turbo
On Thu, Apr 25, 2013 at 6:17 AM, Riku Voipio <riku.voipio@iki.fi> wrote:
> On Wed, Apr 24, 2013 at 03:19:59PM +0200, Bill Allombert wrote:
>> As IJG libjpeg maintainer, my plan is to move to libjpeg9 which has more feature.
>
> Only the applications that actually want to experiment with libjpeg8/9 ABI should be using it -
>
> The 100% of current applications that work just libjpeg-turbo should be
> using libjpeg-turbo for better performance and compatibility with rest
> of the linux distributions.
>
> Which feature in libjpeg9 does anyone want? The ability to make jpeg's
> images that nobody else can view?
Chicken & egg issue, until everyone follow debian and uses libjpeg9,
there may be surprise.
>> I do not see libjpeg-turbo as a suitable replacement. It has
>> 1) an different license
>
> Be specific, what do you not like about libjpeg-turbo license? As far as
> I see, it is under the exact same license?
>
>> 2) much more security issues in a much smaller timeframe.
>
> Which translates to.. a single CVE in libjpeg-turbo since it's
> inception!
>
>> 3) do not implement the full libjpeg8 ABI, nor the upcoming libjpeg9.
>
> This would be a relevant if some application actually used the
> "full libjpeg8 ABI" . In fact, 100% of debian works fine with
> libjpeg-turbo, or even the original libjpeg6b (if the would be
> recompiled against it again).
>
> I find the reason that IJG libjpeg8 fork is so triggerhappy to
> repeatedly break the API and ABI (and image format!) rather a reason
> to make libjpeg8 the non-default.
>
> You should not deprive debian users from high performance jpeg rendering
> for a few ABI features that nobody uses - or anyone is asking for.
I do not believe in debian life-span, a package manager ever switch an
implementation of a package. So libjpeg9 and libjpeg-turbo will have
to co-live.
I understand your point that libjpeg9 offers experimental feature not
needed for everyone, but at least from my point of view libjpeg-turbo
by only implementing portion of ITU-T T.81, ISO/IEC IS 10918-1 (namely
lossy 8bits progressive & sequential) is a no-go for my applications.
Have a look at ITK, DCMTK and/or GDCM which provide a patched libjpeg
to provide support for lossy 8 & 12 bits and lossless 16bits. This is
a burden to maintain those side implementations.
This goes without saying that JPEG commitee is now working on a full
implementation of ITU 81:
https://github.com/thorfdbg/libjpeg
Which also has a different license, may be slower, but *at last*
provide a complete implementation of JPEG. It is said to provide an
ABI compatible with the original IJG implementation in the near
future. So debian may have to provide three JPEG implementations
This bug will be really messy to read, but I wished the team from
libjpeg-turbo and whoever is running IJG found a compromise to either
integrate optimization from -turbo into jpeg9, or the other way
around, -turbo provides empty body function for the new API. oh
well...
-M
Reply to: