Re: Bug#602034: jpeg8 vs jpeg-turbo
Hi all, On Do 25 Apr 2013 22:29:53 CEST Michael Biebl wrote: Am 25.04.2013 20:49, schrieb Mike Gabriel: Can this be a proposal? Package libjpeg and libjpeg-turbo using an alternatives setup and thus, making both libs installable in parallel. Packagers can then build-depend on one or the other libjpeg implementations. Please no. If libjpeg-turbo is the saner implementation, which reading through the messages posted so far it seems like, let's switch to it fully. +1 from me, as well. I have been using the drop-in replacement packages that we provide via the upstream X2Go Debian-compatible package archive for months now and have not found any restraints, so far. How can a consensus on this issue be reached? Mike -- DAS-NETZWERKTEAM mike gabriel, rothenstein 5, 24214 neudorf-bornstein fon: +49 (1520) 1976 148 GnuPG Key ID 0x25771B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb pgpchqwWbU3L9.pgp Description: Digitale PGP-Unterschrift
Re: Bug#602034: jpeg8 vs jpeg-turbo
On 25/04/13 20:39, Pau Garcia i Quiles wrote: It boils down to jpeg6-2 is the only important thing. Forget about jpeg8 and jpeg9, which bring incompatible changes. There are other features in newer libjpeg that packages do need, even when not using exotic JPEG-like formats. For instance, ioquake3 uses the jpeg_mem_src() (ability to load JPEGs from a memory buffer, not just from a file on disk) and previously carried it as a local patch to its embeddded copy of IJG jpeg6b. (It now embeds IJG jpeg8c instead, and is built against the system libjpeg8-dev in Debian.) I believe that means that ioquake3 can be built unpatched against either IJG libjpeg8 or a sufficiently new libjpeg-turbo, but not against IJG libjpeg6b (although if there was libjpeg6b2 release with jpeg_mem_src(), I think that'd also work). S -- 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/517a6517.5080...@debian.org
Re: Bug#602034: jpeg8 vs jpeg-turbo
On Fri, 2013-04-26 at 12:29 +0100, Simon McVittie wrote: On 25/04/13 20:39, Pau Garcia i Quiles wrote: It boils down to jpeg6-2 is the only important thing. Forget about jpeg8 and jpeg9, which bring incompatible changes. There are other features in newer libjpeg that packages do need, even when not using exotic JPEG-like formats. For instance, ioquake3 uses the jpeg_mem_src() (ability to load JPEGs from a memory buffer, not just from a file on disk) [...] That seems to be a pretty simple convenience function which could easily be added in either libjpeg-turbo or the applications that want it. Ben. -- Ben Hutchings Klipstein's 4th Law of Prototyping and Production: A fail-safe circuit will destroy others. signature.asc Description: This is a digitally signed message part
Re: Bug#602034: jpeg8 vs jpeg-turbo
On Fri, Apr 26, 2013 at 12:29:27PM +0100, Simon McVittie wrote: On 25/04/13 20:39, Pau Garcia i Quiles wrote: It boils down to jpeg6-2 is the only important thing. Forget about jpeg8 and jpeg9, which bring incompatible changes. There are other features in newer libjpeg that packages do need, even when not using exotic JPEG-like formats. For instance, ioquake3 uses the jpeg_mem_src() (ability to load JPEGs from a memory buffer, not just from a file on disk) and previously carried it as a local patch to its embeddded copy of IJG jpeg6b. (It now embeds IJG jpeg8c instead, and is built against the system libjpeg8-dev in Debian.) I believe that means that ioquake3 can be built unpatched against either IJG libjpeg8 or a sufficiently new libjpeg-turbo, but not against IJG ^ libjpeg6b (although if there was libjpeg6b2 release with jpeg_mem_src(), I think that'd also work). If it works with libjpeg-turbo, what's the problem? -- ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ -- 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/20130426122747.ga7...@angband.pl
Re: Bug#602034: jpeg8 vs jpeg-turbo
On Fri, Apr 26, 2013 at 02:27:47PM +0200, Adam Borowski wrote: It boils down to jpeg6-2 is the only important thing. Forget about jpeg8 and jpeg9, which bring incompatible changes. There are other features in newer libjpeg that packages do need, even when not using exotic JPEG-like formats. For instance, ioquake3 uses the jpeg_mem_src() (ability to load JPEGs from a memory buffer, not just from a file on disk) and previously carried it as a local patch to its embeddded copy of IJG jpeg6b. (It now embeds IJG jpeg8c instead, and is built against the system libjpeg8-dev in Debian.) I believe that means that ioquake3 can be built unpatched against either IJG libjpeg8 or a sufficiently new libjpeg-turbo, but not against IJG ^ libjpeg6b (although if there was libjpeg6b2 release with jpeg_mem_src(), I think that'd also work). If it works with libjpeg-turbo, what's the problem? That was an answer to a different statement. -- 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/20130426130626.ga23...@belkar.wrar.name
Re: Bug#602034: jpeg8 vs jpeg-turbo
Hi all, On Do 25 Apr 2013 18:41:40 CEST Ondřej Surý wrote: 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) All questions are really good questions. Some of them have already been answered in the backlogs of #602034 [1] and the-merged-with bug #612341 [2]. Reading through both of them is probably a good idea for all who are interested in the complete story. Esp. some statements from Guido Vollbeding [3] make me ask myself: hey, what kind of guy is that and what is the stand of the IJG in the free software ecosystem. His arguing tends to be somehow aggressive and inbalanced. One quote that shows what I mean (taken from [3]): It seems that Bill Allombert is still one of the few sane people out there, many others have apparently gone mad. I don't care for the ignorant people. @Bill: Unfortunately, I am not an expert with image processing, but most of what I have read in this thread speaks for re-thinking the current strategy of staying with libjpeg IJG. Can this be a proposal? Package libjpeg and libjpeg-turbo using an alternatives setup and thus, making both libs installable in parallel. Packagers can then build-depend on one or the other libjpeg implementations. Greets, Mike [1] http://bugs.debian.org/602034 [2] http://bugs.debian.org/612341 [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612341#116 -- DAS-NETZWERKTEAM mike gabriel, rothenstein 5, 24214 neudorf-bornstein fon: +49 (1520) 1976 148 GnuPG Key ID 0x25771B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb pgpqfFSaGlVaK.pgp Description: Digitale PGP-Unterschrift
Re: Bug#602034: jpeg8 vs jpeg-turbo
On Thu, 2013-04-25 at 20:49 +0200, Mike Gabriel wrote: Hi all, On Do 25 Apr 2013 18:41:40 CEST Ondřej Surý wrote: 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) All questions are really good questions. Some of them have already been answered in the backlogs of #602034 [1] and the-merged-with bug #612341 [2]. Reading through both of them is probably a good idea for all who are interested in the complete story. Esp. some statements from Guido Vollbeding [3] make me ask myself: hey, what kind of guy is that and what is the stand of the IJG in the free software ecosystem. His arguing tends to be somehow aggressive and inbalanced. One quote that shows what I mean (taken from [3]): [...] He also says that he is treating his libjpeg as 'reference code' for JPEG, i.e. for demonstrating and testing extensions to the JPEG standard. This does not sound like production code or a suitable substitute for the established libjpeg which supported JFIF and little else (i.e. everything that's in common use) and had a very stable API for that. Maybe when the ink is dry on JPEG 201x then we will want a new libjpeg (perhaps an entirely separate library) that supports it. But we don't need it now. Ben. -- Ben Hutchings Klipstein's 4th Law of Prototyping and Production: A fail-safe circuit will destroy others. signature.asc Description: This is a digitally signed message part
Re: Bug#602034: jpeg8 vs jpeg-turbo
Hello, The KDE maintainer in Fedora started an interesting discussion some time ago in Digikam's mailing list. There was input from the very IJG: http://mail.kde.org/pipermail/digikam-devel/2013-January/066206.html It boils down to jpeg6-2 is the only important thing. Forget about jpeg8 and jpeg9, which bring incompatible changes. http://mail.kde.org/pipermail/digikam-devel/2013-January/066256.html FWIW, Arch and Gentoo also follow the policy that jpeg6-2 (and jpeg-turbo with 6-2 API/ABI) is the real deal. On Wed, Apr 24, 2013 at 1:48 PM, Mike Gabriel mike.gabr...@das-netzwerkteam.de wrote: Hi Ondřej, I have just uploaded libjpeg-turbo to Debian and it still hovers in NEW [1]. On Mi 24 Apr 2013 11:23:04 CEST Ondřej Surý wrote: Debian has already open ITP[3] #602034 for libjpeg-turbo, which support libjpeg62 API/ABI and also some important bits of libjpeg8. As libjpeg is one of the base libraries of the system, I think it might be a good idea to discuss this project wide. Also although I have an opinion (as you might have guessed from this email) that we should try to be aligned with other distributions and the reasoning for not going for , I will be happy with whatever result will end-up. 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. A. Add libjpeg-turbo to Debian archive (that's easy) Done. Waiting in NEW. Only containing libturbojpeg.so.1 B. Add required provides/alternatives for libjpeg62-dev and libjpeg8-dev (where API/ABI match) A packaging example can be seen in [1]. If the packages disappears from the NEW queue, you can also obtain a libjpeg-turbo version with compat packages provided here [3]. C. Decide which package should provide default libjpeg-dev library Last statement from Bill: libjpeg by IJG Greets, Mike [1] http://ftp-master.debian.org/**new/libjpeg-turbo_1.2.90-2.**htmlhttp://ftp-master.debian.org/new/libjpeg-turbo_1.2.90-2.html [2] http://ftp-master.debian.org/**new/libjpeg-turbo_1.2.90-1.**htmlhttp://ftp-master.debian.org/new/libjpeg-turbo_1.2.90-1.html [3] http://packages.x2go.org/**debian/pool/main/libj/libjpeg-**turbo/http://packages.x2go.org/debian/pool/main/libj/libjpeg-turbo/ -- DAS-NETZWERKTEAM mike gabriel, rothenstein 5, 24214 neudorf-bornstein fon: +49 (1520) 1976 148 GnuPG Key ID 0x25771B31 mail: mike.gabriel@das-netzwerkteam.**demike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.**de/freebusy/m.gabriel%40das-** netzwerkteam.de.xfbhttps://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Re: Bug#602034: jpeg8 vs jpeg-turbo
Am 25.04.2013 20:49, schrieb Mike Gabriel: Can this be a proposal? Package libjpeg and libjpeg-turbo using an alternatives setup and thus, making both libs installable in parallel. Packagers can then build-depend on one or the other libjpeg implementations. Please no. If libjpeg-turbo is the saner implementation, which reading through the messages posted so far it seems like, let's switch to it fully. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Bug#602034: jpeg8 vs jpeg-turbo
On Apr 25, Michael Biebl bi...@debian.org wrote: Please no. If libjpeg-turbo is the saner implementation, which reading through the messages posted so far it seems like, let's switch to it fully. Agreed. -- ciao, Marco signature.asc Description: Digital signature
Re: Bug#602034: jpeg8 vs jpeg-turbo
I think this might be a good move, since the libjpeg-turbo maintainer still wants to keep compatibility with libjpeg7/8, and he doesn't want to implement incompatible changes, which might be introduced when coding Jpeg2000 or JpegXR. And if there's and consensus in the community that libjpeg-turbo is way to go, he might be brave and implement the real standards codified by the Joint Photographic Experts Group, which would be something I consider good (adhere to standard for interoperability). See: http://sourceforge.net/p/libjpeg-turbo/discussion/1086868/thread/40a03431/ http://sourceforge.net/p/libjpeg-turbo/feature-requests/4/ O. On Thu, Apr 25, 2013 at 10:43 PM, Marco d'Itri m...@linux.it wrote: On Apr 25, Michael Biebl bi...@debian.org wrote: Please no. If libjpeg-turbo is the saner implementation, which reading through the messages posted so far it seems like, let's switch to it fully. Agreed. -- ciao, Marco -- 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/caljhhg8ws6nbbz2ufig+4uy9bpmg5ms7epfjpydqpkaqkad...@mail.gmail.com
Re: Bug#602034: jpeg8 vs jpeg-turbo
Hi Ondřej, I have just uploaded libjpeg-turbo to Debian and it still hovers in NEW [1]. On Mi 24 Apr 2013 11:23:04 CEST Ondřej Surý wrote: Debian has already open ITP[3] #602034 for libjpeg-turbo, which support libjpeg62 API/ABI and also some important bits of libjpeg8. As libjpeg is one of the base libraries of the system, I think it might be a good idea to discuss this project wide. Also although I have an opinion (as you might have guessed from this email) that we should try to be aligned with other distributions and the reasoning for not going for , I will be happy with whatever result will end-up. 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. A. Add libjpeg-turbo to Debian archive (that's easy) Done. Waiting in NEW. Only containing libturbojpeg.so.1 B. Add required provides/alternatives for libjpeg62-dev and libjpeg8-dev (where API/ABI match) A packaging example can be seen in [1]. If the packages disappears from the NEW queue, you can also obtain a libjpeg-turbo version with compat packages provided here [3]. C. Decide which package should provide default libjpeg-dev library Last statement from Bill: libjpeg by IJG Greets, Mike [1] http://ftp-master.debian.org/new/libjpeg-turbo_1.2.90-2.html [2] http://ftp-master.debian.org/new/libjpeg-turbo_1.2.90-1.html [3] http://packages.x2go.org/debian/pool/main/libj/libjpeg-turbo/ -- DAS-NETZWERKTEAM mike gabriel, rothenstein 5, 24214 neudorf-bornstein fon: +49 (1520) 1976 148 GnuPG Key ID 0x25771B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb pgpWHuuhFcxQJ.pgp Description: Digitale PGP-Unterschrift
Re: Bug#602034: jpeg8 vs jpeg-turbo
On Wed, Apr 24, 2013 at 01:48:48PM +0200, Mike Gabriel wrote: C. Decide which package should provide default libjpeg-dev library Last statement from Bill: libjpeg by IJG The current IJG has nothing to do with the IJG that originally created JPEG. The last activity of original IJG was in 1998, while new IJG surfaced in 2009. Thus we actually have two forks: 1) the new IJG libjpeg, which changes API/ABI of the original libjpeg library, and adds new features to JPEG image format. However the new image format features have been rejected as not improving image quality or compression ratio[1]. The new IJG has no mailing list, VCS or any or other sign of actually being group - all apparent IJG work seems to come from a single person. The website of IJG[2] is void of details - who is in IJG? - how does it make decisions like changing the JPEG image format to add SmartScale support? There is even no place to send bug reports! 2) libjpeg-turbo remains API/ABI and binary format compatible with original libjpeg. The most significant improvements are in supporting SIMD features to make JPEG image encoding and decoding faster on modern cpu's. Libjpeg-turbo website [3] has all the signs of an healthy open source project - A SVN repo with many commiters, bug tracker, a mailing list with open discussion etc. So the Debian options is to choose a libjpeg fork that changes the jpeg image format, or one that renders images fast. At the moment the first fork is being advertized with IJG name, thus painting an image of official upstream. But it isn't - especially not now when the changes libjpeg8 added to JPEG standard have been rejected from the ISO standard. Riku [1] http://hardwarebug.org/2010/02/01/ijg-swings-again-and-misses/ [2] http://www.ijg.org/ [3] http://www.libjpeg-turbo.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/20130424140150.ga31...@afflict.kos.to
Re: Bug#602034: jpeg8 vs jpeg-turbo
On Wed, Apr 24, 2013 at 05:01:50PM +0300, Riku Voipio wrote: Libjpeg-turbo website [3] has all the signs of an healthy open source project - A SVN repo with many commiters, bug tracker, a mailing list with open discussion etc. libjpeg-turbo is also used by webkit, blink, and gecko. Mike -- 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/20130424142644.ga20...@glandium.org
