Re: [gentoo-amd64] New Jpeg-7 -- was Re: kdelibs insanity

[Paul Hartman]

On Fri, Jul 31, 2009 at 8:44 AM, Frank Peters<frank.peters@×××××××.net> wrote:
> Since I process a lot of images, libjpeg is very important to me.  The new
> jpeg-7 now includes arithmetic encoding which can produce smaller compressed
> file sizes and there are also some changes to the scaling and quality features.
> Unlike most Open Source packages, which are updated quite frequently (too
> frequently?), jpeg-7 is the first new release since 1998.
>
> Rather than wait for Gentoo to create the ebuilds for the new jpeg-7, I decided
> to compile it myself and then list it in packages.provided.  In addition,
> the old jpeg-6 shared objects were kept, but all the include files and
> static libraries for linking would refer to the new jpeg-7.  In this way,
> any update of a package that depends on libjpeg would be linked with the
> new libraries, but any existing package that still needs jpeg-6 could be
> left untouched.  I don't like to have to re-compile everything at once.  When
> the time comes to update a package the new libraries will be available but until
> then the old libraries will suffice.  (Gentoo is flexible enough to nicely
> accomodate this.)
>
> However, after emerging a new GTK+, which automatically then became linked
> to the new jpeg-7 libraries, I noticed a severe problem.  Jpeg images viewed
> using programs that depend on GTK+ -- and there are a lot of them -- were
> strangely blurred and out of focus.  Doing some searching, I found this
> thread that explains the problem:
>
> http://bbs.archlinux.org/viewtopic.php?id=75529
>
> The issue is with the new scaling methods in jpeg-7.  Programs such as firefox
> and many others process images through GTK+ facilities, and GTK+ needs to be
> patched before it can utilize the new jpeg-7.  AFAIK, the GTK+ people do not
> even yet know about this issue.  Also, unless I am mistaken, any patch that
> accommodates jpeg-7 will no longer function with jpeg-6.
>
> So there ends my nice, neat plan to have both jpeg-7 and jpeg-6 together
> serving my system.  The situation also illustrates how unanticipated problems
> can easily be injected into this loose but wonderful conglomeration known
> as Open Source software.

FWIW the newly-released gtk+ 2.16.6 of a coupel days ago still has the
problem with jpeg-7, but there was a patch in the gtk bugzilla that
fixed the problem for me:

Author: Romain Perier <mrpouet@g.o>
Subject: Ensure gdk-pixbuf is backward compatible with jpeg6, even if
it's works with jpeg7
Date: 2009-09-01 10:27 UTC

---
 gdk-pixbuf/io-jpeg.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/gdk-pixbuf/io-jpeg.c b/gdk-pixbuf/io-jpeg.c
index cf8c9ed..9af55ba 100644
--- a/gdk-pixbuf/io-jpeg.c
+++ b/gdk-pixbuf/io-jpeg.c
@@ -921,8 +921,11 @@ gdk_pixbuf__jpeg_image_load_increment (gpointer data,
                                        return FALSE;
                                }
                        }
-
+#if JPEG_LIB_VERSION >= 70
+                       for (cinfo->scale_denom = 2;
cinfo->scale_denom <= 16; cinfo->scale_denom *= 2) {
+#else
                        for (cinfo->scale_denom = 2;
cinfo->scale_denom <= 8; cinfo->scale_denom *= 2) {
+#endif
                                jpeg_calc_output_dimensions (cinfo);
                                if (cinfo->output_width < width ||
cinfo->output_height < height) {
                                        cinfo->scale_denom /= 2;