Last modified: 2010-05-15 15:33:05 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 3083 - GIFs, when resized (as thumbnail), turn into PNGs, but without changing MIME type and extension accordingly
GIFs, when resized (as thumbnail), turn into PNGs, but without changing MIME ...
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
File management (Other open bugs)
1.4.x
All All
: Lowest minor (vote)
: ---
Assigned To: Klaus Stock
: patch, patch-need-review
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-08-09 09:57 UTC by Klaus Stock
Modified: 2010-05-15 15:33 UTC (History)
2 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Proposed (UNTESTED) change to Image.php from current HEAD (52.28 KB, text/plain)
2005-08-11 09:20 UTC, Klaus Stock
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 (4.46 KB, patch)
2005-08-12 09:19 UTC, Klaus Stock
Details

Description Klaus Stock 2005-08-09 09:57:17 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!
Comment 1 Klaus Stock 2005-08-10 09:08:43 UTC
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.
Comment 2 Klaus Stock 2005-08-10 09:21:18 UTC
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.
Comment 3 Klaus Stock 2005-08-11 07:26:37 UTC
Image types "WBMP for WML" and "XBM" also seem to suffer from this bug, so they 
should be addressed as well.
Comment 4 Brion Vibber 2005-08-11 08:48:07 UTC
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.
Comment 5 Klaus Stock 2005-08-11 09:20:53 UTC
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.
Comment 6 Brion Vibber 2005-08-11 09:54:12 UTC
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.
Comment 7 Klaus Stock 2005-08-11 18:57:12 UTC
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".
Comment 8 Daniel Kinzler 2005-08-11 19:09:51 UTC
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.
Comment 9 Klaus Stock 2005-08-11 19:59:57 UTC
(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 :-)
Comment 10 Klaus Stock 2005-08-12 07:17:03 UTC
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).
Comment 11 Klaus Stock 2005-08-12 09:19:26 UTC
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.
Comment 12 Zigger 2005-08-12 15:56:18 UTC
(Please add wikibugs-l@wikipedia.org to the CC list when assigning a bug.)
Comment 13 peter green 2005-08-15 20:56:42 UTC
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.

Comment 14 Klaus Stock 2005-08-15 21:43:36 UTC
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.
Comment 15 brianna.laugher 2006-05-29 11:32:11 UTC
Is this problem why this image doesn't display?
http://commons.wikimedia.org/wiki/Image:World_War_2.gif
Comment 16 Brion Vibber 2006-05-29 21:08:28 UTC
No, it just uses too much memory.
Comment 17 Platonides 2008-07-08 18:24:48 UTC
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

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links