libjpeg for F14

[Xose Vazquez Perez]

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-

-- 
If less is more than more, most is more than less.

[Bruno Wolff III]

On Sat, May 22, 2010 at 17:55:39 +0200,
  Xose Vazquez Perez <xose.vazquez(a)gmail.com&gt; 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.)

[Xose Vazquez Perez]

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(a)gmail.com&gt; 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

-- 
If less is more than more, most is more than less.

[Genes MailLists]

 Sorry  - there is reticence to update from something that is 12 years
old ... did I understand that correctly .. if so I am stunned.

gene

[Chen Lei]

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

[Tom Lane]

Xose Vazquez Perez <xose.vazquez(a)gmail.com&gt; 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

[Toshio Kuratomi]

On Sat, May 22, 2010 at 10:23:05PM -0400, Tom Lane wrote:
>  Xose Vazquez Perez <xose.vazquez(a)gmail.com&gt; 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

[Toshio Kuratomi]

On Sat, May 22, 2010 at 10:23:05PM -0400, Tom Lane wrote:
>  Xose Vazquez Perez <xose.vazquez(a)gmail.com&gt; 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

[Chen Lei]

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

[Kevin Kofler]

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

[Xose Vazquez Perez]

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!




-- 
If less is more than more, most is more than less.

[Roberto Ragusa]

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

-- 
   Roberto Ragusa    mail at robertoragusa.it

[Kevin Kofler]

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

[Richard W.M. Jones]

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.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top

[drago01]

On Mon, May 24, 2010 at 2:24 PM, Richard W.M. Jones <rjones(a)redhat.com&gt; 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.

[Chen Lei]

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

[Chris Jones]

On Tue, May 25, 2010 at 12:31 PM, Chen Lei <supercyper1(a)gmail.com&gt; 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(a)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?


-- 
Chris Jones
Photographic Imaging Professional and Graphic Designer
ABN: 98 317 740 240

Photo Resolutions - Photo Printing, Editing and Restorations
Web: http://photoresolutions.freehostia.com
Email: <chrisjones(a)comcen.com.au&gt;

[Chen Lei]

2010/5/25 Chris Jones <chrisjones(a)comcen.com.au&gt;

>  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

[Chris Jones]

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.



-- 
Chris Jones
Photographic Imaging Professional and Graphic Designer
ABN: 98 317 740 240

Photo Resolutions - Photo Printing, Editing and Restorations
Web: http://photoresolutions.freehostia.com
Email: <chrisjones(a)comcen.com.au&gt;


pub 2048R/8C088061 5/25/2010 Chris Jones <chrisjones(a)comcen.com.au&gt;
    Primary key fingerprint:  FAC6 F8E8 868C 8DAB 9DEA 7602 8252 65AD 8C08
8061

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.10 (MingW32) - WinPT 1.4.3
Charset: UTF-8
Comment: Gnu Privacy Tools
Comment: Download at http://www.gnupt.de

mQENBEv7YxMBCADIYm1hzSAgJkzTfs0jvPNMdM23M5qCwgylKE6uCW7iTMke7vhM
lO1+2dMFBxplGHq33QRC0qyercYGtACUSb8BYOtHXZaYfM8E20HJHvXaWWFQBk3S
HGbUnzNO3NzU4pDGJoi5eBH4MkD5FEpkMe1s0Dw9UoWdkQRvMUYhBzGpXxUFz/W8
0uPkfZdeziYlZZ8lUxcw95GfqBbRKLoKYrP/jCBH9BeFNgixpeIiHYt8rHoEg9T1
N9tajw8aRJGJdIgZ6DNirDkFOpYWtSjj0dlDnMy9uPOcrdHlPDjZ0Sw4FrGyb9TR
KoeIpxk3vOlS6nP4HsWjagP0oZzqvdDf9UC1ABEBAAG0JkNocmlzIEpvbmVzIDxj
aHJpc2pvbmVzQGNvbWNlbi5jb20uYXU+iQE4BBMBAgAiBQJL+2MTAhsDBgsJCAcD
AgYVCAIJCgsEFgIDAQIeAQIXgAAKCRCCUmWtjAiAYcmtB/4wpRgf6SZ8H0uFEpIs
x6kxLEsTKzNcW4JNJVPLrSFzTQkslhn6gu+3NVS9qG0whpBVh/eThPVK/zBRzNvw
f5EfI09EKEeGJ9nnTWnVhDDJYnHFXC+w3dgDKv5C5VN1ARGiw8Eot7mgfSv5gcso
VwqA4/Jx3q34sLn7z5AMHa9TamlpffzQma+HqCjn37aaZcx1AGsLlCDVENJcyVKi
+lk8qWvB/1DhEVpSFFlrEouMxvUUWZp9kyT4sXcIuxMUpvPYzM5l7iYxqk6KhC0V
hhnfzDr/exOfLgVhkIzIY8ZR1zeErkQq4seLFJC/ZdpoD1L1acMJoMzwu+1HjmUv
VwtfuQENBEv7YxMBCADajxmRiD2en8fSD5dqa4MwjtNmSKOfzNY2a+a9+Y5VPPYM
irT5c78p6CPLQvgrfgTuPzENk+dsxiIQjyJCOATrrueIFExmBNon9sEEyVzHk9GU
DxdW6eAak5Nlr8qQwc7EpS+KiEwap/TJu/PgIYDg2rGpDGVmZnK5bAG4An2AJJ+n
8i9J/773pQs3iK3HZyjPqAb9Oy03gILRsUydTaj0wXc/5ELgV7UhBay9pc5tOoVV
39Ko9km3VsxeTfcMHcOc46n70tFzyOI/ntsG8GuIAuKAFcn1x8Kdst7no3VrozDT
uPMR+IxJeZ9JKGCz+U0zphecyCi59Ve/Ur77LDKrABEBAAGJAR8EGAECAAkFAkv7
YxMCGwwACgkQglJlrYwIgGF5Tgf/S/5pob7MROT8Q6wVQ3i939eiFUeoHYwO/5Et
DoJIKfXKJW0UHf/HMQt7OhXZSWJWhPX+S2dEPDuIr0QvmGUtRpiuziP8VFdxb6wD
iPm+InsSSSkSZwM+HzK504lXRr4oJgyuw5X/v3+LtfSL9aKHspP81/axP7q0fGiH
WTTuJmzylfBMrBeZD44E8+LFHcDJ7fBxlxXMKH6gdx3rF6AH2ejz1miW6ETbZiba
O5IDcCSuTiMmuqsiNblDp7p6F69tAykbkk5XWwJ/JLxpjOnqgMUBNNgPM2b5JLg2
EjsErAnezLn3XHqLZfCCkVhlKnQeMRmWaiQEJC7lso4rd3VA8w==
=ggBQ
-----END PGP PUBLIC KEY BLOCK-----

[Alexander Larsson]

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.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
       alexl(a)redhat.com            alexander.larsson(a)gmail.com 
He's a war-weary voodoo gangster moving from town to town, helping folk in 
trouble. She's a transdimensional mutant college professor from the wrong side 
of the tracks. They fight crime!

[Bastien Nocera]

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.

[Richard W.M. Jones]

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.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/

[Adam Goode]

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

[Ilyes Gouta]

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(a)spicenitz.org&gt; 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(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>

[Richard W.M. Jones]

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.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top

[Toshio Kuratomi]

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

[Adam Tkac]

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.

[Adam Tkac]

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

-- 
Adam Tkac, Red Hat, Inc.

[Orcan Ogetbil]

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

[Adam Tkac]

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.

[Ilyes Gouta]

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(a)redhat.com&gt; 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(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>

[Adam Tkac]

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.

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

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

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

-- 
Adam Tkac, Red Hat, Inc.

[Toshio Kuratomi]

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

[Ilyes Gouta]

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(a)redhat.com&gt; 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(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>

[Adam Tkac]

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/[e-mail]/msg00225...
http://www.mail-archive.com/[e-mail]/msg00403...

As said there, libjpeg-turbo has nearly same performance as Intel's IPP.

Regards, Adam

-- 
Adam Tkac, Red Hat, Inc.

[Kevin Kofler]

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

[Ilyes Gouta]

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(a)chello.at&gt; 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(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>

[Roberto Ragusa]

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

-- 
   Roberto Ragusa    mail at robertoragusa.it

[Richard W.M. Jones]

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.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v

[Toshio Kuratomi]

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

[Tom Lane]

Toshio Kuratomi <a.badger(a)gmail.com&gt; 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

[Genes MailLists]

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:
> >
> > http://libjpeg-turbo.virtualgl.org/ 

   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 ?

[Richard W.M. Jones]

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:
>  >>
>  >> http://libjpeg-turbo.virtualgl.org/
>  
>  
>     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.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top

[Genes MailLists]

On 05/25/2010 05:03 PM, Richard W.M. Jones wrote:

> >
> >    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.
>   
   Thats great!

[Hans de Goede]

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