Page MenuHomePhabricator

Generate optimised thumbnail even when dimensions match original
Open, LowPublic

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

Related Objects

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 3:15 AM
bzimport set Reference to bz65383.
bzimport added a subscriber: Unknown Object (MLST).

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.

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

matmarex set Security to None.
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.
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 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.

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

Gilles removed Gilles as the assignee of this task.
Krinkle lowered the priority of this task from Medium to Low.Oct 5 2022, 2:54 PM