[Fwd: gtk+ wrong code in JPEG loading module]

[Federico Mena Quintero]

This landed in my inbox - has anyone played with new versions of libjpeg
to see if this works?

  Federico

Hello all

This is a report to the authors mentioned in the gdk-pixbuf/io-jpeg.c
module of the current gtk+ 2.18.0 package,
from Guido Vollbeding, organizer Independent JPEG Group.

I'm sorry if this way is inappropriate, but I'm not involved in any
forums or mailing lists.  Please forward to whom it may concern if
possible.

I have noticed various complaints about weird display of JPEG images
with applications depending on gtk+ after upgrading to the new IJG
JPEG 7 version, and I have seen faulty patches to the above mentioned
module to work around the problem.

I have now looked through the code and found the flawed code sequence
in function "gdk_pixbuf__jpeg_image_load_increment".
I strongly advise to correct the code by simply inserting the statement

        cinfo->scale_num = 1;

in front of the following code sequence in mentioned function:

        for (cinfo->scale_denom = 2; cinfo->scale_denom <= 8; cinfo->scale_denom *= 2) {
                jpeg_calc_output_dimensions (cinfo);
                if (cinfo->output_width < width || cinfo->output_height < height) {
                        cinfo->scale_denom /= 2;
                        break;
                }
        }
        jpeg_calc_output_dimensions (cinfo);

This addition will work with older and newer versions of the library.

The implicit assumption of the given code that cinfo->scale_num is
initialized with 1 by the JPEG library is no longer true for versions
7 and later!  Version 7 initializes this field (and the other) with 8,
and version 8 and later will initialize the fields with the (variable
from 1 to 16) block size of the given JPEG file.  (Note that the
default resulting scaling factor remains 1 in any case.)

The usual recommendation for versions up to 6 has always been that
"scale_num" and "scale_denom" be set *simultaneously* by the calling
application.  Applications following this recommendation will not
suffer an incompatibility with newer JPEG library versions.
Newer applications (written for JPEG library versions 7 and later)
MAY choose to set only one of both fields, because the initialization
defaults are now depending on the input file and are specified as
mentioned above.

The given correction code simply retains the same behaviour with
new JPEG library versions as with old JPEG library versions.
The code may later be revised to utilize the more flexible scaling
choices of v7 and later, but there is no need to do this now.

I have not verified other code in the module.
But this part is clearly wrong for use with newer JPEG library
versions and requires correction, as it may affect a lot of gtk+
dependent applications.

Regards
Guido Vollbeding
Organizer Independent JPEG Group

_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Matthias Clasen-2]

On Tue, Oct 20, 2009 at 6:08 PM, Federico Mena Quintero
<federico@...> wrote:
> This landed in my inbox - has anyone played with new versions of libjpeg
> to see if this works?
>

I believe gentoo has been trying to get gtk to work with libjpeg7.
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Frederic Crozat]

Le mardi 20 octobre 2009 à 19:48 -0400, Matthias Clasen a écrit :
> On Tue, Oct 20, 2009 at 6:08 PM, Federico Mena Quintero
> <federico@...> wrote:
> > This landed in my inbox - has anyone played with new versions of libjpeg
> > to see if this works?
> >
>
> I believe gentoo has been trying to get gtk to work with libjpeg7.

We switched too, and are using patch from bug
https://bugzilla.gnome.org/show_bug.cgi?id=588740 

Once Mandriva cooker is reopened, I'll try the patch suggested by
Guido.

--
Frederic Crozat <fcrozat@...>
Mandriva

_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list