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.

In T217087#5071532, @Krinkle wrote:

In T217087#5071494, @Krinkle wrote:

This is breaking real content that has worked for years.

https://en.wikipedia.org/w/index.php?title=Template:Indian_states_and_territories_image_map&oldid=889956524

Now renders an image again, and with clickable countries:

Agree that floats should be permitted, and any type conversion only done after scaling, to avoid loss of precision. At https://en.wikipedia.org/w/index.php?title=Template:Indian_states_and_territories_image_map&diff=889959581&oldid=889956524 I was forced to convert a whole heap of poly co-ordinates to integer in order to get the template to render at all. Fortunately I could do this by using a perl command on a text file of the wikitext - "perl -i -pe 's/(\d*\.\d*)/int($1+0.5)/ge' filename" otherwise manually rounding hundreds of co-ordinates would have been quite a task. The floats had existed in the code for years without throwing this error, so it certainly was a change in behaviour.

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

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.

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?

Thanks Gilles. You've been very responsive.

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.

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.

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.

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.

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.

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

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

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.

From the comments and examples linked, this is evidently a very poorly thought out "feature", adding little, and leaving open many avenues of abuse.