Discrepancy between thumbnail size and <img height=xx width=xx>
Closed, ResolvedPublic

Description

Author: stephan.walter

Description:
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


Version: unspecified
Severity: minor

bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz153.
bzimport created this task.Via LegacyAug 16 2004, 9:43 PM
bzimport added a comment.Via ConduitMay 30 2005, 7:24 AM

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!

bzimport added a comment.Via ConduitMay 30 2005, 1:43 PM

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.

bzimport added a comment.Via ConduitMay 30 2005, 10:24 PM

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.

  1. 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: thumbheight.patch

hashar added a comment.Via ConduitJul 8 2005, 10:18 AM

Solve the issue and commited. Thanks for the patch.

bzimport added a comment.Via ConduitJul 22 2005, 2:48 PM

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.

bzimport added a comment.Via ConduitSep 10 2005, 9:02 PM

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

bzimport added a comment.Via ConduitSep 26 2005, 8:01 AM

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

bzimport added a comment.Via ConduitSep 26 2005, 10:15 AM

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: patch

brion added a comment.Via ConduitOct 5 2005, 2:03 AM

Marking need-review for updated patch.

bzimport added a comment.Via ConduitDec 4 2005, 12:30 AM

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) :)

brion added a comment.Via ConduitDec 4 2005, 8:26 AM

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.

brion added a comment.Via ConduitDec 4 2005, 8:27 AM

Also see bug 4162; it'll be necessary to rerender a lot of thumbs.

brion added a comment.Via ConduitDec 4 2005, 9:04 AM

Applied on CVS HEAD

bzimport added a comment.Via ConduitDec 14 2005, 11:28 AM

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

Gilles added a project: Multimedia.Via WebDec 4 2014, 10:55 AM
Gilles moved this task to Closed on the Multimedia workboard.Via WebDec 4 2014, 10:58 AM

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.