Re: jpeg8 vs jpeg-turbo
On Sat, Apr 27, 2013 at 08:55:28AM +0200, Ondřej Surý wrote:
> On Fri, Apr 26, 2013 at 11:50 PM, Bill Allombert
> <Bill.Allombert@math.u-bordeaux1.fr> wrote:
> >
> > I think there are some misunderstanding about what offer libjpeg8:
> >
> > 1) by default, libjpeg8 creates JFIF files which are compatible with libjpeg62.
> >
> > 2) by default, libjpeg8 uses a different subsampling which lead to higher
> > quality output than libjpeg62.
> >
> > However this leads to files which are not byte per byte indentical to what
> > libjpeg62 would produce, but this is in no way required by the JPEG standard.
> > Indeed the standard explicitely allow for different DCT implementation.
>
> No this is not the case. It was just this initial issue which raise my
> attention to what is happening with libjpeg in Debian.
What is not the case ? Even libjpeg6b include three DCT implementations which
can leads to different output.
I find interesting that you have just discovered #629963 I reported two years
ago.
> P.S.: You still haven't answered my questions in the previous email. I
> don't think they are unreasonable.
Let start with the beginning:
I became the maintainer of libjpeg62 in November 2001, the package having been
unmaintained for 3 years. During the last twelve year, Guido has served as
the upstream maintainer, helping me to deal with bug reports, providing patches
to fix issues, and finally releasing libjpeg7 which included, inter alia, patches
I wrote for the need of the Debian package (the DP xxx patches in the changelog).
Guido also agreed to the release of libjpeg 6b1 which is libjpeg 6b with
versionned symbols, which was needed to move forward with libjpeg7. Since the
release of libjpeg7, Guido makes one release (minor or major) each year in
January.
During that time, it became obvious that Guido has a deep understanding of the
libjpeg code and the JPEG technology, and at the same time that the quality
of libjpeg is very high (there have been no security vulnerability reported
against libjpeg6b in 15 years. Compare that number to libtiff, libpng or even
libjpeg-turbo.)
On the other hand, it is also obvious that the libjpeg-turbo upstream does not
have a full understanding of the libjpeg code, so we are better off with Guido
as upstream maintainer.
Cheers,
--
Bill. <ballombe@debian.org>
Imagine a large red swirl here.
Reply to: