Re: [CTTE #717076] Default libjpeg implementation in Debian
Hey all,
tech-ctte bug was opened last July 2013. Bill you had a year to
provide an evidence or arguments why we should not switch
away from jpeg8. You have refused to take part in the discussion,
and yet now after the decision has been made, you come with
backhand arguments with no references...
To remind you what you said at that time:
On Wed, 24 Jul 2013, Bill Allombert wrote:
> I am not going to answer such drivel. You will have to contend with what I
> sent to debian-devel. Show a bit of respect.
On Sat, Aug 9, 2014, at 15:03, Henrique de Moraes Holschuh wrote:
> On Sat, 09 Aug 2014, Bill Allombert wrote:
> > > 3. libjpeg8 adds new features to the JPEG image format. These have
> > > however been rejected from the ISO standard, and their
> > > contributions to image quality and compression appear to be widely
> > > disputed.
> >
> > This is not really relevant. What is relevant, however, is that nobody is
> > disputing that libjpeg8 produce higher quality images than libjpeg62 when
> > decompressing standard JPEG images.
>
> If this is true, it is a concern: at least the bitmap editors and image
> processing utilities (gimp, imagemagick, etc) would regress on output
> quality.
>
> Are there any examples of this output difference? And I do mean between
> IJG libjpeg and libjpeg-turbo, not IJG libjpeg62 and IJG libjpeg8/9.
Yes, citation needed. Otherwise those are just empty claims.
> > Beside it has been reported that libjpeg-turbo do not play well with valgrind.
Again, ctation needed.
> This could also be a serious problem. Any lib that impairs the use of
> valgrind-style tools is going to be trouble as they interfere with
> valgrind runs on the applications/libraries linked to them.
Searching for "libjpeg-turbo valgrind" shows:
https://bugzilla.redhat.com/show_bug.cgi?id=730364
and referenced:
fixed-closed upstream http://sourceforge.net/p/libjpeg-turbo/bugs/33/
Also I found several reports where users are able to run valgrind
just fine.
> Should the two points above be pressing concerns that cannot be easily
> addressed by changes in libjpeg-turbo in a short timeframe, could we keep
> both libraries in light of this new information?
Release team has already expresses that they do not wish to have
two libjpeg libraries in stable release.
Ondrej
--
Ondřej Surý <ondrej@sury.org>
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
Reply to: