On Fri, Jul 31, 2009 at 8:44 AM, Frank Peters<frank.pet...@comcast.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 <mrpo...@gentoo.org>
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;
