URLs of images that have this probelm:

http://de.wikipedia.org/wiki/Bild:TEST.png
http://commons.wikimedia.org/wiki/Image:The_german_language_since_1945.PNG

the strange thing is that thumbnails of those images work correctly. So, what is
the problem here? Maybe the software does not detect that the image *should* be
scaled. but in that case, the "high resultion" link would not appear, right?

Something else: it appears that the software indeed does not try to scale the
image, or it fails trying: The URL of the supposedly scaled image is the same as
the URL of the "original" version. I.e. no temporary/cached scaled version of
the files is created/used.

JeLuF told me this happens when an image gets bigger (in bytes) when scaled
down. This is the case for images that have a low color-depth (like 4 or 8 bit),
which are rendered in 24 bit depth when scaling (because auf antialiasing),
creating a file bigger than the original. In this case the software does not use
the scaled image, because it would be against the original purpose of this
feature, namely to preserve bandwidth.

However, as this feature is also very useful to allow large images to be seen
"at once" even if the original is bigger than the users screnn, and this is
percived as the main advantage by many users, this is confusing. Also, as images
with a low color-depth are not very frequent, i would argue that enabling
scaling even in cases where the scaled file is bigger than the original would
profit the users and wouldn't hurt too much bandwidth-wise.

colin.pitts wrote:

Even if the behavior is left as-is, it needs to be better documented so it
doesn't confuse anyone else in the future.

andrew.archibald wrote:

This bug was introduced by an attempted solution to bug 1218.

I suggest two things:

• Always resize images.
• 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 (the original motivation for the
unresized images).

avarab wrote:

The behaviour for image resize has been changed in HEAD (and note that this is a
change of behaviour, not a bug as such.)

avarab wrote:

Changed the summary to reflect the issue.