Page MenuHomePhabricator

Update MediaModerationPhotoDNAServiceProvider::getThumbnailForFile to choose a thumbnail that meets minimum height requirements for PhotoDNA API
Closed, ResolvedPublic

Description

In T351401: Create service(s) to send an image to PhotoDNA for a scan, services were added to allow scanning from the PhotoDNA API. These services work for files with around equal width and height. However, as raised in code review for that task, the current code is only getting a thumbnail that meets the width requirements. In the cases where a file is much wider than tall, the thumbnail sent to the PhotoDNA API will not meet the minimum height requirements.

The service should be updated to determine the best width for the thumbnail where the thumbnail is at least 160px in height. The best width is likely to be the smallest width possible while ensuring the height requirement.

Acceptance criteria
  • Ensure that the thumbnail sent to PhotoDNA meets the minimum height requirements where it is possible to do so with the given possible thumbnail widths

Event Timeline

We could bump the width to 1280 (an entry in $wgUploadThumbnailRenderMap) and that would narrow the list of potential cases where height is below the 160 pixel minimum.

We could bump the width to 1280 (an entry in $wgUploadThumbnailRenderMap) and that would narrow the list of potential cases where height is below the 160 pixel minimum.

I would be concerned about avoiding making the file too large. However, perhaps 1280px by 1280px isn't enough pixels to make such an issue occur.

We could bump the width to 1280 (an entry in $wgUploadThumbnailRenderMap) and that would narrow the list of potential cases where height is below the 160 pixel minimum.

I would be concerned about avoiding making the file too large. However, perhaps 1280px by 1280px isn't enough pixels to make such an issue occur.

What should we do with this task? @Tchanders @STran do you have any thoughts on it?

The downside to switching to 1280px is that we're transmitting more bytes (not sure if that would have a measurable impact on request times) and using more storage if we have to generate thumbnails.

I'm missing some context here, but here goes...

If we know the file size in advance as seems to be suggested in the conversation on gerrit, calculating the best width for the height sounds ideal. We can do that by calculating:

minWidthScalingFactor = minWidth / originalWidth
minHeightScalingFactor = minHeight / originalHeight

...then take the maximum of those.

  • This may increase the size (though the same applies to the current fixed width so I'm assuming that's allowed?)
  • If we need to use one of commons' pre-generated sizes, we can just use the smallest one that's bigger than the calculated scaling factor.

This seems a bit simple so maybe I'm missing something!

Change 989234 had a related patch set uploaded (by Tchanders; author: Tchanders):

[mediawiki/extensions/MediaModeration@master] Calculate ideal thumbnail width where possible

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

Change #989234 abandoned by Dreamy Jazz:

[mediawiki/extensions/MediaModeration@master] Calculate ideal thumbnail width where possible

Reason:

Needs to be significantly rebased and the approach to take has changed, so will create a new patch

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

Change #1134063 had a related patch set uploaded (by Dreamy Jazz; author: Dreamy Jazz):

[mediawiki/extensions/MediaModeration@master] [WIP] Choose ideal thumbnail width where possible

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

Change #1134063 merged by jenkins-bot:

[mediawiki/extensions/MediaModeration@master] Choose ideal thumbnail width where possible

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

Djackson-ctr subscribed.

QA is completed, I have verified the new code change(s) have been implemented and are functioning as expected Per the Acceptance Criteria.