Last modified: 2010-05-15 15:33:05 UTC
Situation: a GIF image is uploaded to a MediaWiki wiki, image name is (for example) "spaceship.gif". No problem so far. The wiki doesn't use ImageMagick, btw. The image is then placed in an articel as a thumbnail, like this: [[Image:spaceship.gif|thumb|left|300px|Picture of a spaceship]]. What happens is that the image gets resized to a width of 300 pixel. The resulting thumbnail image then carries the filename "300px-spaceship.gif". However, the image "300px-spaceship.gif" is in PNG format, not a GIF! Yet, it still carries the ".gif" extension, and is served by the web server with "Content-Type: image/gif". No problem...most of the time. Most browser manage to figure out that this "GIF" is, in reality, a PNG (I guess by looking inside), and manage to display it, most of the time. The problem may become apparent when saving the article as an HTML page to the local hard disk for offline browsing. Suddenly, it seems that the PNG-which-is- disguised-as-a-GIF cannot be displayed as successful any more. Verified with MSIE6 as browser, when the page was saved with MSIE6 (problem appears). Verified with MSIE6 as browser, when the page was saved with httrack-3.40-ALPHA- 5 (problem appears). Firefox 1.0 works, with page saved with MSIE6 and page saved with httrack-3.40- ALPHA-5. Okay, now it's easy to blame everything on Microsoft ;-) However, the current behavior still relies on the generous tolerance of the viewer software and is not really according to the specs. As far as I can tell. Possible options to fix it: 1. When a GIF gets transformed, rename the extension to ".png". May cause problems if there are already two images whose names only differ in the extension. 2. When a GIF gets transformed, attach an additional ".png". Will result in something like "spaceship.gif.png". Looks sorta stupid, but works more reliable that option 1, I guess. 3. When a GIF gets uploaded, immediately transform it into a PNG. Will break animated GIFs, and may also cause problems with the GIFs which already present. No good. 4. Disallow GIFs alltogether. Will be regarded as a real stupid idea by many. Same problems as option 3, too. 5. Never transform GIFs. Resizing will have to occur on the client side, traffic may increase. If this option is implemented, it should be possible to turn it off in LocalSettings.php. 6. Transform GIFs to GIFs, not PNGs. Only problem is the incompatability with the "Burn All GIFs" movement (which is kind of obsolete anyway now, as the "GIF patent" wasn't extented). Might be of advantage, if a "Burn All PNGs" movement appears (in case a Submaraine Patent surfaces which is relevant to PNGs (not really a joke - one reason why JPEG2000 isn't that popular is said to be the possibility of potetntial Submarine Patents there, too...). Holy shit! This was meant to be a bug report and not a political rant!
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' ) { # Rasterize SVG vector images to PNG $thumb .= '.png'; } ##### 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.
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.
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.
Created attachment 773 [details] 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.
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.
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.
(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 :-)
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).
Created attachment 775 [details] 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.
(Please add wikibugs-l@wikipedia.org to the CC list when assigning a bug.)
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.
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.
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
