Page MenuHomePhabricator

Allow requesting PageImage thumbnail size by width only
Closed, DeclinedPublic


This will make the width of the resulting thumbnail much more predictable, with at least two benefits:
(1) it will likely look better on mobile devices, where we're much more concerned about image width than height;
(2) it will more likely fall within a pregenerated thumb width bucket, for WMF wiki API consumers.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

Change 325066 had a related patch set uploaded (by Mholloway):
API: Add thumbwidth property parameter to restrict size by width only

How does this differ from the declined T132132 ?

This probably needs a priority, but since it is a task shared across teams I recommend Tracking it and creating a team specific task when it comes time to do work, and prioritizing that one.

bmansurov closed this task as Declined.Dec 14 2016, 2:06 PM
bmansurov added a subscriber: bmansurov.

Closing as a similar task T132132 has been declined. Feel free to re-open if you disagree.

Change 325066 abandoned by Mholloway:
API: Add thumbwidth property parameter to restrict size by width only

Task was declined. If we want width-only sizing restrictions it'll have to be via a different approach.

Jdlrobson reopened this task as Stalled.Dec 14 2016, 7:07 PM
Jdlrobson removed a project: Patch-For-Review.

I don't think declining this is appropriate. I'm still curious about a reply to
The approach was different but it wasn't clear to me if it would hit the same issues. I'd appreciate hearing more about the problem that the apps are seeing. @Mholloway can you elaborate?

Sorry it's taken me a while to get back to this. Here's an example of a case where we're not getting the behavior we want: the featured article response in the mobileapps enwiki featured feed from 12/16:

"tfa": {
  "title": "Vincent_van_Gogh",
  "extract": "Vincent Willem van Gogh (Dutch: [ˈvɪnsɛnt ˈʋɪləm vɑn ˈɣɔx]; 30 March 1853 – 29 July 1890) was a Dutch Post-Impressionist painter who is among the most famous and influential figures in the history of Western art. In just over a decade he created about 2,100 artworks, including around 860 oil paintings, most of them in the last two years of his life. They include landscapes, still lifes, portraits and self-portraits, and are characterised by bold colours and dramatic, impulsive and expressive brushwork that contributed to the foundations of modern art. His suicide at 37 followed years of mental illness and poverty.\nBorn into an upper-middle-class family, Van Gogh drew as a child and was serious, quiet and thoughtful.",
  "thumbnail": {
    "source": "",
    "width": 506,
    "height": 640
  "lang": "en",
  "dir": "ltr",
  "timestamp": "2016-12-16T22:04:32Z",
  "description": "Dutch post-Impressionist painter",
  "normalizedtitle": "Vincent van Gogh"

This is a standardized set of page summary content that comes from RESTBase and is replicated in structure throughout the feed. The problem we have is that RESTBase gets the thumbnail info for a page of interest from PageImages as part of its standard query to the action API action=query module, but PageImages (unlike the mobileview and imageinfo APIs) doesn't allow us to request a thumbnail specifically by width. What we'd like to do is request a thumbnail of a given width, but in many cases (i.e., where the image height is greater than the width) the value of the thumbsize parameter is used to restrict the height instead. Hence our 506px thumb URL instead of the desired 640px thumb URL here.

In the feed, we typically care much more about the width of an image than the height. It sometimes happens that a very tall, narrow image is restricted by height and turns out to appear of very poor quality when expanded to the width of the feed.

It seems like what you wanted to do in T132132 was maybe slightly more involved, as we're not looking to do any kind of on-the-fly rescaling, just allow a query parameter option such that the thumbnail URLs in the feed response are created consistently for the requested width. Still, I can see the argument that it's better not to add options like this in an ad-hoc way to every extension that deals with thumbnails.

Jdlrobson closed this task as Declined.Jun 15 2017, 9:43 PM

T66214 seems like a much better more generic solution to this problem.