dbenbenn wrote:

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!

rowan.collins wrote:

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.

dbenbenn wrote:

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.

Attached:

Solve the issue and commited. Thanks for the patch.

dbenbenn wrote:

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.

dbenbenn wrote:

There was a second "floor" I missed

Ah, there was a "floor" in Image.php, too. This trivial patch changes it to
"round".

attachment patch ignored as obsolete

dbenbenn wrote:

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.

attachment patch ignored as obsolete

dbenbenn wrote:

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.

Attached:

Marking need-review for updated patch.

gmaxwell wrote:

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

gangleri wrote:

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]]