Page MenuHomePhabricator

mobileview "thumbwidth" parameter doesn't always result in return of desired image url for SVG files
Closed, ResolvedPublic2 Story Points

Description

Background:

The "thumbwidth" parameter was added to mobileview to let us request the url for a size variant of an image bound by a certain width. i.e. say we want a 640px wide version of an image regardless of its height, such as for "lead" images. (Previously only "thumbsize" was available and it restricted *both* height and width.)

Anyway, the expected behavior is that thumbwidth set to, say 640, would get us the url to the size variant of the image closest to, but not exceeding, 640 in width, regardless of its height.

However, it appears that, for some images, a lower resolution variant url is returned:

Bug Example:

https://en.wikipedia.org/w/api.php?action=mobileview&format=jsonfm&page=wikipedia&thumbwidth=640&prop=thumb

Returns:

"thumb": {
     "url": "//upload.wikimedia.org/wikipedia/en/thumb/8/80/Wikipedia-logo-v2.svg/103px-Wikipedia-logo-v2.svg.png",
     "width": 103,
     "height": 94
}

What I would expect it to return is the following url for the 640 width variant:

"thumb": {
     "url": "//upload.wikimedia.org/wikipedia/en/thumb/8/80/Wikipedia-logo-v2.svg/640px-Wikipedia-logo-v2.svg.png",
     "width": 640,
     "height": 584
}

The results of this specific example (click on the image to see how bad it looks when you expect a 640 width but instead get a 103 width):

Details

Related Gerrit Patches:
mediawiki/extensions/MobileFrontend : masterDon't constrain SVG thumb requests based on the original file size

Related Objects

StatusAssignedTask
DeclinedNone
ResolvedCatrope
ResolvedSbailey
Resolved GWicke
Resolvedssastry
ResolvedNone
ResolvedDbrant
ResolvedbearND
ResolvedMholloway
ResolvedNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
ResolvedJdforrester-WMF
DuplicateNone
ResolvedbearND
OpenNone
OpenNone
DeclinedNone
DuplicateNone
DeclinedNone
OpenNone
OpenNone
ResolvedArlolra
ResolvedMooeypoo
ResolvedCatrope
Resolved GWicke
OpenNone
Resolvedmarcoil
Resolvedmarcoil
Resolved GWicke
DuplicateNone
DeclinedNone
OpenNone
OpenNone
OpenNone
OpenNone
DuplicateNone
ResolvedMholloway
ResolvedNone

Event Timeline

Mhurd created this task.May 7 2015, 9:30 PM
Mhurd assigned this task to MaxSem.
Mhurd raised the priority of this task from to Needs Triage.
Mhurd updated the task description. (Show Details)
Mhurd added a project: MobileFrontend.
Mhurd added a subscriber: Mhurd.
Restricted Application added a project: Readers-Web-Backlog. · View Herald TranscriptMay 7 2015, 9:30 PM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
Mhurd added a comment.May 7 2015, 9:40 PM

Basically it looks like it's returning a url for a size variant which doesn't exceed thumbwidth, but not necessarily the size variant closest-to-and-not-exceeding thumbwidth.

Mhurd updated the task description. (Show Details)EditedMay 7 2015, 9:45 PM
Mhurd set Security to None.

Another example showcasing the bug:

https://en.wikipedia.org/w/api.php?action=mobileview&format=jsonfm&page=information&thumbwidth=640&prop=thumb

"url":
     "//upload.wikimedia.org/wikipedia/commons/thumb/b/bb/WikipediaBinary.svg/88px-WikipediaBinary.svg.png",
     "width": 88,
     "height": 106
   },
Mhurd added a comment.EditedMay 7 2015, 9:47 PM

Oh interesting! It may be only happening for SVG images... can you confirm @MaxSem ?

Mhurd updated the task description. (Show Details)May 7 2015, 9:51 PM
Mhurd updated the task description. (Show Details)
Nnemo added a subscriber: Nnemo.May 7 2015, 10:17 PM
phuedx removed MaxSem as the assignee of this task.May 8 2015, 7:38 AM
phuedx added a subscriber: phuedx.May 8 2015, 7:41 AM

Thanks for all of the detail @Mhurd. What's the priority of this bug on your side? I'd like to put this through the normal Readers-Web-Backlog process and knowing if it needs to be fixed sharpish would help.

Mhurd added a comment.May 8 2015, 7:31 PM

Hey @phuedx, I'd say it's medium to high priority.

brion added a subscriber: brion.Jun 2 2015, 8:18 PM
Mhurd updated the task description. (Show Details)Jun 5 2015, 12:21 AM
Mhurd updated the task description. (Show Details)

@BGerstle-WMF @Fjalapeno

Hey guys didn't realize you weren't tagged on this. I added a screen shot.

There is a dupe of this card in iOS sprint 59: https://phabricator.wikimedia.org/T99126.

I recommend we close that ticket and instead pull this one into sprint 59. Let's do this thing :)

Mhurd added a subscriber: JKatzWMF.Jun 5 2015, 12:31 AM

@JKatzWMF here's a ticket that will improve some upstream bits :)

I'm recommending we pull this into the next iOS sprint and work with whoever to make it happen.

@Mhurd does this impact android as well? This seems like a reasonable thing to work on, but I think prioritization for this falls in the hands of @Fjalapeno, @Dbrant and @phuedx : TechPMs let me know if you want to discuss prioritization.

bearND added a subscriber: bearND.

Yes, this does affect Android as well.

Is this limited to SVGS? I see the width and height being returned is the preview size on https://en.m.wikipedia.org/wiki/File:Wikipedia-v2-logo.svg

Jhernandez added a subscriber: Jhernandez.

Going to have a good look at this next sprint.

@Mhurd can you help @Jdlrobson ^ and confirm it only happens with svgs? Thanks!

Jhernandez triaged this task as Normal priority.Aug 13 2015, 7:32 PM

@Jhernandez yes it's only happening with SVGs.

@Jdlrobson

Ah you're right, it's returning the first, lowest resolution preview size! The problem is it's ignoring the requested thumbwidth parameter. I believe the desired behavior is for it to return the preview size closest to (but not exceeding) the requested thumbwidth.

In the example in the ticket description, a thumbwidth of 640 is sought. So the "526 × 480 pixels" variant would be the closest match, not the "103 × 94 pixels" variant it's presently returning.

In mean time this could be worked around like so:

  • If SVG..
    • take height / width to get ratio e.g. h / w = 106 / 88 = 1.204...
    • Multiply desired width by ratio to get height e.g. 640 * ratio = 771px
bmansurov moved this task from To Do to Doing on the Reading-Web-Sprint-54-28-Days-Later board.

@bmansurov any findings from your time on this bug? No matter how small they might be enlightening - even if they are "this is hard" :)

@Jdlrobson, I haven't been able to get the API return a thumbnail of an SVG yet. I may have time to investigate more today.

bmansurov removed bmansurov as the assignee of this task.Sep 1 2015, 12:30 AM
bmansurov added a subscriber: bmansurov.

Feel free to pick the card up if anyone has bandwidth.

jhobs added subscribers: JMinor, jhobs.

@JMinor Can you escalate this to high if this needs attention from the web team (or comment on its relative priority)?

Jdlrobson renamed this task from mobileview "thumbwidth" parameter doesn't always result in return of desired image url to mobileview "thumbwidth" parameter doesn't always result in return of desired image url for SVG files.Nov 24 2016, 7:26 PM
Mholloway added a comment.EditedDec 9 2016, 3:40 PM

While I tend to agree that this is a bug, I think the thumb request API logic is working as expected: when a thumb of width greater than the original image size is requested, a link is returned for the file at the original dimensions. Here, the original (nominal) dimensions are 103px by 94px,[1] so that's what it returns dimensions and a link for. (Request a smaller size, and you'll see that the specified size is honored.[2])

For most file formats, that's what we want, because the thumbnailing engine won't render a thumbnail larger than the original.[3] However, SVGs are exceptional because they can be scaled arbitrarily, which the thumbnailing engine will in fact do for us.[4]

So I think the real fix is to create an exception for SVGs to the rule that the API won't return thumbnail results for a size larger than the original, and instead return results for arbitrarily large sizes for SVGs (within some reasonable limit). This would probably have to happen somewhere in MW core, where I think the core scaling logic lives. In the meantime I agree with @Jdlrobson that we could work around this on the client by detecting when we're dealing with an SVG and rewriting the size in the URL to whatever we want in that case.

[1] https://en.wikipedia.org/wiki/File:Wikipedia-logo-v2.svg
[2] https://en.wikipedia.org/w/api.php?action=mobileview&format=jsonfm&page=wikipedia&thumbwidth=80&prop=thumb
[3] https://upload.wikimedia.org/wikipedia/commons/thumb/8/8d/President_Barack_Obama.jpg/9999px-President_Barack_Obama.jpg
[4] https://upload.wikimedia.org/wikipedia/en/thumb/8/80/Wikipedia-logo-v2.svg/9999px-Wikipedia-logo-v2.svg.png

Mholloway added a comment.EditedJan 22 2017, 8:10 PM

Upon further investigation, this isn't getting constrained in MW core, but actually by this bit of logic in MobileFrontend:

https://github.com/wikimedia/mediawiki-extensions-MobileFrontend/blob/master/includes/api/ApiMobileView.php#L738-L743

In Monte's query in the description, for example, there's no thumbheight specified, so a height of 94px is getting set based on the (nominal) height of the original, and that value's then constraining the overall size when the thumbnail is generated. Omit adding these constraints and MediaWiki will happily give us a thumb and URL for any* size we specify for an SVG.

It would be easy to just add a check to skip adding these constraints based on the original file dimensions when $file->getMimeType() === "image/svg", but is there any reason to add these constraints in MobileFrontend at all rather than simply relying on the normalization logic in MW core?

*(subject to any maximum set in the global variable $wgSVGMaxSize)

Change 334791 had a related patch set uploaded (by Mholloway):
Don't constrain SVG thumb requests based on the original file size

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

Change 334791 merged by jenkins-bot:
Don't constrain SVG thumb requests based on the original file size

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

phuedx assigned this task to bmansurov.Jan 31 2017, 12:11 PM
phuedx set the point value for this task to 2.

2 story points for the review and testing (see rEMFR156bfe8aa9be: Don't constrain SVG thumb requests based on the original file size for detail).

bmansurov closed this task as Resolved.Jan 31 2017, 1:23 PM

Wikipedia logo at 640px wide is returning

{
    "mobileview": {
        "thumb": {
            "url": "https://upload.wikimedia.org/wikipedia/commons/thumb/8/80/Wikipedia-logo-v2.svg/640px-Wikipedia-logo-v2.svg.png",
            "width": 640,
            "height": 584
        },
        "sections": []
    }
}

Wikipedia logo at 80px wide is returning

{
    "mobileview": {
        "thumb": {
            "url": "https://upload.wikimedia.org/wikipedia/commons/thumb/8/80/Wikipedia-logo-v2.svg/80px-Wikipedia-logo-v2.svg.png",
            "width": 80,
            "height": 73
        },
        "sections": []
    }
}

Wikipedia logo at 103px wide (original size) is returning

{
    "mobileview": {
        "thumb": {
            "url": "https://upload.wikimedia.org/wikipedia/commons/thumb/8/80/Wikipedia-logo-v2.svg/103px-Wikipedia-logo-v2.svg.png",
            "width": 103,
            "height": 94
        },
        "sections": []
    }
}
bmansurov removed bmansurov as the assignee of this task.Jan 31 2017, 1:23 PM