Please see https://phabricator.wikimedia.org/T108517 and check under "Related Objects" whether any existing open task already applies.
Is this the same problem as T31659 or T53400 or T71155? Thanks!

(It would be also welcome if the task summary described a specific problem.)

No, this problem is not the same as in those other tickets. In this case, the image of Margaret Thatcher at https://upload.wikimedia.org/wikipedia/commons/thumb/9/92/Margaret_Thatcher_at_White_House.png/240px-Margaret_Thatcher_at_White_House.png looks significantly blurrier or more out of focus than the image of her at https://upload.wikimedia.org/wikipedia/commons/thumb/1/15/Margaret_Thatcher_at_White_House.jpg/240px-Margaret_Thatcher_at_White_House.jpg .

How would sharpening png images effect non-photographic pngs ?

Commenting as I'm in the original linked discussion. I've looked through the linked Phab discussions and here's where I'm at: current behaviour is crap - there's no way we should have that amount of difference between thumbnail rendering of basically the same image just because it's a png rather than a jpg. Again, having read the linked discussions - ok, sharpening png thumbnails might make them bigger, or less optimal. Best solution I saw? Return a jpg thumbnail.

In T192744#4149625, @Begoon wrote:

Commenting as I'm in the original linked discussion. I've looked through the linked Phab discussions and here's where I'm at: current behaviour is crap - there's no way we should have that amount of difference between thumbnail rendering of basically the same image just because it's a png rather than a jpg. Again, having read the linked discussions - ok, sharpening png thumbnails might make them bigger, or less optimal. Best solution I saw? Return a jpg thumbnail.

While I appreciate your conviction that this is the right thing, quite often once applied it turns out we forgot all kinds of details. Wikimedia is simply huge, with lots of different use cases, which are easily overlooked. I think we need someone to run some tests to make sure any changes do not cause unexpected side effects (and if i remember correctly, for the VIPS scaler at some point, we couldn't even apply sharpening to PNGs, so maybe we need upstream changes (i don't think we use ImageMagick for PNG scaling any longer).

@Gilles, might you have some applicable insight here ?

Yeah, but it's been an issue since forever. I'm just happy to see any movement.

The logic behind this very old decision is that JPG and PNG thumbnails are optimized for different use cases.

JPG is optimized for photographic context where sharpening is considered beneficial because it retains detail in small thumbnails. It's a destructive process, but it makes thumbnails subjectively "look better" for a majority of people.

However, sharpening is very harmful on diagrams, schematics, etc. that have very sharp lines. It makes high contrast areas look bad. This is why PNG thumbnails don't have sharpening applied to them.

In theory, one could make the case that editors should be able to control whether an image gets sharpened or not, regardless of image type, with a sensible default. However, introducing this ability would have a significant impact on storage and caching capacity (by allowing to multiply thumbnail variants by 2), which has a non-trivial dollar cost. Would it be money well spent for the WMF, when the alternative is to upload photographs as JPGs?

Furthermore, PNG thumbnails are not only expensive for storage (they are much bigger to store), but also for viewers (they are much bigger to download). The penalty for someone on a slow and/or expensive connection in the developing world could be significant.

As such, I think it would be misguided to push for serving photographs as PNGs, regardless of sharpening or lack thereof. PNG thumbnails should really be only used as a last resort. In the case of diagrams it's a necessity, because even without sharpening, a JPG version would affect the visual information too negatively.

I said "...what about the large number of cases where png is used just to allow a "transparent background"? Jpg doesn't permit this at all, leading to things like this, and this. "Oval" portraits of historical subjects are a strikingly common example of this need, but there are many others, and the ability to display them nicely in infoboxes without needing to choose between "blurring" and a "white box" seems like it would be appreciated imo."

...and I just realised (sorry, I'm very slow, and very dumb) that returning jpg thumbnails for png wouldn't help this use case at all... I feel very small and foolish now, but... It's still an issue worth consideration, I think?

In theory, one could make the case that editors should be able to control whether an image gets sharpened or not, regardless of image type, with a sensible default. However, introducing this ability would have a significant impact on storage and caching capacity (by allowing to multiply thumbnail variants by 2), which has a non-trivial dollar cost.

As an aside, the decent way to do this without inflating storage needs would be to allow control of sharpening per file, not per thumbnail (Structured Data on Commons would provide a nice config interface for this). There is rarely a need to have sharpened and non-sharpened versions of the same image.

In T192744#4152456, @Tgr wrote:

In theory, one could make the case that editors should be able to control whether an image gets sharpened or not, regardless of image type, with a sensible default. However, introducing this ability would have a significant impact on storage and caching capacity (by allowing to multiply thumbnail variants by 2), which has a non-trivial dollar cost.

As an aside, the decent way to do this without inflating storage needs would be to allow control of sharpening per file, not per thumbnail (Structured Data on Commons would provide a nice config interface for this). There is rarely a need to have sharpened and non-sharpened versions of the same image.

I kind of alluded to this approach in the linked discussion with the pitifully primitive idea of a "png-photo" flag (per file) which would tell the software to always return jpg thumbnails for that file. It's a crap "solution" but we are where we are because of a decision to treat jpg and png differently based on file extension rather than actual content, so...

In T192744#4152456, @Tgr wrote:

As an aside, the decent way to do this without inflating storage needs would be to allow control of sharpening per file, not per thumbnail (Structured Data on Commons would provide a nice config interface for this). There is rarely a need to have sharpened and non-sharpened versions of the same image.

From an operational perspective this information would have to be stored in Swift alongside the original object as a special header, as access to the database from the thumbnailing layer is undesirable for security reasons. Something to keep in mind when you work on the UI for structured data in general. It could be stored in both places, but there needs to be a mechanism to keep that particular flag in sync in Swift. Switching the flag on and off would need to purge all thumbnails, obviously, but that's not difficult to do. Once such a flag exists in Swift, it's trivial for Thumbor to generate thumbnails accordingly. I've also believed for a while that this is the ideal solution to this problem, but for lack of an extensible file page editing interface right now...

IMHO the default should remain what it is today, as in the flag would only be set to override JPGs not to get conditional sharpening and for PNGs to get it.

Something else I didn't bring up is that the JPG sharpening is actually conditional depending on the resizing ratio (if the target size is close to the source size, no sharpening is applied). Seems to work fine for JPGs, though, so probably not another thing to make configurable per-file.

Well, again, I'm just happy we're discussing it productively. I do lots of image work and this is a genuine issue for end users. Any improvement in the current behaviour would be good. I actually hate my "flag" idea, but there's a deeper "false flag" in the software itself based on file extensions and inherent content assumptions.

FYI, at some point I traced back the decision that led to the current conditional sharpening parameters applied to JPG and the rationale for sorting content between JPG and PNG and it came from the very early days of Commons. The technical discussion about the sharpening parameters where someone showed different settings and people kind of voted for the best was in German, as I believe the German-speaking community was a significant driving force early on Commons. I've lost the link to that stuff, but the point is that it's a 10+ yo community decision.

In T192744#4152902, @Gilles wrote:

FYI, at some point I traced back the decision that led to the current conditional sharpening parameters applied to JPG and the rationale for sorting content between JPG and PNG and it came from the very early days of Commons. The technical discussion about the sharpening parameters where someone showed different settings and people kind of voted for the best was in German, as I believe the German-speaking community was a significant driving force early on Commons. I've lost the link to that stuff, but the point is that it's a 10+ yo community decision.

Fascinating. I love history. At the end of the day, though, png thumbnails still look "blurry" in Mediawiki. Can we fix that here or am I wasting your very valuable time and my own?

If the Structured Data on Commons delivers a file-editing UI that allows for the easy addition of a sharpening flag as described above, it becomes a fairly simple project to solve this issue by making this configurable per-file, regardless of extension. But I don't know the timeline of the Structured Data project for the UI component that's a blocker for this. @Tgr can probably provide more information about that.

As for non-WMF MediaWiki deployments, applying sharpening to PNG thumbnails is easily achieved by a one-liner modification to the MediaWiki code. Someone who needs this could go the extra mile and make it based on a config variable and it would get merged into MediaWiki itself. Just like someone recently made JPG quality configurable.

In T192744#4153048, @Gilles wrote:

If the Structured Data on Commons delivers a file-editing UI that allows for the easy addition of a sharpening flag as described above, it becomes a fairly simple project to solve this issue by making this configurable per-file, regardless of extension. But I don't know the timeline of the Structured Data project for the UI component that's a blocker for this. @Tgr can probably provide more information about that.

Thank you. I don't much like the "flag" solution even though I'm its reluctant parent, but that's a very clear answer. Sorry if I was brusque.

In T192744#4153059, @Gilles wrote:

As for non-WMF MediaWiki deployments, applying sharpening to PNG thumbnails is easily achieved by a one-liner modification to the MediaWiki code. Someone who needs this could go the extra mile and make it based on a config variable and it would get merged into MediaWiki itself. Just like someone recently made JPG quality configurable.

Again, thanks.

At the risk of being pushy - do you think there's a better place than here to ask: "png thumbnails still look "blurry" in Mediawiki. Can we fix that ?" I hate it when I ask things in the wrong place.

The task could be rephrased to the more actionable proposal we've discussed with @Tgr and have the relevant Structured Data on Commons task(s) marked as a dependency for it. If a team from Audiences at the WMF or from the joint WMF/WMDE Structured Data project is willing to tackle the UI and community consultation part, I'm fine taking care of the Swift/Thumbor part of things as a side project. I can't be driving it, though, as it's off topic for my team (Performance).

Thanks Gilles. You've been very responsive.

In T192744#4153059, @Gilles wrote:

As for non-WMF MediaWiki deployments, applying sharpening to PNG thumbnails is easily achieved by a one-liner modification to the MediaWiki code. Someone who needs this could go the extra mile and make it based on a config variable and it would get merged into MediaWiki itself. Just like someone recently made JPG quality configurable.

If current Commons users established a new consensus on sharpening of all PNG thumbnails on Commons, would implementation be feasible?

Sure, it's very simple to implement. But you're going to end up with a lot of terrible-looking maps and diagrams... I don't think that's a desirable change, I doubt anyone is going to bother reuploading all schematics with thin lines currently stored as PNG into a different format, so that PNG can be repurposed for photographs. The majority of the corpus of Commons images stored as PNG would render poorly when sharpened.

Using another lossless photograph-specific open format to store photos would be a more sensible path, imho.

Yet many png images on Commons ARE photographs, and WOULD benefit from sharpening of thumbnails. They have historically been uploaded as png because it's lossless, or for transparency - or simply because the original being uploaded was itself png. Which alternative format do you propose, and how will (tens of?) thousands of existing images be converted? And won't this potentially add a whole load of additional "duplicates" and even more confusion?

To work around the current situation many png files now have jpg duplicates just for thumbnailing, which need to be/should be synchronised with png masters - this is an unworkable mess, and can't help at all if transparency is required, as in many logos or hundreds/thousands of oval, historical portraits etc...

Wouldn't it make more sense to have a per-file, user configurable flag to enable/disable png thumbnail sharpening?

I understand that the default for such a flag, how it is set for existing images, and how it gets set at upload time, and maintained, are all aspects that would need discussion, but it does provide a simple solution to implement per-file where none currently exists. There are, for example, many cases where it could be applied across existing image categories which should ease implementation.

Per past discussion, what would be needed is:

• T199352: Deploy Structured Data on Commons with arbitrary Statements (soonish, I believe? @Jdforrester-WMF can probably provide details)
• the community should define a stadard for how image sharpening information is stored (this could be a new property that needs to be proposed on Wikidata, or could use some existing property, maybe along the lines of is_a photograph (p31 Q125191))
• presumably we'd want a nice user interface for it (include it in UploadWizard and whatnot) although it's not strictly necessary
• some hook in some extension (it's not really a good fit conceptually for anything I can think of, so we'd need a new one) should detect when the flag is changed, and push the info to a Swift header
  • MediaWiki needs an interface for extensions messing with headers (c402476 could be restored for that)
• Thumbor should check the header and apply sharpening appropriately

Frankly it seems like a lot of work for such a marginal feature, although maybe there are other uses for file transformations based on mediainfo data so some of it could be reused.

You say "it seems like a lot of work for such a marginal feature". It's not really a feature though, imo - it's a fix - and I don't believe it is 'marginal' either. We currently generate suboptimal thumbnails for thousands of images because of a very old decision to treat png and jpeg differently, based largely on an assumption that png would be used almost exclusively for diagrams and jpeg for photos. I don't have any statistics, but I do, based on observation, question the validity of that assumption.

What is certain is that we have no way to display transparent png thumbnails optimally for cases such as I mentioned above - irregularly shaped logos or hundreds/thousands of oval, historical portraits etc... What is also certain is that the current situation has resulted in many unwieldy, confusing, time-consuming 'workarounds' like keeping a lossless png 'master' synced with a jpeg copy purely for thumbnailing, or kludges where 'infobox' grey is used around oval/non-rectangular images to eliminate the white borders on copies of jpegs. This is desperation, though, and fails if someone has a custom theme or reuses the image outside an infobox. Resorting to 'tricks' like these should not be necessary and is pretty amateur.

A "png-sharpen-thumbnail" flag isn't a perfect solution by any means, but it at least gives a workable way to improve the quality of the thumbnails we serve.

@Tgr that's a sound plan. There is potentially an issue with the semantics of something like p31, because we have photos and scans (speaking of which, are scans photographs?) of maps and schematics, for which sharpening would have a negative effect. I think it would be better if the structured data property really is just about the image processing, as it would allow people to override it in special cases where the image is technically a photograph, but not one we want to see sharpened.

Is there any further movement on this (anywhere else we can watch/add input)? Thanks.

Here's another, current, example of the inconvenience this causes: https://commons.wikimedia.org/w/index.php?title=Commons:Graphic_Lab/Photography_workshop&oldid=349692308#Removal_of_frame. Yes, on this occasion, it turns out the end-user wasn't using the image in an infobox or other non-white background, so a jpeg was ok - but it's not portable should the usage scenario change, and would have required a 'kludge' if the intended usage had been infobox (or other non-white background/template etc.), as is the case with a great number (possibly the majority?) of these oval, historical portraits.