Last modified: 2011-03-13 18:05:39 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 1218 - Scaled image is larger than original for palletted PNG (in terms of size)
Scaled image is larger than original for palletted PNG (in terms of size)
Product: MediaWiki
Classification: Unclassified
File management (Other open bugs)
All All
: Lowest minor with 3 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: 5211 14974 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2004-12-28 01:17 UTC by peter green
Modified: 2011-03-13 18:05 UTC (History)
4 users (show)

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


Description peter green 2004-12-28 01:17:59 UTC
the point of doing scaling on the server side is to reduce load times. However
when the image is only being scaled by a small ammount and the original is line
art the image sometimes gets substantially bigger. In the specific case shown in
the url the reduced image inlined in the page is nearly 4 times the size of the

it would seem sensible to check if the version scaled on the server side really
was smaller than the original before deciding which version to send.
Comment 1 grendelkhan 2004-12-28 03:31:19 UTC
There's also the issue of quality, however. Web browsers use some truly 
grotesque scaling algorithms in the interest of speed; it is likely that 
doing client-size image scaling will result in very, very ugly image 
display. See
images for an example. The unscaled version is being sent, but it's being 
scaled on the web browser end. On IE6 SP1, at least, it looks ucky.

This may or may not outweigh the size costs of computing and sending a 
nicely antialiased version, but it's something to consider.
Comment 2 JeLuF 2004-12-28 21:52:10 UTC
Fixed in CVS HEAD.
If the thumbnail image in an image page is bigger (in Bytes) than the original
image, the original one is shown. It will not be scaled down using <img
width=... height=...> but keep its original size.
Comment 3 JeLuF 2004-12-28 23:17:05 UTC
fixed in 1.4, deployed
Comment 4 peter green 2005-02-24 03:03:10 UTC
there has been quite a discussion regarding this issue over at

the REAL problem seems to be that imagemagick converts EVERYTHING to truecolor
during any operation. This seems to be the main cause of bloat during the
conversion process causing the scaled images to be far bigger than they should
be and more likely to exceed the size of the original image in the first place.
Comment 5 Andrew Archibald 2005-02-27 09:19:18 UTC
I suggest two things:

* Always resize images (This would resolve bug 1352 as well).
* Use ImageMagick's "identify" to count the colors in an image (possibly only if
the input image was indexed or grayscale); if it's 256 or less, convert the PNG
to an indexed PNG (losslessly). 

The first cures the user hassle; the second will probably avoid most of the
cases where the image actually gets bigger.
Comment 6 peter green 2005-02-27 16:39:04 UTC
* Use ImageMagick's "identify" to count the colors in an image (possibly only if
the input image was indexed or grayscale); if it's 256 or less, convert the PNG
to an indexed PNG (losslessly)

i think this is unlikely to work.

scaling by non integer scale factors will produce an insane flood of colors
which is pretty much only limited by the bitdepth you allow the output to be.

Comment 7 Andrew Archibald 2005-03-01 08:04:17 UTC
I should first point out that the limitations discussed here apply also to the
usual thumbnailing process - a greyscale image yields a "truecolor" thumbnail.

Scaling to any ratio does indeed produce a flood of colors.  This cannot and
should not be changed (the colors are there to improve image quality).  So most
scaled pictures will stay truecolor.  What are the problem cases then?

* Start with a black-and-white (bitonal) image.  Scale it; currently it turns
into truecolor.  This method would yield a (paletted) grayscale image.  (I would
guess that this is by far the most common case of image growth.)

* Start with a bitonal image in two other colors. Currently turns into
truecolor; this suggestion would make it paletted.

* Start with an image with a handful of colors (a color line drawing, say, that
has been inexplicably rendered with no antialiasing).   Scaling needs a flood of
colors to render an antialiased version (any time two colors border on one
another, many colors between the two are needed to antialias it).  This would
stay truecolor.

* Start with a grayscale image.  Scaling currently converts this into a
truecolor image; this proposal would convert it into a (paletted) grayscale image.

What other alternatives do we have? 

* Scale only to integer ratios (or fractions with small numerator and
denominator). This somewhat reduces the number of distinct colors that are
introduced (if the simplest anti-aliasing scheme is used).  For reasonable-sized
images this probably yields scaled bitonal images with not more than nine
colors; it also helps with images with not too many colors, especially if they
don't meet very much.  This would most naturally be combined with the previous
suggestion, so that one need not assume ahead of time anything about the
resulting colors.  It might also improve image clarity (at the cost of size). 
It is of no use for thumbnails in pages.

* Attempt to lossily reduce the number of colors in some images.  Which images?
Bitonal only? Some bitonal images (scans, for example) use stippling to produce
shades of gray, which has the correct effect when scaled using the current
algorithm.  How many colors should be used?  The answer will surely depend on
the image and the scaling ratio. How much quality are we willing to lose, and
how can it be measured?  Histograms of the image pixels, perhaps, along with a
human visual model.  How much CPU time will it use on the servers? How much
developer time will it take?  How many images need this anyway?
Comment 8 Brion Vibber 2005-06-20 02:25:32 UTC
Reclosing this, since problem as described was fixed as requested.

Open a separate enhancement request for more intelligent thumbnail formatting if desired.
Comment 9 JeLuF 2005-06-25 21:50:42 UTC
In 1.5alpha2, this behaviour can be observed again. => REOPEN. is 75 KByte, its
image page thumbnail in 1.5alpha2 is 305 KByte.
Comment 10 peter green 2005-06-25 22:58:21 UTC
indeed because the cure that was made (which was not the one i as the reporter
proposed) was worse than the original issue and so was backed out for 1.5.

the original souloution i proposed was scaling down using the browser for such
cases but that has problems too (mostly because browsers do a really shitty job
of scaling).

the real issue is that scaling in mediawiki sucks for pretty much everything
except photographic jpegs. see for the real improvements
that are needed.
Comment 11 Derek 2005-12-28 21:03:23 UTC
I found this bug while preparing to file one, so just adding a comment.

1) The scaling algorithm wasn't smart enough to note it was "scaling" it by only
a few pixels
2) In scaling the PNG it presumably caused some imperceptible slurring - as a
result the original size of 12kb
  was inflated almost 8 fold (!).  Scaling would probably be better off just
using JPEG.
3) The 250 pixel version on the page should probably have been a jpeg - possibly
with Mediawiki checking to see if the scaled image was larger than the original,
and if so, discarding the scaled version and just using the original with image
width/height set in CSS or IMG attributes.  (comment #2 - sorry for repeating,
just was applicable in this case as well)
4) Additionally, if Mediawiki was clever, it'd note when simpled line drawings
or user interfaces or even text of math equations was being uploaded as RGBA
when the number of colours in the image was less than 255.  In such a case,
Mediawiki would be better off resaving as an 8bit PNG with savings of 50% or
more in image size.  Also possibly reevaluating the need for a scaled version as
mentioned in comment #2.  In this case, doing that to the original image reduced
the size to 6852 bytes with no data loss - making the "scaled" size of 96437 a
ridiculous 14 fold increase.

Comment 12 Derek 2005-12-28 21:23:55 UTC
And apologies, should have read all the comments more carefully, the other
issues with this image were also being discussed in comment #5, comment #6 and

Well. Adding my vote for smarter scaling and not saving as PNG when scaling...
Comment 13 Brion Vibber 2006-03-09 21:18:37 UTC
*** Bug 5211 has been marked as a duplicate of this bug. ***
Comment 14 MER-C 2008-03-09 02:38:36 UTC
Still an issue in 1.13alpha, this time it's animated gifs. is about 10% larger than [[Image:Cicada molting animated-2.gif]].
Comment 15 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-07-29 21:03:21 UTC

*** This bug has been marked as a duplicate of bug 234 ***
Comment 16 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-07-29 21:09:28 UTC
Actually, reopening, since bug 234 deals with two issues, and it seems to primarily deal with the transparency issue.  Let's use this one for the size-increase issue.
Comment 17 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-07-29 21:09:44 UTC
*** Bug 14974 has been marked as a duplicate of this bug. ***
Comment 18 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-07-29 21:14:43 UTC
The comment from the duplicate may be useful.

(from bug 14974 comment #0)
> The thumbnails are created by GD using the function imagecreatetruecolor(...)
> to create a blank new image in which the thumbnail is created. So the
> destination image is a true color image which is therefor larger than the
> source. When imagecreate(...) is used for the non true color images these
> thumbnails are much smaller.
> The following code in media/Bitmap.php at about line 170 does this.
>                         if (imageistruecolor( $src_image ) ) {
>                                 $dst_image = imagecreatetruecolor(
> $physicalWidth, $physicalHeight );
>                         }
>                         else {
>                                 $dst_image = imagecreate( $physicalWidth,
> $physicalHeight );
>                         }
> ImageMagick using the -depth 8 option also creates a full color image from the
> source. 

As has been pointed out above, more colors may be needed in the scaled version due to interpolation, so there's not necessarily an easy fix.
Comment 19 Rene Bakker 2008-07-29 21:28:07 UTC
(In reply to comment #18)
> > ImageMagick using the -depth 8 option also creates a full color image from the
> > source. 

The -depth ImageMagick command line option may get an enhancement which could solve the problem, if I understand the following link correctly:
I have not seen it yet in the latest version though.
Comment 20 peter green 2008-07-29 21:56:41 UTC
>As has been pointed out above, more colors may be needed in the scaled version
>due to interpolation, so there's not necessarily an easy fix.
Agreed, IMO the only proper fix to this and the other thumbnailer issues is to
give the editor more control over the thumbnailer output.

IMO only a human can judge how much color depth is really needed to give a
decent looking thumbnail of a particular image and whether it is sensible to
use lossy or lossless compression for that thumbnail. 
Comment 21 Tim Starling 2008-11-02 19:22:55 UTC
The point of server-side scaling is to make images take up less pixels while still looking nice, not to take up less bytes. Inevitably, downscaling will sometimes cause images to get bigger on disk, unless you accept a loss in image quality. This is because downscaling works by moving information from fine spatial detail into fine colour detail, via antialiasing. Due to the nature of the PNG format, that colour detail is not as easily compressable as the spatial detail which gave rise to it, thus the file size is bigger. 

There are two special cases where a saving might be made:

The colours in the final image will be linear combinations of the colours in the source image. This allows for space savings in certain cases. If the colours in the source image are colinear when plotted in 3-d colour space, then the colours in the final image will be along the same line. For instance, if the source image is greyscale, then the destination image will be greyscale.

If there are very few colours in the source image, then the antialiased final image will have a limited number of colours also, due to the limited number of ways in which the colours can combine. Say if there were 3 source colours. If you downscale by a factor of 2, then you might use a 2x2 grid in the source image to calculate each pixel in the destination image. So there are 3^4 = 81 possible 2x2 source image grids, and so 81 possible colours in the destination image. This allows you to map a palette source image to a palette destination image. However this potential saving diminishes rapidly with increasing number of source colours, and with increasing scaling factor.

I would argue that the initial report is naive, and that the bug should be closed as WONTFIX along the lines of comment 8: i.e. detection of the two special cases above can be filed separately as feature requests.

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