[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#717076: tech-ctte: Decide what jpeg library the Debian project will use



Compression several replies into one.

> Couple of quick questions:
>
> 1) Does libjpeg-turbo (LJT) now completely support the libjpeg8 ABI?

AFAIK it doesn't support the SmartScale, but it does support full libjpeg8 ABI.

More on the ABI compatibility can be read in the article where LJT author explains why he won't support libjpeg9 ABI:
http://www.libjpeg-turbo.org/About/Jpeg-9

> 2) Do we have benchmark results which indicates that LJT is
> actually faster than IJG?

Yes, the benchmark can be found here:
http://www.libjpeg-turbo.org/About/Performance

Although it hasn't been by third party, I think it clearly explains the methodology and can be challenged and the results reproduced.

> 3) Has LJT tried to get its changes adopted by IJG?

I have no idea, but this might explain the history of the project:

> libjpeg-turbo was originally based on libjpeg/SIMD, an MMX-accelerated derivative of libjpeg v6b developed by Miyasaka Masaru. The TigerVNC and VirtualGL projects made numerous enhancements to the codec in 2009, and in early 2010, libjpeg-turbo spun off into an independent project, with the goal of making high-speed JPEG compression/decompression technology available to a broader range of users and developers.

If you check the libjpeg/SIMD page it becomes apparent that the libjpeg/SIMD author was not very fluent in English according to his words (and rough Google translate from Japanese).

Anyway if you look at the history of IJG, there was a 10 year gap between release 6 and 7, so there might have been no functional IJG, once the JPEG standard was adopted.

Also given the hostile content of the IJG libjpeg8 README against LJT, I doubt that there's a chance to merged the two libraries:
http://www.libjpeg-turbo.org/About/FUD

This also explains why the two projects have developed in different direction.

This is also an interesting reading:
https://bugzilla.redhat.com/show_bug.cgi?id=639672#c7

This might answer your question about merging LJT (libjpeg/SIMD) into IJG work.

> 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.

Bill, I am sorry, but I don't think there's a "drivel" in my questions. I think
I have raised valid questions that deserve to be answered, because I was
unable to find the answers myself.

Also I have been always polite in the conversation with you, so I don't see a reason to call my arguments a "drivel". I would have listened to reason, but I have a feeling that instead of engaging in healthy debate, you have entrenched yourself and you won't budge even a little.

> It has never been required of free software projects to restrict themselves to
> the features mandated by a standard.

One of the purposes of original IJG was to force the industry to standardize
one JPEG format. They have succeeded and now we even have ISO standard
group for JPEG.

I think that standardization is important for interoperability in case of such
widely used standard as JPEG. The opposite examples would be the f.e.
the Celt code that had many variants as the standard evolved and the result
was interoperability hell – look at the state of the Mumble packages in Debian.

Also I wouldn't object to any improvements to JPEG standard if they were
developed in an open way. I don't have a feeling that it was the case. The
author of improvements submitted his extensions to ISO JPEG committee
and his proposal was rejected. I don't think it's good for interoperability to
push his improvements in the de-facto standard library after the rejection.

> Finally, it doesn't currently look like the libjpeg-turbo packages are
> at all in a state to replace the libjpeg8 or libjpeg6b packages. I'm not
> sure why the CTTE should rule to replace the IJG packages when the work
> and testing necessary to make the LJT packages ready hasn't been done.

Mike has explained why:

> In an IRC discussion in #debian-devel several weeks ago the consensus  
> was: the RT team (represented Julien) will probably not want two  
> libjpeg implementations in Debian. My first packaging approach aimed  
> at having the compat mode libraries available [2] and allow the user  
> to install them as a drop-in replacement for libjpeg8.
>
> The IRC discussion lead to the result that the compat packages are not  
> wanted in Debian, only the native TURBOjpeg ABI. I was asked to ping  
> Bill Allombert about his opinion to transition from libjpeg8 fully to  
> libjpeg8-turbo. @Bill: can you repeat your disposition here again? I  
> guess our earlier mailing was a private mail exchange.

Anyway Ubuntu is using LJT packages since Ubuntu precise (e.g. 2011) as
a drop-in replacement for libjpeg8 and I think we can adapt their work quite
easily.

You (as tech-ctte) has also an option to allow compat libjpeg8 packages built from LJT, but this won't solve anything, since Bill plans to move to libjpeg9 ABI and LJT does not plan to support v9 ABI. Also I agree with release team that it's undesirable to have to libjpeg libraries. It would be only harder to debug the problems in upper layers.

Thus I think this needs a decision from tech-ctte before we make the switch to different implementation of libjpeg.



JFTR other prominent users of LJT include f.e. Chrome/Chromium and Firefox, also most of the distributions that matter has moved to LJT:

http://libjpeg-turbo.virtualgl.org/About/Software

O.

On Wed, Jul 24, 2013 at 3:05 AM, Don Armstrong <don@debian.org> wrote:
>
> On Tue, 23 Jul 2013, Don Armstrong wrote:
> > http://bugs.debian.org/632949 has more information from a previous
> > discussion around 2011; I'm Cc:'ing that bug to make sure the logs have
> > a connection between the two.
>
> The ITP for libjpeg-turbo also has some emails:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=602034 which shed some
> more background on this.
>
> Finally, it doesn't currently look like the libjpeg-turbo packages are
> at all in a state to replace the libjpeg8 or libjpeg6b packages. I'm not
> sure why the CTTE should rule to replace the IJG packages when the work
> and testing necessary to make the LJT packages ready hasn't been done.
>
>
> --
> Don Armstrong                      http://www.donarmstrong.com
>
> "You know," said Arthur, "it's at times like this, when I'm trapped in
> a Vogon airlock with a man from Betelgeuse, and about to die from
> asphyxiation in deep space that I really wish I'd listened to what my
> mother told me when I was young."
> "Why, what did she tell you?"
> "I don't know, I didn't listen."
>  –- Douglas Adams _The Hitchhikers Guide To The Galaxy_




--
Ondřej Surý <ondrej@sury.org>

Reply to: