Aug 3 2019
May 11 2019
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.
Mar 30 2019
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.
Mar 8 2019
Is there any further movement on this (anywhere else we can watch/add input)? Thanks.
Feb 7 2019
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?
Apr 24 2018
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.
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.
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."
Apr 23 2018
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.