tech wrote:

Option 6 is apparently out of the question, unless ImageMagick is installed on
the machine. The GD library which is used by PHP's image function doesn't
support GIF any more.

Option 5 looks easy. One might think that "$wgUseImageResize = false" should do
the trick...but it doesn't. First of all, only GIFs are the problem, and the
performance of PNG and JPG images would suffer that way as well...and second: it
doesn't work anyway (width & height are omitted from the image tag most of the
time). Option 5 is sort of stupid anyway, I think.

Option 2...now that's an easy one. Really. All I have to do is to patch one
function in includes/Image.php:

function thumbName( $width, $shared=false ) {
global $wgUseLatin1,$wgSharedLatin1;
$thumb = $width."px-".$this->name;
if( $this->extension == 'svg' ) {

1. Rasterize SVG vector images to PNG

		$thumb .= '.png';

}

1. The following 3 lines are new: #

if( $this->extension == 'gif' ) {

		$thumb .= '.png';

}
if( $shared && $wgUseLatin1 && !$wgSharedLatin1) {

		$thumb=utf8_encode($thumb);

}
return $thumb;
}

However, I am not sure if this works with sites which use ImageMagick, and I
cannot test this currently, unfortunately :-(

The patch of option 2 is currently running at http://www.c64-wiki.de (without
ImageMagick, I told ya!), and it seems to work.

tech wrote:

Disadvantage of my above patch for option 2: all thumbnails for GIFs get
regenerated with new file names. The old files will need removal as they are not
needed any more.

tech wrote:

Image types "WBMP for WML" and "XBM" also seem to suffer from this bug, so they
should be addressed as well.

It may make sense to transform all non-JPEG thumbnails to PNG, for convenience
and consistency between variants. This should be done for ImageMagick-generated
thumbs as well; when non-standard types are added, we'd still like thumbs to be
in a nice format.

tech wrote:

Proposed (UNTESTED) change to Image.php from current HEAD

Since the change in the thumbnail naming scheme is incompatible with the old
scheme (requiring all affected thumbnails to be regenerated), this fix has to
be activated by setting "$wgRectifyThumbnailExtensions = true;" somewhere in
LocalSettings.php (or whatever). My proposal is that it's set to "true" for new
installations and kept at "false" for existing installations.

attachment Image.php ignored as obsolete

Klaus, can you post a diff instead of a full file? This is easier to read and
keep track of. (cvs diff -u includes/Image.php)

I don't think this is particularly an incompatible change so the option is
probably unnecessary; the existing thumbnail files are still there, and if the
page gets rerendered the new files will be created automatically. It should be a
completely transparent process.

tech wrote:

I fetched the recent 1.5 version from CVS to check things out. However, the bug
seems to be already fixed there, using "option 6" (the image type is kept during
resize). Apparently, recent GD library versions do support writing of GIFs
(although this can be disabled, if someone chooses to).

"If it ain't broken, don't fix fit."

The change in behavior seems to appear with Image.php V1.106 (included in
REL1.5beta4), in action against Bug 2780, changed by Brion Vibber (as far as I
tracked things down in CVS).

Proposed action: do nothing for the 1.5 branch, ignore bug in the 1.4.x branch
(it's pretts obscure anyway, and we all expect 1.4 to be deprectated Real Soon
Now(tm), right?).

I have a tested fix for 1.4.7, though, so if anyone thinks it would be worth the
effort, tell me! Otherwise, let's regard this bug as "closed, works in 1.5".

I think we have to consider several things:

a) keeping the file type makes only sense for file types that are supported by
the browser. XBM, WBMP, SVG etc should always be returned to the browser as PNG.
GIF, JPEG and PNG are the only formats we can expect browsers to support.

b) when scaling a (large) GIF, the result may look ugly when we keep GIF as the
file format. The reson for this is that GIF supports only 256 colors, which does
not allow for full interpolation during resize. The resulting PNG would look
much nicer.

c) I see no reason for sicking to GIFs, but the PNG could be set to indexed 256
color mode. This would result in smaller files, but it would also not solve the
problem mentioned in b).

For transparent GIFs, conversion to PNG may be a problem for MS-IE users,
because its PNG support is incomplete/broken. But we have this problem with all
transparent PNGs, of which there are many.

But anyway... isn't this already done for animated GIFs? The seem to be scaled
as GIFs, even though the results are often buggy.

And whil i'm at it: a "convert on upload" feature would be extremely helpful,
especially for MP3->OGG, etc. But this would put considerable load on the
servers, I fear.

tech wrote:

(In reply to comment #8)

I think we have to consider several things:a) keeping the file type makes only

sense for file types that are supported bythe browser. XBM, WBMP, SVG etc should
always be returned to the browser as PNG.

As far as I have seen in the current Image.php, only SVG gets rendered (as PNG),
while XBM and WBMP retain their filetype when getting thumbnailed. Well, that's
what the source code says, I haven't tried that on the test machine.

GIF, JPEG and PNG are the only formats we can expect browsers to support.

So we may have found another bug?

And whil i'm at it: a "convert on upload" feature would be extremely helpful,

especially for MP3->OGG, etc.

Anything with "mp3 technology" isn't free, we'd need a license from Thompson
Multimedia. These licenses aren't free, so for a decoder which was developed by
third party: US$ 0.75 per unit or US$ 50 000.00 one-time paid-up, Minimum
Royalties US$ 15 000.00 per calendar year. This license does not cover the right
to distribute, broadcast and/or stream mp3 / mp3PRO encoded data. Source:
http://www.mp3licensing.com/royalty/software.html

Royalities for serving mp3s are only applicable for commercial (revenue-
generating) use, so the average Wiki won't be required to pay the $2000/year for
the distribution license.

However, with all these patent/license issues, mp3 seems like a dead end to me
anyway (when used in a typical Wiki). Sigh.

FLAC would be cool (FLAC = Free Lossless Audio Codec), but about noone knows it.
Eats up more memory and bandwidth than OGG, of course. Well, I guess that's all
stuff for the not-so-near future. We should we aware of the possible future
options, of course, in order to avoid stupid design decisions which might turn
out to be obstacles for future requirements. But right now we should concentrate
on getting a rock solid image/thumbnail support in MediaWiki 1.5 :-)

tech wrote:

Okay, I will look for issues conerning thumbnailing of palletized graphic
formats. Some thumbnails do indeed look awful when downsampled at 256
colors...some look even worse. This is contrary to the intention of using such
losslessly compressing image file formats as GIF, where clarity should be fully
ratained (otherwiese, everything could get transformed to JPEG when thumbnailed).

tech wrote:

For the 1.5 branch! Generates PNG thumbnails GIF/XBM/WBMP, uses truecolor where reasonable to improve quality of downsampled images, adjusts extension to '.png' where required

After considering thge input from Brion and Daniel, I now propose a change in
the thumbnail generation scheme. For GIFs, XBM and XBMP images, thumbnails are
now generated in PNG format (extension of the filename gets adjusted
accordingly). For GIFs and PNGs, thumbnails get "promoted" to truecolor, as
downsampled 256 color images typically contain more color than the source
image.

The patch is tested and it works for me (with "GD library 2.0.28 compatible",
ImageMagick not tested).

The patch is, as already mentioned, for the MediaWiki 1.5 branch.

Attached:

zigger wrote:

(Please add wikibugs-l@wikipedia.org to the CC list when assigning a bug.)

plugwash wrote:

the problem with upconverting to truecolor when scaling is that in many cases
the extra colors add little visiblly to the image and yet bloat the filesize
considerablly.

it always seems a bit of a kick in the teeth to choose a sensible color depth
for your upload and then have the scaling system spit out a bloated truecolor
image anyway.

tech wrote:

The problem with the currently used approaches is that the thumbnails may end up
with *much* less content than the original picture. In extreme cases, the
thumbnail may even come out blank (unicolor). Resizing with interpolation is an
option which usually results in the use of more colors, but often gives a much
better preview of the original content.

I agree that nothing beats manual control when it comes to quality vs. size.
However, most of the time thumbnails are generated automatically (for example,
in automatically or semi-automatically generated image galleries or image
pages), so the primary goal should be to get reasonable thumbnails without the
need for user intervenation.

Well, at least the patch should get smarter, if my proposed approach is taken at
all.

brianna.laugher wrote:

Is this problem why this image doesn't display?
http://commons.wikimedia.org/wiki/Image:World_War_2.gif

No, it just uses too much memory.

The bug is prior to the rewrite to the image handling system.
Currently, gif images are thumbnailedto gif images, e.g. http://upload.wikimedia.org/wikipedia/commons/thumb/a/a8/Glagolica.gif/200px-Glagolica.gif
When changing formats, a double extension is used, e.g. http://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/Pachycondyla.harpax.larvae.-.wheeler.svg/585px-Pachycondyla.harpax.larvae.-.wheeler.svg.png