Page MenuHomePhabricator

Generate optimised thumbnail even when dimensions match original
Open, NormalPublic

Description

(T48936 comment 2)

However what we could do is never serve the original as a thumbnail.
The original is always available if a user visits the "File"
description page and downloads it, but when an article embeds an image
at a size that happens to not have a smaller thumbnail size available,
we currently serve the original. We could probably change that to even
serve a thumbnail for the nominal size (like we do with SVGs), which
would presumably make our urls a lot more consistent and allows for
better optimisation of smaller images.


See Also:

Details

Reference
bz65383

Event Timeline

bzimport raised the priority of this task from to Normal.Nov 22 2014, 3:15 AM
bzimport set Reference to bz65383.
bzimport added a subscriber: Unknown Object (MLST).
Krinkle created this task.May 16 2014, 1:26 AM

Sometimes people optimize the original for a specific use case.

(In reply to Bawolff (Brian Wolff) from comment #1)

Sometimes people optimize the original for a specific use case.

Do we have a vague idea how often that happens?

(In reply to Andre Klapper from comment #2)

(In reply to Bawolff (Brian Wolff) from comment #1)

Sometimes people optimize the original for a specific use case.

Do we have a vague idea how often that happens?

Not really. I would guess probably not very often.

Cases i could think of - apng files, demos for some particular feature (e.g. maybe on an article about exif, it would include a file with specific color profile)

Its also possible that this may increase the size of some files

Anyways code wise this is a one line change. I think more research would be needed to see if its a net benefit (or even if it has an appreciable effect at all outside of a few edge cases)

mankens wrote:

In the closed bug that Krinkle was referencing the concern was that some original image assets are being served instead of optimized ones. My impression now is that if the requested dimensions are greater than the original, then the original (unoptimized) file is served. If a copy of the original image was compressed and served instead then I think there could be real bandwidth-saving gains.

There is an attachment in that other bug showing some good lossless file size reduction for PNGs currently being served to users.

I think the opposite happens as well: the thumbnailer currently screws up some image types (I've seen transparent images and animated images mentioned in bug reports). I think including the original image if that is explicitly what is requested (ie, the 'frame' image option) is a good solution. I don't think we should *always* serve images from the thumbnailer, unless/until we add a special case to the thumbnailer to pass through certain image types unmodified.

Having had some additional experience with OCG, I'm leaning more toward comment 4 -- I've seen a lot of really terribly-encoded files, with crazy density settings and garbage EXIF and other strange stuff. Having uniform thumbnails would probably be an improvement.

This would also fix T11534.

Tgr added a comment.Feb 26 2015, 8:14 PM

Would also fix some inconsistencies when trying to use thumbnail URLs as a REST API, see e.g. T70320#729713.

Restricted Application added subscribers: Steinsplitter, Matanya, Aklapper. · View Herald TranscriptAug 9 2015, 1:28 PM
matmarex updated the task description. (Show Details)Sep 3 2015, 9:55 AM
matmarex set Security to None.
Jdforrester-WMF moved this task from Untriaged to Backlog on the Multimedia board.Sep 4 2015, 6:36 PM
Krinkle renamed this task from Serve thumbnails even for the original size of a jpeg or png to Create optimised thumbnail even when original size is used.May 4 2016, 9:34 AM
Krinkle removed a subscriber: wikibugs-l-list.
Restricted Application added a project: Commons. · View Herald TranscriptMay 4 2016, 9:34 AM
Krinkle updated the task description. (Show Details)May 4 2016, 9:35 AM
Restricted Application added a subscriber: Poyekhali. · View Herald TranscriptMay 4 2016, 9:35 AM
Krinkle renamed this task from Create optimised thumbnail even when original size is used to Generate optimised thumbnail even when dimensions match original.Jun 10 2017, 3:11 PM
Gilles closed this task as Resolved.Jul 5 2017, 6:48 AM
Gilles claimed this task.

Possible in production with Thumbor now: https://upload.wikimedia.org/wikipedia/commons/thumb/2/2e/Anfiteatro%2C_El_Jem%2C_T%C3%BAnez%2C_2016-09-04%2C_DD_41-43_HDR.jpg/4197px-Anfiteatro%2C_El_Jem%2C_T%C3%BAnez%2C_2016-09-04%2C_DD_41-43_HDR.jpg

Upscaling is also possible, in fact, since we're going to regularly clean up large thumbnails in Swift and this protection was wildly inconsistent in Mediawiki, where upscaling was already possible on some non-vector formats (and nobody seemed to notice). Since the operational concerns aren't a problem anymore, there was no reason to keep this artificial inconsistent limitation, which was actually a lot of work to reproduce in Thumbor.

Tgr added a comment.Jul 5 2017, 8:43 AM

This task is about doing it in MediaWiki though, which is still not fixed.

Gilles reopened this task as Open.Jul 5 2017, 11:50 AM
Gilles removed Gilles as the assignee of this task.