Generate optimised thumbnail even when dimensions match original
Open, LowPublic
Actions

Assigned To

None

Authored By

	Krinkle
	May 16 2014, 1:26 AM

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
Search...

		Status	Subtype	Assigned	Task
		Open		None	T43371 Thumbnail/imagescaler (tracking)
		Open		None	T67383 Generate optimised thumbnail even when dimensions match original

Event Timeline

• bzimport raised the priority of this task from to Medium.Nov 22 2014, 3:15 AM

• bzimport added projects: MediaWiki-File-management, Performance Issue.

• 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.

• Gilles added a project: Multimedia.Nov 24 2014, 3:17 PM

Tgr mentioned this in T75935: Reply with HTTP 302 (temporarily moved) instead of HTTP 500 when a full-sized thumbnail is requested.Nov 25 2014, 10:27 PM

This would also fix T11534.

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

Tgr mentioned this in T5361: Embed image author, description, and copyright data in file metadata fields.Jul 31 2015, 7:22 PM

McZusatz subscribed.Aug 9 2015, 1:28 PM

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

• Gilles mentioned this in T101015: Use optimised version instead of original when original size is used as thumbnail.Sep 7 2015, 5:55 AM

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 merged a task: T101015: Use optimised version instead of original when original size is used as thumbnail.May 4 2016, 9:35 AM

Krinkle added subscribers: • Gilles, Subfader.

Krinkle mentioned this in T135550: Exclude redundant srcset attribute values (e.g. same url).May 17 2016, 7:43 PM

Tgr mentioned this in T66214: Define an official thumb API.Nov 10 2016, 12:12 AM

MarkTraceur unsubscribed.Jan 27 2017, 10:11 PM

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

Krinkle mentioned this in T150741: Thumbor should reject thumbnail requests that are the same size as the original or bigger.

• Mholloway subscribed.Jun 12 2017, 1:39 PM

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 reopened this task as Open.Jul 5 2017, 11:50 AM

• Gilles removed • Gilles as the assignee of this task.

zhuyifei1999 subscribed.Jul 12 2017, 7:54 PM

• mmodell awarded a token.Aug 2 2017, 7:02 PM

Tgr mentioned this in T48921: Refuse uploading JPEG files with extra junk at the end..Sep 11 2017, 11:15 PM

Krinkle mentioned this in T92457: PageImages not compatible with webm files.Apr 28 2018, 1:38 AM

Krinkle mentioned this in T193792: Do not show a broken thumbnail for small video thumbnails.Jun 15 2018, 1:11 AM

Tacsipacsi mentioned this in T33366: File description page thumbnail click versus EXIF rotation, mustRender().Mar 21 2020, 7:24 PM

Tgr mentioned this in T250317: Add schema.org structured data to images on Commons and Wikipedia to meet Google's requirements.May 29 2020, 9:32 PM

Krinkle added a project: Performance-Team (Radar).Jun 7 2022, 3:33 PM

Krinkle moved this task from Limbo to Perf recommendation on the Performance-Team (Radar) board.