Page MenuHomePhabricator

no robust way to thumbnail images by exact height
Open, LowPublic

Description

Author: M8R-cyc3n3

Description:
one cannot display on wikipedia a thumbnail of File:George-W-Bush.jpeg
at a height of exactly 600px. one can attempt to constrain it by height
and no width (enter [[File:George-W-Bush.jpeg|x600px]]).
however this produces a 453 × 599 image (!) while the next available size
454 × 601.

suppose a user needs to arrange horizontally several photos of arbitrary
dimension while keeping their top and bottom edges aligned. in many cases
this requires working backwards by coin-shaving the original images in a
graphics editor until round( $srcHeight * $dstWidth / $srcWidth ) happens
to equal the desired height.

for narrower aspect ratios (flag-poles, longcat, yao ming) this issue will
be more certain to arise.

the most obvious solution is to pass the size parameter directly to image-
magick as widthlessly (breadthlessly?) specified, e.g. this serves me well
for a local copy of the same photograph; the height is not replaced by a
dependent round-trip calculation.

owner@lappy:~$ convert George-W-Bush.jpeg -thumbnail x600 w.jpg
owner@lappy:~$ identify w.jpg
w.jpg JPEG 453x600 453x600+0+0 8-bit DirectClass 86.2KiB 0.000u 0:00.000

since mediawiki isn't doing it this way already, i should guess the real
issue lies in gracefully adopting a new thumbnail url pattern (one which incorporates the height-dimension in some fashion), or no?


Version: 1.17.x
Severity: minor

Details

Reference
bz24763

Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 11:07 PM
bzimport set Reference to bz24763.
bzimport added a subscriber: Unknown Object (MLST).

Is this a duplicate of bug 25989?

This bug is actually very annoying not only because it can't create thumbnail with exact height, but also because it will make the image VERY BLURRY.

The way currently mediawiki doing is to create a 453 × 599 image and then set it height to 600px by html code, which will made the image very blurry.

Example: https://en.wikipedia.org/wiki/User:%E7%83%88%E4%B9%8B%E6%96%A9/sandbox

HTML code: <img style="width: 117px; height: 190px;" alt="Tim Conway cropped.jpg" src="upload.wikimedia.org/wikipedia/commons/thumb/4/40/Tim_Conway_cropped.jpg/117px-Tim_Conway_cropped.jpg" class="thumbborder" srcset="upload.wikimedia.org/wikipedia/commons/thumb/4/40/Tim_Conway_cropped.jpg/176px-Tim_Conway_cropped.jpg 1.5x, //upload.wikimedia.org/wikipedia/commons/thumb/4/40/Tim_Conway_cropped.jpg/234px-Tim_Conway_cropped.jpg 2x" height="190" width="117">

Hm. This behavior is pretty fundamental to the way mediawiki handles scaling. It names thumbnails using only the width. it can't distinguish between the 453x599px image caused by requesting "width=453px" and the 453x600px image which you want to result from "height=600px". They would both have the same filename: 453px-Foobar.jpg".

I don't think this bug is related to bug 25989 at all, nor is it strictly related to the square bounding box RFC.

Fixing the issue would require (at least) adding the height to the thumbnail filename. You'd also have to worry about the storage issues involved with storing (for example) both a 453x599 and a 453x600 version of the same image. One current proposal is to drastically limit the number of 'standard' thumbnail sizes (https://www.mediawiki.org/wiki/Requests_for_comment/Standardized_thumbnails_sizes).

I do agree that it would be best if "square bounding boxes" (https://www.mediawiki.org/wiki/Requests_for_comment/Square_bounding_boxes) actually resulted in exactly the requested height, as this bug requests. But neither issue strictly depends on the other.

The cropping option proposed in T37756 might help as well, since it would guarantee an exact size for the thumbnail.

Jdforrester-WMF moved this task from Untriaged to Backlog on the Multimedia board.Sep 4 2015, 6:15 PM
Restricted Application added subscribers: Steinsplitter, Matanya, Aklapper. · View Herald TranscriptSep 4 2015, 6:15 PM
Restricted Application added a project: Commons. · View Herald TranscriptMar 1 2016, 1:07 PM
gpaumier removed a subscriber: gpaumier.Jul 18 2018, 5:57 PM