hi there,
Can it be updated to upstream version in rawhide ?
The libjpeg version(6b) in Fedora is quite old(27-Mar-1998). And newer versions were released on:
Version 7 27-Jun-2009 Version 8 10-Jan-2010 Version 8a 28-Feb-2010 Version 8b 16-May-2010 http://www.ijg.org/
libpng also needs some care, 1.4 tree was releasd on jan-2010: http://www.libpng.org/pub/png/src/libpng-1.2.x-to-1.4.x-summary.txt http://www.libpng.org/pub/png/src/libpng-1.4.1-README.txt http://www.libpng.org/pub/png/src/libpng-1.4.2-README.txt
But, the maintainer of the packages is not very receptive.
-thanks-
On Sat, May 22, 2010 at 17:55:39 +0200, Xose Vazquez Perez xose.vazquez@gmail.com wrote:
hi there,
Can it be updated to upstream version in rawhide ?
Normally you want to file an RFE bug against the package. That way the request doesn't get lost. (It still might not get done right away.)
On 05/22/2010 11:41 PM, Bruno Wolff III wrote:
On Sat, May 22, 2010 at 17:55:39 +0200, Xose Vazquez Perez xose.vazquez@gmail.com wrote:
hi there,
Can it be updated to upstream version in rawhide ?
Normally you want to file an RFE bug against the package. That way the request doesn't get lost. (It still might not get done right away.)
*RE*opened:
https://bugzilla.redhat.com/show_bug.cgi?id=563890 https://bugzilla.redhat.com/show_bug.cgi?id=569055
Sorry - there is reticence to update from something that is 12 years old ... did I understand that correctly .. if so I am stunned.
gene
Now we have those libs in repo libpng10 for libpng1.0 libpng for libpng 1.2 libjpeg for libjpeg 6b
Is it possible to package all version of libjpeg and libpng parallelly as libpng and libpng10? redhat-lsb only depends on soname, if we package multi-version, it won't break anything. Maybe we can rename libpng to libpng12, rename libjepg to libjpeg6b, then update libpng and libjpeg to the lastest version.
Chen Lei
Xose Vazquez Perez xose.vazquez@gmail.com writes:
Can it be updated to upstream version in rawhide ?
I've been told (though this may well be inaccurate) that the LSB requires libjpeg 6b. If so, that would pose a problem for adopting the non-ABI-compatible version 8. In any case I'm not eager to force a recompile of everything that depends on it ...
regards, tom lane
On Sat, May 22, 2010 at 10:23:05PM -0400, Tom Lane wrote:
Xose Vazquez Perez xose.vazquez@gmail.com writes:
Can it be updated to upstream version in rawhide ?
I've been told (though this may well be inaccurate) that the LSB requires libjpeg 6b. If so, that would pose a problem for adopting the non-ABI-compatible version 8.
We don't seem to have any policy, guidelines, or even any mailing list discussions that I can recall that tell us to what extent LSB compliance is something we have to watch out for in Fedora. Perhaps we need to have that discussion and then decide whether we need to parallel install 8b or not.
In any case I'm not eager to force a recompile of everything that depends on it ...
This is not at all a blocker criteria for rawhide at the beginning of the release cycle.... We do practically whole distro rebuilds for gcc updates; doing a rebuild for things that depend on libjpeg is not a big deal compared to that.
-Toshio
On Sat, May 22, 2010 at 10:23:05PM -0400, Tom Lane wrote:
Xose Vazquez Perez xose.vazquez@gmail.com writes:
Can it be updated to upstream version in rawhide ?
I've been told (though this may well be inaccurate) that the LSB requires libjpeg 6b. If so, that would pose a problem for adopting the non-ABI-compatible version 8. In any case I'm not eager to force a recompile of everything that depends on it ...
Regarding the possibility of parallel installing, I just did a test compile of jpeg-8b; Looks like it creates a library with SONAME of libjpeg.so.8 and our current libjpeg which has libjpeg.so.62
-Toshio
redhat-lsb 4.0-2 is broken now, the author add requires after %description.
See http://koji.fedoraproject.org/koji/rpminfo?rpmID=1768691
Chen Lei
Tom Lane wrote:
I've been told (though this may well be inaccurate) that the LSB requires libjpeg 6b.
It is NOT a goal of Fedora to be LSB-compliant. It IS a goal of Fedora to ship the latest available Free Software. So please upgrade libjpeg in Rawhide to the current upstream version.
In any case I'm not eager to force a recompile of everything that depends on it ...
This is quite normal in Rawhide, we've been through this with many other core libraries.
Kevin Kofler
On 05/23/2010 04:23 AM, Tom Lane wrote:
I've been told (though this may well be inaccurate) that the LSB requires libjpeg 6b. If so, that would pose a problem for adopting the non-ABI-compatible version 8. In any case I'm not eager to force a recompile of everything that depends on it ...
To be clear, this is fedora.
RHEL is in the next door!
Xose Vazquez Perez wrote:
On 05/23/2010 04:23 AM, Tom Lane wrote:
I've been told (though this may well be inaccurate) that the LSB requires libjpeg 6b. If so, that would pose a problem for adopting the non-ABI-compatible version 8. In any case I'm not eager to force a recompile of everything that depends on it ...
To be clear, this is fedora.
RHEL is in the next door!
Hmmm, isn't RHEL 5 actually many floors downstairs? ;-)
RHEL 6 is not so far from here, ok, but the room appears to be still full of noisy and dangerous working tools. ;-)
Xose Vazquez Perez wrote:
To be clear, this is fedora.
RHEL is in the next door!
+1
Please do not ship old crap just to comply with the LSB. Due to how the LSB works, the LSB follows what we do (since Fedora's stuff eventually ends up in RHEL and RHEL is one of the distros the LSB looks at to decide what to standardize on), not the other way round. If we wait for the LSB, not only are we failing to meet our objectives, but we also have a chicken&egg problem.
Kevin Kofler
On Sat, May 22, 2010 at 05:55:39PM +0200, Xose Vazquez Perez wrote:
The libjpeg version(6b) in Fedora is quite old(27-Mar-1998). And newer versions were released on:
Version 7 27-Jun-2009 Version 8 10-Jan-2010 Version 8a 28-Feb-2010 Version 8b 16-May-2010 http://www.ijg.org/
libjpeg has an odd upstream. We needed some build fixes to be included for the Windows cross-compiler, but found the current upstream to be unresponsive (although at least they're making releases now ...)
There's also this project, to add hardware acceleration (SSE and so on) to libjpeg:
http://libjpeg-turbo.virtualgl.org/
If we're going to switch, maybe this is a good choice.
Rich.
On Mon, May 24, 2010 at 2:24 PM, Richard W.M. Jones rjones@redhat.com wrote:
On Sat, May 22, 2010 at 05:55:39PM +0200, Xose Vazquez Perez wrote:
The libjpeg version(6b) in Fedora is quite old(27-Mar-1998). And newer versions were released on:
Version 7 27-Jun-2009 Version 8 10-Jan-2010 Version 8a 28-Feb-2010 Version 8b 16-May-2010 http://www.ijg.org/
libjpeg has an odd upstream. We needed some build fixes to be included for the Windows cross-compiler, but found the current upstream to be unresponsive (although at least they're making releases now ...)
There's also this project, to add hardware acceleration (SSE and so on) to libjpeg:
http://libjpeg-turbo.virtualgl.org/
If we're going to switch, maybe this is a good choice.
If it works as a drop in replacement it is an obvious choice, jpeg de/compression is a rather common task a 2-4 speedup (as claimed on the page) would be rather nice.
repoquery --whatrequires --alldeps libpng10 libpng10-0:1.0.53-1.fc14.x86_64 libpng10-0:1.0.53-1.fc14.i686 gnome-libs-1:1.4.2-15.fc12.i686 libpng10-devel-0:1.0.53-1.fc14.i686 gnome-libs-1:1.4.2-15.fc12.x86_64 libpng10-devel-0:1.0.53-1.fc14.x86_64
libpng10 is removed in many distributions including debian, ubuntu, arch, why it still be maintained in fedora?
Do we have a policy to remove long legacy libs?
Chen Lei
On Tue, May 25, 2010 at 12:31 PM, Chen Lei supercyper1@gmail.com wrote:
repoquery --whatrequires --alldeps libpng10 libpng10-0:1.0.53-1.fc14.x86_64 libpng10-0:1.0.53-1.fc14.i686 gnome-libs-1:1.4.2-15.fc12.i686 libpng10-devel-0:1.0.53-1.fc14.i686 gnome-libs-1:1.4.2-15.fc12.x86_64 libpng10-devel-0:1.0.53-1.fc14.x86_64
libpng10 is removed in many distributions including debian, ubuntu, arch, why it still be maintained in fedora?
Do we have a policy to remove long legacy libs?
Chen Lei
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
I'm curious as to what Debian/Ubuntu are using as a replacement for libpng10?
2010/5/25 Chris Jones chrisjones@comcen.com.au
I'm curious as to what Debian/Ubuntu are using as a replacement for libpng10?
Debian updated libpng10 to libpng12 long ago, they don't keep multiversion
libpng. Almost all packages which still depend on libpng10 is dead.inupstream.
Chen Lei
Right, so they're still using libpng* but the more updated version. I read the original post as not using libpng at all and using another library as an alternative. Sorry, my misunderstanding.
On Mon, 2010-05-24 at 13:24 +0100, Richard W.M. Jones wrote:
On Sat, May 22, 2010 at 05:55:39PM +0200, Xose Vazquez Perez wrote:
The libjpeg version(6b) in Fedora is quite old(27-Mar-1998). And newer versions were released on:
Version 7 27-Jun-2009 Version 8 10-Jan-2010 Version 8a 28-Feb-2010 Version 8b 16-May-2010 http://www.ijg.org/
libjpeg has an odd upstream. We needed some build fixes to be included for the Windows cross-compiler, but found the current upstream to be unresponsive (although at least they're making releases now ...)
There's also this project, to add hardware acceleration (SSE and so on) to libjpeg:
http://libjpeg-turbo.virtualgl.org/
If we're going to switch, maybe this is a good choice.
I did some profiling of this for the spice project, and it performed very well. I would very much like this to be in fedora, either as a separate library or as a replacement for libjpeg.
It is binary compatible with libjpeg, but contains some extra API not supported by the normal libjpeg.
On Tue, 2010-05-25 at 15:27 +0200, Alexander Larsson wrote: <snip>
There's also this project, to add hardware acceleration (SSE and so on) to libjpeg:
http://libjpeg-turbo.virtualgl.org/
If we're going to switch, maybe this is a good choice.
I did some profiling of this for the spice project, and it performed very well. I would very much like this to be in fedora, either as a separate library or as a replacement for libjpeg.
It is binary compatible with libjpeg, but contains some extra API not supported by the normal libjpeg.
Which means you'll have to make a choice as to which one to support if you want to handle JPEG files, and that we'll have to fix upgrades and new installations to install the preferred one, as they would have the same soname.
On Tue, May 25, 2010 at 02:57:37PM +0100, Bastien Nocera wrote:
On Tue, 2010-05-25 at 15:27 +0200, Alexander Larsson wrote:
<snip> > > There's also this project, to add hardware acceleration (SSE and so > > on) to libjpeg: > > > > http://libjpeg-turbo.virtualgl.org/ > > > > If we're going to switch, maybe this is a good choice. > > I did some profiling of this for the spice project, and it performed > very well. I would very much like this to be in fedora, either as a > separate library or as a replacement for libjpeg. > > It is binary compatible with libjpeg, but contains some extra API not > supported by the normal libjpeg.
Which means you'll have to make a choice as to which one to support if you want to handle JPEG files, and that we'll have to fix upgrades and new installations to install the preferred one, as they would have the same soname.
Why couldn't we just replace libjpeg with the libjpeg-turbo upstream? (For the primary architectures anyway).
Rich.
On 05/25/2010 10:09 AM, Richard W.M. Jones wrote:
Why couldn't we just replace libjpeg with the libjpeg-turbo upstream? (For the primary architectures anyway).
I think this is a great idea, libjpeg is the bottleneck for a lot of my code.
One issue: are there C fallbacks for all the arch-specific code? It would be great if secondary architectures could just use libjpeg-turbo as well.
Adam
Hi,
SSE and friends are arch. specific and according to the feature list the upstream is displaying, I don't think it would offer any other benefits for the other archs.
There is one strong point that libjpeg-{6b, 8ab} inherited since it's been there for a lof time: a *defacto* standard for JPEG compression/decompression that has been heavily depolyed, used and tested code for various application/, thoughtout the time, for more than a decade! I think that's important and would enable it to keep its place in the destribtion.
libjpeg-6b is at production level code, and it actually offers a couple of ways to accelerate JPEG decoding by turning on the IDCT level decimation (basically for free resize) and enabling YUV raw decodes.
How about this: since libjpeg is picking momentum and there are actually people updating the code base, why not push for a libjpeg-turbo merge into the original ijg's code and get Fedora to rebase on that unique source instead? That way ijg can test for any regressions using their conformance tests.
Regards, -Ilyes Gouta
On Tue, May 25, 2010 at 3:23 PM, Adam Goode adam@spicenitz.org wrote:
On 05/25/2010 10:09 AM, Richard W.M. Jones wrote:
Why couldn't we just replace libjpeg with the libjpeg-turbo upstream? (For the primary architectures anyway).
I think this is a great idea, libjpeg is the bottleneck for a lot of my code.
One issue: are there C fallbacks for all the arch-specific code? It would be great if secondary architectures could just use libjpeg-turbo as well.
Adam
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Tue, May 25, 2010 at 04:40:15PM +0100, Ilyes Gouta wrote:
How about this: since libjpeg is picking momentum and there are actually people updating the code base, why not push for a libjpeg-turbo merge into the original ijg's code and get Fedora to rebase on that unique source instead?
The problem, as I said before, is that the libjpeg upstream is not being developed in an open manner.
I've emailed Adam Tkac to bring his attention to this thread (he's involved with libjpeg-turbo) and hopefully he'll bring some more up to date information about this matter.
Rich.
On Tue, May 25, 2010 at 04:47:13PM +0100, Richard W.M. Jones wrote:
On Tue, May 25, 2010 at 04:40:15PM +0100, Ilyes Gouta wrote:
How about this: since libjpeg is picking momentum and there are actually people updating the code base, why not push for a libjpeg-turbo merge into the original ijg's code and get Fedora to rebase on that unique source instead?
The problem, as I said before, is that the libjpeg upstream is not being developed in an open manner.
Licensing is also an issue here. It's probably easier from licensing and project management perspective to merge the ijg libjpeg into libjpeg-turbo than vice versa.
I've emailed Adam Tkac to bring his attention to this thread (he's involved with libjpeg-turbo) and hopefully he'll bring some more up to date information about this matter.
Sounds good.
-Toshio
On Tue, May 25, 2010 at 04:47:13PM +0100, Richard W.M. Jones wrote:
On Tue, May 25, 2010 at 04:40:15PM +0100, Ilyes Gouta wrote:
How about this: since libjpeg is picking momentum and there are actually people updating the code base, why not push for a libjpeg-turbo merge into the original ijg's code and get Fedora to rebase on that unique source instead?
The problem, as I said before, is that the libjpeg upstream is not being developed in an open manner.
This is pretty big issue.
I've emailed Adam Tkac to bring his attention to this thread (he's involved with libjpeg-turbo) and hopefully he'll bring some more up to date information about this matter.
Sorry for late response, this mail got lost in my queue.
libjpeg-turbo is a fork of the original libjpeg-6b release created and maintained by VirtualGL and TigerVNC developers. Main focus is on performance and API+ABI compatibility with libjpeg. Although libjpeg-turbo contains MMX/SSE acceleration it also contains bunch of pure algorithmic enhancements so even if target platform doesn't support MMX/SSE libjpeg-turbo is around 25% faster than original libjpeg. When SSE is used then libjpeg and libjpeg-turbo performance is simply incomparable. And there are still number of areas for optimizations, for example on we are currently using only half of SSE registers on 64bit platforms.
About the merge of this code with the original ijg's code. Yes, I must admit it is possible but personally I don't like it much. In my opinion libjpeg-turbo is far more ahead than libjpeg so it's easier for us to incorporate libjpeg changes to libjpeg-turbo. And I'm not able to find CVS/SVN/git repository of the libjpeg code.
In my opinion if will be great benefit for Fedora to simply replace libjpeg by libjpeg-turbo. It works fine on secondary architectures and if processor doesn't support MMX/SSE then it falls back to non-ASM code (which is still faster than libjpeg code, as I wrote above).
Btw this library is used since Fedora 11 in tigervnc package for JPEG compression/decompression and it works without any problem on all supported platforms (x86, x86_64, ppc, ppc64) and also on s390(x).
So, if I summarize pros and cons for libjpeg-turbo:
+: _really_ faster than libjpeg more portable more open than IJG code API/ABI compatible with libjpeg (AFAIK) works on all platforms (not only on SSE capable platforms)
-: not developed by IJG :)
I'm going to create a Fedora feature for this task.
Regards, Adam
On Mon, May 31, 2010 at 05:33:38PM +0200, Adam Tkac wrote:
I'm going to create a Fedora feature for this task.
Done. You can check http://fedoraproject.org/wiki/Features/libjpeg-turbo.
Regards, Adam
On Mon, May 31, 2010 at 12:16 PM, Adam Tkac wrote:
On Mon, May 31, 2010 at 05:33:38PM +0200, Adam Tkac wrote:
I'm going to create a Fedora feature for this task.
Done. You can check http://fedoraproject.org/wiki/Features/libjpeg-turbo.
Thanks. Is there an SRPM we can give it a test?
Orcan
On Mon, May 31, 2010 at 12:51:56PM -0400, Orcan Ogetbil wrote:
On Mon, May 31, 2010 at 12:16 PM, Adam Tkac wrote:
On Mon, May 31, 2010 at 05:33:38PM +0200, Adam Tkac wrote:
I'm going to create a Fedora feature for this task.
Done. You can check http://fedoraproject.org/wiki/Features/libjpeg-turbo.
Thanks. Is there an SRPM we can give it a test?
Yes, I just created it, check http://atkac.fedorapeople.org/libjpeg-turbo. I also updated the feature page because no package linked against current libjpeg needs to be rebuilt, libjpeg-turbo is API/ABI compatible. You can simply build & install libjpeg-turbo and you should immediately see performance benefits.
If you prefer to test libjpeg-turbo in more conservative way you can build SRPM and then extract libjpeg.so from it (`rpm2cpio libjpeg-turbo.rpm | cpio -id`) and simply LD_PRELOAD it.
Regards, Adam
Hi,
I'm still interested in seeing a linjpeg-turbo merger with ijg's own code base. I'd say that the most performance boost brought in by libjpeg-turbo is due to the specialized SIMD routines, which theoretically can be easily merged. libjpeg-turbo has also some weaknesses such as (as provided from the project's homepage):
1. Worse chroma upsampling quality, where libjpeg-turbo is favoring speed over accuracy when upsamling the chroma components 2. JPEG's standard restart marker aren't properly handled, in favor of a faster huffman decoding 3. Asymetric performance gain between 32bit and 64bit arch., which means specific, per arch. code paths and not algorithmic and architecture wise tweaks that could benefit all the architectures.
To me, 1. and 2. are a bit worrying, I don't want to scarify standard correctness over a 15% perf. boost. The only items that stands out are the SIMD routines which can be merged with the ijg's official libjpeg, and I think we should push in that direction instead.
-Ilyes Gouta
On Tue, Jun 1, 2010 at 12:00 PM, Adam Tkac atkac@redhat.com wrote:
On Mon, May 31, 2010 at 12:51:56PM -0400, Orcan Ogetbil wrote:
On Mon, May 31, 2010 at 12:16 PM, Adam Tkac wrote:
On Mon, May 31, 2010 at 05:33:38PM +0200, Adam Tkac wrote:
I'm going to create a Fedora feature for this task.
Done. You can check http://fedoraproject.org/wiki/Features/libjpeg-turbo.
Thanks. Is there an SRPM we can give it a test?
Yes, I just created it, check http://atkac.fedorapeople.org/libjpeg-turbo. I also updated the feature page because no package linked against current libjpeg needs to be rebuilt, libjpeg-turbo is API/ABI compatible. You can simply build & install libjpeg-turbo and you should immediately see performance benefits.
If you prefer to test libjpeg-turbo in more conservative way you can build SRPM and then extract libjpeg.so from it (`rpm2cpio libjpeg-turbo.rpm | cpio -id`) and simply LD_PRELOAD it.
Regards, Adam
-- Adam Tkac, Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Tue, Jun 01, 2010 at 01:35:20PM +0100, Ilyes Gouta wrote:
Hi,
Hello,
I'm still interested in seeing a linjpeg-turbo merger with ijg's own code base. I'd say that the most performance boost brought in by libjpeg-turbo is due to the specialized SIMD routines, which theoretically can be easily merged. libjpeg-turbo has also some weaknesses such as (as provided from the project's homepage):
You are right, it will be better to join forces together with IJG. But as I wrote earlier, libjpeg-turbo is at my opinion far more ahead than IJG's source and is developed in more open-source manner. Additionally, as Tom Lane wrote, current maintainer of the IJG libjpeg doesn't care about API/ABI compatibility much.
- Worse chroma upsampling quality, where libjpeg-turbo is favoring
speed over accuracy when upsamling the chroma components
This is not enabled by default, you have to explicitly specify this behavior (TJ_FASTUPSAMPLE parameter).
- JPEG's standard restart marker aren't properly handled, in favor of
a faster huffman decoding
It is handled properly. When libjpeg-turbo hits restart marker then it must use slower huffman decoder which means 15% - 20% performance drop but is still much faster than IJG's libjpeg.
- Asymetric performance gain between 32bit and 64bit arch., which
means specific, per arch. code paths and not algorithmic and architecture wise tweaks that could benefit all the architectures.
Yes, usage of SSE is the main reason why libjpeg-turbo is much more faster than libjpeg. But as written on http://libjpeg-turbo.virtualgl.org/About/Performance, 32bit is slower due small number of registers; those registers are allocated by compiler, it's not assembler code, libjpeg-turbo is currently using same ASM code for both x86 and x64.
Regards, Adam
On Tue, Jun 01, 2010 at 01:35:20PM +0100, Ilyes Gouta wrote:
Hi,
I'm still interested in seeing a linjpeg-turbo merger with ijg's own code base. I'd say that the most performance boost brought in by libjpeg-turbo is due to the specialized SIMD routines, which theoretically can be easily merged. libjpeg-turbo has also some weaknesses such as (as provided from the project's homepage):
Note: Due to the licensing of the two libraries, I think it's more likely that libjpeg-turbo can merge the changes occurring in ijg jpeg than ijg jpeg merging libjpeg-turbo changes. So it might be better for you to look at what libjpeg-8b provides, what the cost is in compatibility, and decide whether we should propose those features be merged into libjpeg-turbo.
-Toshio
Hi Adam,
it also contains bunch of pure algorithmic enhancements so even if target platform doesn't support MMX/SSE libjpeg-turbo is around 25% faster than original libjpeg.
Can you please give some details on this point?
-Ilyes Gouta
On Mon, May 31, 2010 at 4:33 PM, Adam Tkac atkac@redhat.com wrote:
On Tue, May 25, 2010 at 04:47:13PM +0100, Richard W.M. Jones wrote:
On Tue, May 25, 2010 at 04:40:15PM +0100, Ilyes Gouta wrote:
How about this: since libjpeg is picking momentum and there are actually people updating the code base, why not push for a libjpeg-turbo merge into the original ijg's code and get Fedora to rebase on that unique source instead?
The problem, as I said before, is that the libjpeg upstream is not being developed in an open manner.
This is pretty big issue.
I've emailed Adam Tkac to bring his attention to this thread (he's involved with libjpeg-turbo) and hopefully he'll bring some more up to date information about this matter.
Sorry for late response, this mail got lost in my queue.
libjpeg-turbo is a fork of the original libjpeg-6b release created and maintained by VirtualGL and TigerVNC developers. Main focus is on performance and API+ABI compatibility with libjpeg. Although libjpeg-turbo contains MMX/SSE acceleration it also contains bunch of pure algorithmic enhancements so even if target platform doesn't support MMX/SSE libjpeg-turbo is around 25% faster than original libjpeg. When SSE is used then libjpeg and libjpeg-turbo performance is simply incomparable. And there are still number of areas for optimizations, for example on we are currently using only half of SSE registers on 64bit platforms.
About the merge of this code with the original ijg's code. Yes, I must admit it is possible but personally I don't like it much. In my opinion libjpeg-turbo is far more ahead than libjpeg so it's easier for us to incorporate libjpeg changes to libjpeg-turbo. And I'm not able to find CVS/SVN/git repository of the libjpeg code.
In my opinion if will be great benefit for Fedora to simply replace libjpeg by libjpeg-turbo. It works fine on secondary architectures and if processor doesn't support MMX/SSE then it falls back to non-ASM code (which is still faster than libjpeg code, as I wrote above).
Btw this library is used since Fedora 11 in tigervnc package for JPEG compression/decompression and it works without any problem on all supported platforms (x86, x86_64, ppc, ppc64) and also on s390(x).
So, if I summarize pros and cons for libjpeg-turbo:
+: _really_ faster than libjpeg more portable more open than IJG code API/ABI compatible with libjpeg (AFAIK) works on all platforms (not only on SSE capable platforms)
-: not developed by IJG :)
I'm going to create a Fedora feature for this task.
Regards, Adam
-- Adam Tkac, Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Mon, May 31, 2010 at 06:58:37PM +0100, Ilyes Gouta wrote:
Hi Adam,
Hello Ilyes,
it also contains bunch of pure algorithmic enhancements so even if target platform doesn't support MMX/SSE libjpeg-turbo is around 25% faster than original libjpeg.
Can you please give some details on this point?
Yes, of course. This topic was discussed on tigervnc-devel ML, check those threads:
http://www.mail-archive.com/tigervnc-devel@lists.sourceforge.net/msg00225.ht... http://www.mail-archive.com/tigervnc-devel@lists.sourceforge.net/msg00403.ht...
As said there, libjpeg-turbo has nearly same performance as Intel's IPP.
Regards, Adam
Ilyes Gouta wrote:
There is one strong point that libjpeg-{6b, 8ab} inherited since it's been there for a lof time: a *defacto* standard for JPEG compression/decompression that has been heavily depolyed, used and tested code for various application/, thoughtout the time, for more than a decade! I think that's important and would enable it to keep its place in the destribtion.
libjpeg-6b is at production level code, and it actually offers a couple of ways to accelerate JPEG decoding by turning on the IDCT level decimation (basically for free resize) and enabling YUV raw decodes.
This kind of arguments doesn't really make sense for Fedora. We should ship the best implementation, not the most "tried and true" one. Fedora is about advancing Free Software, not being conservative. If you see any concrete issues with libjpeg-turbo, do point them out. If not, we shouldn't refuse it just because it's not the same old stuff.
Something which is IMHO more important to consider is whether libjpeg-turbo is missing any improvements which are in the current IJG codebase, e.g. new APIs apps may start relying on at some point. (In that case, we need to either decide which to ship or ship both.)
Kevin Kofler
Hi,
A merge is the most appropriate here. After all libjpeg-turbo just offers a set of x86 specific SSE/MMX routines such as IDCT (maybe huffman, but I didn't check that) that would be easily plugged into ijg, but doesn't change the foundations (architecture and exposed public API) of libjpeg.
Also, one has to think about the applications that depend on it: what if they break and/or require changes.
-Ilyes Gouta
On Wed, May 26, 2010 at 1:45 AM, Kevin Kofler kevin.kofler@chello.at wrote:
Ilyes Gouta wrote:
There is one strong point that libjpeg-{6b, 8ab} inherited since it's been there for a lof time: a *defacto* standard for JPEG compression/decompression that has been heavily depolyed, used and tested code for various application/, thoughtout the time, for more than a decade! I think that's important and would enable it to keep its place in the destribtion.
libjpeg-6b is at production level code, and it actually offers a couple of ways to accelerate JPEG decoding by turning on the IDCT level decimation (basically for free resize) and enabling YUV raw decodes.
This kind of arguments doesn't really make sense for Fedora. We should ship the best implementation, not the most "tried and true" one. Fedora is about advancing Free Software, not being conservative. If you see any concrete issues with libjpeg-turbo, do point them out. If not, we shouldn't refuse it just because it's not the same old stuff.
Something which is IMHO more important to consider is whether libjpeg-turbo is missing any improvements which are in the current IJG codebase, e.g. new APIs apps may start relying on at some point. (In that case, we need to either decide which to ship or ship both.)
Kevin Kofler
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Ilyes Gouta wrote:
A merge is the most appropriate here. After all libjpeg-turbo just offers a set of x86 specific SSE/MMX routines such as IDCT (maybe huffman, but I didn't check that) that would be easily plugged into ijg, but doesn't change the foundations (architecture and exposed public API) of libjpeg.
I'm personally quite surprised to discover that libjpeg has still no multimedia acceleration today.
The number of impacted applications is huge: photo browsers (they make thumbnails), web browsers, ... Just loading the desktop background can imply the decompression of a big jpeg.
And optimized IDCT code is not exactly something rare to find around. :-)
On Tue, May 25, 2010 at 10:23:45AM -0400, Adam Goode wrote:
On 05/25/2010 10:09 AM, Richard W.M. Jones wrote:
Why couldn't we just replace libjpeg with the libjpeg-turbo upstream? (For the primary architectures anyway).
I think this is a great idea, libjpeg is the bottleneck for a lot of my code.
One issue: are there C fallbacks for all the arch-specific code? It would be great if secondary architectures could just use libjpeg-turbo as well.
I had a quick scan of the build system, and it seems to me that on non-x86 architectures it falls back to using C. So it could be used as a drop-in replacement for libjpeg. Note that I've not tried compiling it on a secondary arch.
Rich.
On Tue, May 25, 2010 at 03:09:27PM +0100, Richard W.M. Jones wrote:
On Tue, May 25, 2010 at 02:57:37PM +0100, Bastien Nocera wrote:
On Tue, 2010-05-25 at 15:27 +0200, Alexander Larsson wrote:
<snip> > > There's also this project, to add hardware acceleration (SSE and so > > on) to libjpeg: > > > > http://libjpeg-turbo.virtualgl.org/ > > > > If we're going to switch, maybe this is a good choice. > > I did some profiling of this for the spice project, and it performed > very well. I would very much like this to be in fedora, either as a > separate library or as a replacement for libjpeg. > > It is binary compatible with libjpeg, but contains some extra API not > supported by the normal libjpeg.
Which means you'll have to make a choice as to which one to support if you want to handle JPEG files, and that we'll have to fix upgrades and new installations to install the preferred one, as they would have the same soname.
Why couldn't we just replace libjpeg with the libjpeg-turbo upstream? (For the primary architectures anyway).
The issue would be that it's a fork. So libjpeg from the independent jpeg group and libjpeg-turbo can gain incompatible API in isolation from each other. (The situtation seems a bit complex, there's three projects that I can see working on libjpeg:
* libjpeg.sf.net -- working on API compatible updates to libjpeg-6b * independent jpeg group (one person?) -- working on jpeg-8b and beyond * libjpeg-turbo -- seems to be based on libjpeg-6b has speedups on modern x86 (w/SSE), licensed under the wxwindows license instead of BSD due to using code from that project. (according to the README in libjpeg-turbo, wxwindows license is a less restrictive form of the LGPL -- it allows static linking without the resulting work having to take on the LGPL license.)
tgl, is this your understanding of the separate projects as well?
-Toshio
Toshio Kuratomi a.badger@gmail.com writes:
The issue would be that it's a fork. So libjpeg from the independent jpeg group and libjpeg-turbo can gain incompatible API in isolation from each other. (The situtation seems a bit complex, there's three projects that I can see working on libjpeg:
- libjpeg.sf.net -- working on API compatible updates to libjpeg-6b
- independent jpeg group (one person?) -- working on jpeg-8b and beyond
- libjpeg-turbo -- seems to be based on libjpeg-6b has speedups on modern x86 (w/SSE), licensed under the wxwindows license instead of BSD due to using code from that project. (according to the README in libjpeg-turbo, wxwindows license is a less restrictive form of the LGPL -- it allows static linking without the resulting work having to take on the LGPL license.)
tgl, is this your understanding of the separate projects as well?
[ sorry for slow response ] libjpeg-turbo is news to me, but as far as the other two go:
* the sf.net project was started to produce ABI-compatible updates of libjpeg 6b, but I'm beginning to despair of ever seeing a release from them.
* libjpeg7/8/etc is pretty much one person, and I'm not terribly happy with the direction that that's going either. Guido doesn't seem to be very concerned with even file-level compatibility, let alone source-code compatibility (libjpeg7 is known to have broken multiple dependent packages), and he's also not worrying much about patent issues. The move to add arithmetic-coding support seems a bad idea on at least two of those grounds, and it doesn't even buy that much in file size.
I suppose this is all my fault for having let libjpeg languish for so many years, but that's water under the bridge now. If the libjpeg-turbo group is doing active development and is taking care not to break things unnecessarily, I'm happy to see them become the forefront of libjpeg development. Especially if it means I don't have to do the work ;-)
regards, tom lane ex-organizer, Independent JPEG Group
On 05/25/2010 09:27 AM, Alexander Larsson wrote:
There's also this project, to add hardware acceleration (SSE and so on) to libjpeg:
PLease also don't forget the applications which are provided by libjpeg such as jpegtran et al ..
Are they all included in the turbo version ?
On Tue, May 25, 2010 at 04:47:29PM -0400, Genes MailLists wrote:
On 05/25/2010 09:27 AM, Alexander Larsson wrote:
There's also this project, to add hardware acceleration (SSE and so on) to libjpeg:
PLease also don't forget the applications which are provided by libjpeg such as jpegtran et al ..
Are they all included in the turbo version ?
Yes.
Rich.
Hi all,
On 05/22/2010 05:55 PM, Xose Vazquez Perez wrote:
hi there,
Can it be updated to upstream version in rawhide ?
The libjpeg version(6b) in Fedora is quite old(27-Mar-1998). And newer versions were released on:
Version 7 27-Jun-2009 Version 8 10-Jan-2010 Version 8a 28-Feb-2010 Version 8b 16-May-2010 http://www.ijg.org/
May I point out that libjpeg version 7 and later add support for the patented (and optional) arithmetic coding part of the JPEG spec. So before we go any further in discussing whether or not to switch to a newer libjpeg we first need to investigate what the legal status of these newer versions is.
Regards,
Hans
-
Adam Goode -
Adam Tkac -
Alexander Larsson -
Bastien Nocera -
Bruno Wolff III -
Chen Lei -
Chris Jones -
drago01 -
Genes MailLists -
Hans de Goede -
Ilyes Gouta -
Kevin Kofler -
Orcan Ogetbil -
Richard W.M. Jones -
Roberto Ragusa -
Tom Lane -
Toshio Kuratomi -
Xose Vazquez Perez