Page MenuHomePhabricator

PageImages should support other aspect ratios
Closed, DeclinedPublic

Description

Currently when requesting a PageImage you provide a thumbsize parameter. This can result in images which either have a width of thumb size or a height of thumb size. This can be problematic when you want to render an image as a square consistently as it might lead to an image which has a height or width less than the thumbsize.

PageImages API should be more flexible in supporting this use case.

Event Timeline

Jdlrobson created this task.Apr 8 2016, 7:53 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptApr 8 2016, 7:53 AM

Change 276394 had a related patch set uploaded (by Jdlrobson):
Allow specification of thumbmode attribute for thumbnails

https://gerrit.wikimedia.org/r/276394

jhobs triaged this task as Normal priority.Apr 12 2016, 5:18 PM

I've added the blocked task T111329: [GOAL] Hovercards/Popups/Link preview on mobileweb given this issue will become more prominent when we push hovercards to more users.

Context of the gerrit patch for those who would rather not read a bunch of inline comments over multiple patch sets: A new parameter is proposed for PageImages that would allow "min" vs. "max" specification when requesting a thumbnail ("min" basically works like background-size: cover in CSS). Currently, the only way to do this is requesting the image as usual (max), checking the parameter and image dimensions, and then requesting the image again if necessary. Patch is basically blocked on the double request.

phuedx added a subscriber: phuedx.Apr 12 2016, 6:33 PM

@Jdlrobson, @jhobs: As I said, the mobileview API query module has the ability to arbitrarily resize images, which was introduced in 44fe067.

(The mobileview API query module does everything…)

Jdlrobson changed the task status from Open to Stalled.Apr 20 2016, 8:35 PM
Jdlrobson added subscribers: Anomie, MaxSem, Tgr.

I suspect to move this along we'll need to have a chat with @Anomie, @Tgr and @MaxSem.

Outstanding question we need to answer:
Is it more computationally expensive to
A) run transform twice (if needed) when the parameter is passed
B) allow file->transform to take a new parameter that gives the caller exactly what is needed and is possible to run on all requests?
e.g.

$thumb = $file->transform( array( 'width' => $newSize, 'height' => $newSize, 'thumbmode'  => 'min' ) );

I don't know much about the inner workings of MediaHandler to know the answer to this.
This card is stalled until we can answer that question.

Tgr added a comment.Apr 20 2016, 9:13 PM

On wikis using a 404 handler transform is very cheap as it just generates the URL of the file. With default configuration it will actually thumbnail the file twice, though. You could call MediaHandler::getTransform directly, but I don't see the point - you don't need to transform the file to see whether it will be width-constrained or height-constrained. Just compare image aspect ratio with bounding box aspect ratio - if the image aspect ratio is larger, the image is wider than the bounding box and you need to limit by height, and vice versa.

In any case, adding thumnail format parameters to the pageimages API feels like a hack. Ideally, thumbnail rendering should be done by the imageinfo API instead every single API module where someone finds it convenient; if that's not feasible because it would cause extra requests, thumbnail parameters should at least be standardized somehow and handled by some helper that can be shared between API modules.

(Even more ideally, this would be done through T37756.)

Change 276394 abandoned by Jhobs:
Allow specification of thumbmode attribute for thumbnails

Reason:
Per T132132#2225443

https://gerrit.wikimedia.org/r/276394