Re: jpeg8 vs jpeg-turbo
On Thu, May 2, 2013 at 2:58 PM, Andrey Rahmatullin w...@wrar.name wrote: On Wed, May 01, 2013 at 07:18:31PM -0400, Paul Tagliamonte wrote: Why has this taken so long? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=602034#62 And no one raised this to tech-ctte. And this has been done now: #717076 Ondrej -- Ondřej Surý ond...@sury.org
Re: jpeg8 vs jpeg-turbo
On Sat, May 04, 2013 at 06:11:48AM +0200, Matthias Klose wrote: Am 24.04.2013 11:23, schrieb Ondřej Surý: do you have some insight how openjpeg enters this game? apparently some packages already use openjpeg explicitly to support some jpeg2000 features. Irrelevant to this discussion, as it's jpeg2000 not jpeg. With a short glance at their webpage, it doesn't seem like it accepts regular jpeg at all. Do one thing and do it well. There was some discussion on that in Ubuntu, see https://launchpad.net/bugs/711061. But the bug entry you linked to contains some insight on the IJG guy. And it's thoroughly disgusting: his words: # FILE FORMAT WARS # # # The ISO JPEG standards committee actually promotes different formats like # JPEG 2000 or JPEG XR which are incompatible with original DCT-based # JPEG and which are based on faulty technologies. IJG therefore does not # and will not support such momentary mistakes (see REFERENCES). # We have little or no sympathy for the promotion of these formats. Indeed, # one of the original reasons for developing this free software was to help # force convergence on common, interoperable format standards for JPEG files. # Don't use an incompatible file format! So, with royal we, this guy disparages a new format which: * doesn't pretent to be regular jpeg * doesn't use .jpg or image/jpeg * is an official ISO standard * has some use in the wild yet he does introduce incompatibilities himself, without meeting any of the above. -- ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130504100706.ga8...@angband.pl
Re: jpeg8 vs jpeg-turbo
Am 24.04.2013 11:23, schrieb Ondřej Surý: do you have some insight how openjpeg enters this game? apparently some packages already use openjpeg explicitly to support some jpeg2000 features. There was some discussion on that in Ubuntu, see https://launchpad.net/bugs/711061. Matthias -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51848a84.3030...@debian.org
Re: Re: jpeg8 vs jpeg-turbo
Bill Allombert wrote: On Sat, Apr 27, 2013 at 08:55:28AM +0200, Ondřej Surý wrote: 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, What do you base this on? It seems nobody is particularly impressed by his attempts to improve the format. Can you personally evaluate this, or whose opinion do you rely on? 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.) But it seems libjpeg6 was created by different people (though nobody has clearly answered the question of who the maintainers actually are and have been). So this hardly seems like an argument to prefer Guido as an upstream, at most an argument to stop any attempts at further improvement and just stay with the old code. 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. Do you have some references for that obviousness? Other distributions do not seem to consider it so obvious. And on the other hand, several problems with Guido's work have been mentioned here (such as in Ondřej Surý's mail you're replying to). While his positive accomplishments as a maintainer don't seem all that many; much of the new work has been in new extensions that are considered dubious. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1367496958.1926.17.camel@glyph.nonexistent.invalid
Re: jpeg8 vs jpeg-turbo
On Wed, May 01, 2013 at 07:18:31PM -0400, Paul Tagliamonte wrote: Why has this taken so long? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=602034#62 And no one raised this to tech-ctte. I mean, every other major distro is using -turbo. It can't be that bad. They are not Debian. -- WBR, wRAR signature.asc Description: Digital signature
Re: jpeg8 vs jpeg-turbo
On Thu, May 2, 2013 at 12:16 AM, Bill Allombert bill.allomb...@math.u-bordeaux1.fr wrote: so we are better off with Guido as upstream maintainer. So you are saying you won't budge even a little and any discussion with you to consider that change of the default libjpeg-dev is futile? Am I getting that right? Ondrej -- Ondřej Surý ond...@sury.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caljhhg_y_f-j7uf2fqq2x1ypcv6xha9y6xq2taw1g_c0v99...@mail.gmail.com
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.allomb...@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. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130501221646.GA22352@yellowpig
Re: jpeg8 vs jpeg-turbo
On Thu, May 02, 2013 at 12:16:46AM +0200, Bill Allombert wrote: 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. It's no reason to hold the whole distro back, however. Perhaps after he figures out he has no more users he'd be more open to merging the fork back in, and *collaborating* in a productive way. I'll take an upstream that takes slightly longer to fix a bug and is open to evolving with the software it uses than a project that breaks A[P|B]I regularly (from what I read here) any way. I don't have all the facts, and I only know what I read others saying about it, but +1 to turbo. Why has this taken so long? I mean, every other major distro is using -turbo. It can't be that bad. Cheers, Paul -- .''`. Paul Tagliamonte paul...@debian.org : :' : Proud Debian Developer `. `'` 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `- http://people.debian.org/~paultag signature.asc Description: Digital signature
Re: jpeg8 vs jpeg-turbo
On Fri, Apr 26, 2013 at 11:50 PM, Bill Allombert bill.allomb...@math.u-bordeaux1.fr wrote: On Wed, Apr 24, 2013 at 10:10:42PM +0800, Aron Xu wrote: On Wed, Apr 24, 2013 at 9:19 PM, Bill Allombert bill.allomb...@math.u-bordeaux1.fr wrote: As IJG libjpeg maintainer, my plan is to move to libjpeg9 which has more feature. From a user's prospective, I don't think adding bunches of not widely used features is that useful (I mean it's useful but not that important), but speed does matter a lot, especially on slower hardware like ARM-boards. 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. 3) libjpeg8 implements a larger part of the JPEG standard, so it can read and write JFIF files that are standard compliant but not supported by libjpeg62. This is too much generic. Could you please list those differences in the JPEG standard implementation between IJG libjpeg and libjpeg-turbo. 4) it also provides a number of extension to the standard, which are well documented. Again, could you please list that? If you are speaking about SmartScale, then I really don't think that non-(ISO)-standard extensions are usefull for anything. Or is there anything else? So I do not think it is fair to restrict JPEG support in Debian to 1998 image processing technology. Nobody is saying that. Bill, please stop being holed up in your position. Most of the Open Source world (as already proven and cited) has moved to libjpeg-turbo and I don't think this is the case where Debian should stand out. O. P.S.: You still haven't answered my questions in the previous email. I don't think they are unreasonable. -- Ondřej Surý ond...@sury.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CALjhHG92k=s4vbzjnlr2vskkwuae+vfpovhmh8wgkzr69qh...@mail.gmail.com
Re: jpeg8 vs jpeg-turbo
On Wed, Apr 24, 2013 at 10:10:42PM +0800, Aron Xu wrote: On Wed, Apr 24, 2013 at 9:19 PM, Bill Allombert bill.allomb...@math.u-bordeaux1.fr wrote: As IJG libjpeg maintainer, my plan is to move to libjpeg9 which has more feature. From a user's prospective, I don't think adding bunches of not widely used features is that useful (I mean it's useful but not that important), but speed does matter a lot, especially on slower hardware like ARM-boards. 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. 3) libjpeg8 implements a larger part of the JPEG standard, so it can read and write JFIF files that are standard compliant but not supported by libjpeg62. 4) it also provides a number of extension to the standard, which are well documented. So I do not think it is fair to restrict JPEG support in Debian to 1998 image processing technology. Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130426215054.GB19734@yellowpig
Re: jpeg8 vs jpeg-turbo
+++ Bill Allombert [2013-04-26 23:50 +0200]: So I do not think it is fair to restrict JPEG support in Debian to 1998 image processing technology. Neither does anyone else, which is why they want to be able to use the SIMD features in their CPUs for (much) faster JPEG processing. So far a good case seems to be being made that that is more useful and more requested than the relatively minor image quality improvements you mentioned. (And they can be had without any issues with incompatible image formats.) Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130426221316.gh2...@stoneboat.aleph1.co.uk
Re: jpeg8 vs jpeg-turbo
On Fri, Apr 26, 2013 at 11:50 PM, Bill Allombert bill.allomb...@math.u-bordeaux1.fr wrote: So I do not think it is fair to restrict JPEG support in Debian to 1998 image processing technology. According to this mail by the Fedora KDE maintainer, ISO rejected the latest changes introduced by libjpeg8: http://mail.kde.org/pipermail/digikam-devel/2013-January/066256.html Why should Debian use a library which generates non-standard JPEG files? And it's even worse for libjpeg9, IIUC from that discussion in the Digikam mailing list. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Re: jpeg8 vs jpeg-turbo
On Thu, Apr 25, 2013 at 6:17 AM, Riku Voipio riku.voi...@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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ca+7wuszqjfo+ma94e2s_mkzbjduvmvcg+wsbgzhrfghjb5+...@mail.gmail.com
Re: jpeg8 vs jpeg-turbo
On 2013-04-25, Mathieu Malaterre ma...@debian.org wrote: Chicken egg issue, until everyone follow debian and uses libjpeg9, there may be surprise. Everyone seems to head towards libjpeg-turbo. 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. And because of the image format changes, some of my upstreams are going to force using libjpeg-turbo because they do not want or need jpeg files that are incompatible with the world. /Sune -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnknhns9.fhs.nos...@sshway.ssh.pusling.com
Re: jpeg8 vs jpeg-turbo
Riku Voipio wrote: On Wed, Apr 24, 2013 at 03:19:59PM +0200, Bill Allombert wrote: 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. That *alone* sounds like a good argument for switching, to be honest... -- Steve McIntyre, Cambridge, UK.st...@einval.com -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1uvnew-xi...@mail.einval.com
Re: jpeg8 vs jpeg-turbo
[Mathieu Malaterre] 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. It happens. Look at the source for 'libc6'. It used to be glibc, these days it is a fork called eglibc. Likewise the source for the 'ssh' package was once SSH by Tatu Ylonen, these days it is a fork called OpenSSH maintained by some OpenBSD hackers. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130425152859.ga4...@p12n.org
Re: jpeg8 vs jpeg-turbo
On Wed, Apr 24, 2013 at 3:19 PM, Bill Allombert bill.allomb...@math.u-bordeaux1.fr wrote: On Wed, Apr 24, 2013 at 11:23:04AM +0200, Ondřej Surý wrote: Hi Bill and Debian Developers, My proposal is: A. Add libjpeg-turbo to Debian archive (that's easy) B. Add required provides/alternatives for libjpeg62-dev and libjpeg8-dev (where API/ABI match) C. Decide which package should provide default libjpeg-dev library 1. https://bitbucket.org/libgd/gd-libgd/issue/50/tests-jpeg-jpeg_readc-fails-on-debian 2. http://lists.fedoraproject.org/pipermail/devel/2013-January/176299.html 3. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=602034 As IJG libjpeg maintainer, my plan is to move to libjpeg9 which has more feature. I do not see libjpeg-turbo as a suitable replacement. It has 1) an different license. 2) much more security issues in a much smaller timeframe. 3) do not implement the full libjpeg8 ABI, nor the upcoming libjpeg9. Bill, sorry to barge in, but as a maintainer of the most prominent rev-deps of libjpeg (libgd2 php5-gd), I would like to have some questions answered, and I cannot find the answer neither on http://www.ijg.org/ nor http://www.infai.org/jpeg/. 1. Who is behind IJG? Is it just Guido Vollbeding or there are more people? 2. What's the legal status of IJG? 3. What is the relation of IJG and InfAI (http://www.infai.org/jpeg/)? 4. Is there a (public) bug tracker? 5. Is there a source repository? 6. Is there a mailing list for libjpeg development/users? 7. How do I contribute code to IJG libjpeg? 8. There are new features incorporated to libjpeg? Is that a community process? Or how are the changes driven? IJG (and the features they implement in libjpeg) is independent from jpeg.org (the standards committee). 9. Is there a documentation for new features of libjpeg (DCT, SmartScale), so independent implementations can be done? 10. And what is JPEGClub (http://jpegclub.org/)? (Just found it in the comment rant under: http://blog.kaourantin.net/?p=116) I haven't been able to find answers at IJG or any linked sites, so as you are so far the only one taking stand for IJG jpeg implementation, I would like to to help me to answer those questions. I wouldn't bother to care about libjpeg in Debian, but it's one of the core graphics libraries, and I think we should strive for good compatibility with the rest of the distros, applications and our users. And the 'new features' of libjpeg seems to contradict this. Ondrej -- Ondřej Surý ond...@sury.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caljhhg-6u1y0v50zxuzn-2zcgomxy0dg5qb7cqsyc2m1zlz...@mail.gmail.com
Re: jpeg8 vs jpeg-turbo
On Wed, Apr 24, 2013 at 11:23:04AM +0200, Ondřej Surý wrote: A. Add libjpeg-turbo to Debian archive (that's easy) Not really (especially if you want it to ship libjpeg.so.* too). -- WBR, wRAR -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130424093046.ga13...@belkar.wrar.name
Re: jpeg8 vs jpeg-turbo
On Wed, 24 Apr 2013 15:30:46 +0600, Andrey Rahmatullin wrote: On Wed, Apr 24, 2013 at 11:23:04AM +0200, Ondřej Surý wrote: A. Add libjpeg-turbo to Debian archive (that's easy) Not really (especially if you want it to ship libjpeg.so.* too). We have a plenty of libraries (and other packages) who do conflict between themselves, so we know the drill. Also Debian no longer ships libjpeg62, so there's not conflict there at least for baseline implementation (libjpeg62 API/ABI). Remember we are speaking about wheezy+1 now. For libjpeg8-turbo you can just declare Conflict with libjpeg8 and it will be used just in the applications who explicitly link with libjpeg-turbo-dev. Still easy. O. P.S.: I was not subscribed to debian-devel (I will do for sake of this issue), so this email has been reconstructed from the archive, thus there are neither References: nor In-Reply-To: headers. Sorry for breaking the threading. -- Ondřej Surý ond...@sury.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caljhhg_y2vxhe8tdxvikhjyqgvhumug1ekuwqgwx4renui3...@mail.gmail.com
Re: jpeg8 vs jpeg-turbo
On Wed, Apr 24, 2013 at 11:23:04AM +0200, Ondřej Surý wrote: Hi Bill and Debian Developers, My proposal is: A. Add libjpeg-turbo to Debian archive (that's easy) B. Add required provides/alternatives for libjpeg62-dev and libjpeg8-dev (where API/ABI match) C. Decide which package should provide default libjpeg-dev library 1. https://bitbucket.org/libgd/gd-libgd/issue/50/tests-jpeg-jpeg_readc-fails-on-debian 2. http://lists.fedoraproject.org/pipermail/devel/2013-January/176299.html 3. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=602034 As IJG libjpeg maintainer, my plan is to move to libjpeg9 which has more feature. I do not see libjpeg-turbo as a suitable replacement. It has 1) an different license. 2) much more security issues in a much smaller timeframe. 3) do not implement the full libjpeg8 ABI, nor the upcoming libjpeg9. Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130424131959.GD3132@yellowpig
Re: jpeg8 vs jpeg-turbo
On Wed, Apr 24, 2013 at 9:19 PM, Bill Allombert bill.allomb...@math.u-bordeaux1.fr wrote: On Wed, Apr 24, 2013 at 11:23:04AM +0200, Ondřej Surý wrote: Hi Bill and Debian Developers, My proposal is: A. Add libjpeg-turbo to Debian archive (that's easy) B. Add required provides/alternatives for libjpeg62-dev and libjpeg8-dev (where API/ABI match) C. Decide which package should provide default libjpeg-dev library 1. https://bitbucket.org/libgd/gd-libgd/issue/50/tests-jpeg-jpeg_readc-fails-on-debian 2. http://lists.fedoraproject.org/pipermail/devel/2013-January/176299.html 3. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=602034 As IJG libjpeg maintainer, my plan is to move to libjpeg9 which has more feature. From a user's prospective, I don't think adding bunches of not widely used features is that useful (I mean it's useful but not that important), but speed does matter a lot, especially on slower hardware like ARM-boards. -- Regards, Aron Xu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAMr=8w7KO=g7vi+uymphed5jp9xqxpgtvxaj0-c6_ax-ugz...@mail.gmail.com
Re: jpeg8 vs jpeg-turbo
On 04/24/2013 05:23 PM, Ondřej Surý wrote: Hi Bill and Debian Developers, while doing work on GD Library 2.1.0 it was discovered there's encoding incompatibility introduced by libjpeg8/9 [1]. While doing further research I have found that Fedora has switched to libjpeg-turbo[2] (for reasoning please read the referred email). Ubuntu (and Steam) is also using libjpeg-turbo as base jpeg library. SuSE has also switched to libjpeg-turbo some time ago (just had a quick chat with it's maintainer). Debian has already open ITP[3] #602034 for libjpeg-turbo Just being curious... Is the -turbo called this was because it's faster? How much faster is it then? Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5177f661.30...@debian.org
Re: jpeg8 vs jpeg-turbo
On Wed, Apr 24, 2013 at 11:12:33PM +0800, Thomas Goirand wrote: Just being curious... Is the -turbo called this was because it's faster? How much faster is it then? Hi, Thomas, The very first hit on the duckduckgo.com search engine for search expression libjpeg-turbo (not including the quotes) is a pointer to a git repository on github.com. The second hit is a link to http://libjpeg-turbo.virtualgl.org/. Both contain the following information (README-turbo.txt in the git repo): libjpeg-turbo is a JPEG image codec that uses SIMD instructions (MMX, SSE2, NEON) to accelerate baseline JPEG compression and decompression on x86, x86-64, and ARM systems. On such systems, libjpeg-turbo is generally 2-4x as fast as libjpeg, all else being equal. On other types of systems, libjpeg-turbo can still outperform libjpeg by a significant amount, by virtue of its highly-optimized Huffman coding routines. In many cases, the performance of libjpeg-turbo rivals that of proprietary high-speed JPEG codecs. This service has been provided to you by the Association for spreading the word on search engines. It has been my pleasure to look up this information for you. I hope we may count you as a future member in the association! -- http://www.cafepress.com/trunktees -- geeky funny T-shirts http://gtdfh.branchable.com/ -- GTD for hackers -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130424152447.gp4...@mavolio.codethink.co.uk
Re: jpeg8 vs jpeg-turbo
❦ 24 avril 2013 13:08 CEST, Ondřej Surý ond...@sury.org : We have a plenty of libraries (and other packages) who do conflict between themselves, so we know the drill. Also Debian no longer ships libjpeg62, so there's not conflict there at least for baseline implementation (libjpeg62 API/ABI). Remember we are speaking about wheezy+1 now. For libjpeg8-turbo you can just declare Conflict with libjpeg8 and it will be used just in the applications who explicitly link with libjpeg-turbo-dev. Which means that some applications won't be coinstallable? -- Don't use conditional branches as a substitute for a logical expression. - The Elements of Programming Style (Kernighan Plauger) pgpRFWpE4OAdn.pgp Description: PGP signature
Re: jpeg8 vs jpeg-turbo
Vincent Bernat ber...@debian.org writes: ❦ 24 avril 2013 13:08 CEST, Ondřej Surý ond...@sury.org : We have a plenty of libraries (and other packages) who do conflict between themselves, so we know the drill. Also Debian no longer ships libjpeg62, so there's not conflict there at least for baseline implementation (libjpeg62 API/ABI). Remember we are speaking about wheezy+1 now. For libjpeg8-turbo you can just declare Conflict with libjpeg8 and it will be used just in the applications who explicitly link with libjpeg-turbo-dev. Which means that some applications won't be coinstallable? For this to be viable, you'd need to do the same thing that we do for MIT Kerberos and Heimdal, namely: * Create conflicting -dev packages. - For special bonus points, have both conflicting and co-installable ones, as with the -multidev Kerberos packages. * Give the libraries different SONAMEs. * Ensure both libraries use symbol versioning with different versions. * Ensure the shared library packages are coinstallable. Note that you will still lose if you run into a situation where some piece JPEG library data has to be shared between two other shared libraries, one of which uses one library and one of which uses the other. I don't know if we have such a situation. (There are some edge cases like that with the Kerberos libraries; for example, it's possible to use libremctl from inside an application linked with Heimdal, but you get a link-time warning and MEMORY ticket caches don't work because the two libraries use independent data structures.) -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87sj2fpoie@windlord.stanford.edu
Re: jpeg8 vs jpeg-turbo
On Wed, Apr 24, 2013 at 03:11:53PM -0700, Russ Allbery wrote: We have a plenty of libraries (and other packages) who do conflict between themselves, so we know the drill. Also Debian no longer ships libjpeg62, so there's not conflict there at least for baseline implementation (libjpeg62 API/ABI). Remember we are speaking about wheezy+1 now. For libjpeg8-turbo you can just declare Conflict with libjpeg8 and it will be used just in the applications who explicitly link with libjpeg-turbo-dev. Which means that some applications won't be coinstallable? For this to be viable, you'd need to do the same thing that we do for MIT Kerberos and Heimdal, namely: * Create conflicting -dev packages. - For special bonus points, have both conflicting and co-installable ones, as with the -multidev Kerberos packages. * Give the libraries different SONAMEs. * Ensure both libraries use symbol versioning with different versions. * Ensure the shared library packages are coinstallable. This will also lead to an unnecessary choice for each maintainer of packages using libjpeg: they will need to choose the implementation to use. -- WBR, wRAR signature.asc Description: Digital signature
Re: jpeg8 vs jpeg-turbo
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? 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. Riku -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130425041740.ga2...@afflict.kos.to
