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 <img> tag. Example: See http://de.wikipedia.org/wiki/Benutzer:Stw/Test The thumbnail size is 161x101, but in the HTML you have <img ... width="161" height="100"> 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 http://upload.wikimedia.org/wikipedia/commons/thumb/0/04/1px-Tape_measure.jpg, 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 "round".
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 just now.
Also see bug 4162; it'll be necessary to rerender a lot of thumbs.
Applied on CVS HEAD
Should 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]]
