Last modified: 2005-12-14 11:28:18 UTC
When inserting a thumbnailed image, the size of the generated thumbnail (in
/upload/thumb/) is not always the same as the height and width specified in the
Example: See http://de.wikipedia.org/wiki/Benutzer:Stw/Test
The thumbnail size is 161x101, but in the HTML you have <img ... width="161"
This leads to ugly resizing on some browsers
I've seen the same thing with the third image at
[http://en.wikipedia.org/wiki/Petersen_graph]. I thought it was a problem with
my image; bravo for nailing down what the real problem is!
This is because MediaWiki's image code calculates the width *and* height, but
then only passes the width to the resizing code (i.e. ImageMagick or the GD
library). While it would presumably be possible to always arrive at the same
answer, it might be more reliable to ask the actual resize code what the
resulting height was and insert that into the html attribute.
If I ever get around to finally polishing my patch at bug 689, I'll probably
make it work that way.
Created attachment 580 [details]
1-line patch to fix the problem
ImageMagick apparently rounds when thumbnailing, instead of truncating.
I agree that it would be better to just identify the actual dimensions of the
thumbnail, instead of relying on how ImageMagick works internally. There are
two issues with that solution:
1) Identifying the dimensions of a PNG image is slow. We'd have to store that
data somewhere, instead of calculating it every time the page is rendered.
2) With a short, wide image (for example, [[Commons:Image:Tape measure.jpg]]),
asking for a 1px thumbnail simply copies the original image size (see
which is 1623x393). So that error would have to be detected.
Solve the issue and commited. Thanks for the patch.
Doesn't seem to have been fixed. See, for example,
[[Arapahoe County, Colorado]]. The locator map is 300 x 217 on the
page, but the thumbnail is really 300 x 218.
Created attachment 868 [details]
There was a second "floor" I missed
Ah, there was a "floor" in Image.php, too. This trivial patch changes it to
Created attachment 915 [details]
Fix the same issue on image description pages
The same problem with floor instead of round existed on image description
pages. In addition, if the image height was the limiting factor, the code
would floor twice, adding an extra error. This patch replaces that hunk of
code with something that only rounds once in either case, and that calculates
the thumbnail's height and width correctly.
Created attachment 916 [details]
Fix some problems when limiting the image's height
See http://commons.wikimedia.org/wiki/User:Dbenbenn/sandbox, which shows two
examples where MediaWiki is badly broken. Here's a combined patch to fix all
the problems I've found so far involving a disagreement between a thumbnail's
size and the <img> height and width parameters.
Marking need-review for updated patch.
ahh I'd made the same fix as above, but didn't catch some of the other places...
Came here to submit a patch, but it seems unneeded now. You should completely
omit the -size from convert as -resize is all we need (and who knows what what
other bugs we might trigger) :)
As discussed in IRC, -size is required to avoid huge memory wastage on large source JPEG images.
Patch looks ok (live on test.leuksman.com), but SF.net CVS is currently on the fritz, so can't commit
Also see bug 4162; it'll be necessary to rerender a lot of thumbs.
Applied on CVS HEAD
bug 4207: Wrong image size when using 100x200px syntax to scale image up
be marked as a duplicate or a dependency?
regards reinhardt [[user:gangleri]]