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

[Federico Mena Quintero <federico ximian com>]

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

  Federico

--- Begin Message ---

• From: Guido Vollbeding <guido jpegclub org>
• To: Michael Zucchi <zucchi zedzone mmc com au>, Federico Mena-Quintero <federico gimp org>, Michael Fulbright <drmike redhat com>
• Cc: Tom Lane <tgl sss pgh pa us>, Bill Allombert <Bill Allombert math u-bordeaux1 fr>, Bob Friesenhahn <bfriesen simple dallas tx us>
• Subject: gtk+ wrong code in JPEG loading module
• Date: Sat, 26 Sep 2009 22:01:40 +0200

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

--- End Message ---