Commons:Village pump/Proposals

Shortcut: COM:VP/P· COM:VPP

Welcome to the Village pump proposals section This page is used for proposals relating to the operations, technical issues, and policies of Wikimedia Commons; it is distinguished from the main Village pump, which handles community-wide discussion of all kinds. The page may also be used to advertise significant discussions taking place elsewhere, such as on the talk page of a Commons policy. Recent sections with no replies for 30 days and sections tagged with {{section resolved|1=~~~~}} may be archived; for old discussions, see the archives. Commons discussion pages (index) Commons Help desk Commons:Upload help Community-wide general discussion Copyright Proposals Graphics and photography discussion Image improvement Photography critiques Categories for discussion Deletion requests OTRS noticeboard Translators' noticeboard Work requests for bots Contact administrators Vandalism User problems (Dispute resolution) Blocks and protections Bureaucrats' noticeboard CheckUser requests #wikimedia-commons webchat Commons mailing list (archive) Commons' bugs on Phabricator Please note One of Wikimedia Commons' basic principles is: "Only free content is allowed." Please do not ask why unfree material is not allowed on Wikimedia Commons or suggest that allowing it would be a good thing. Have you read the FAQ?   Start a new discussion

SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 1 day and sections whose oldest comment is older than 30 days.

Allow WebP upload

Tracked in Phabricator
Task T27397

WebP is an open file format to store images in a lossy or lossless way. It supports transparency in both the lossy and lossless mode while providing smaller file sizes when compared with JPEG or PNG compression (even animation like in GIF is possible). Despite the technical advance, WebP could never gain substantial support other than by it's creator (google).

Below is a separate subsection where opinions about enabling WebP upload to the WMF cluster should be discussed as well as subsections for voting about the WebP upload. --McZusatz (talk) 16:36, 28 June 2015 (UTC)

Support

•  Support if and only if we get thumbnails in a format supported by Firefox and IE -- Rillke^(q?) 19:50, 28 June 2015 (UTC)

Just for reference, the current implementation in MediaWiki is like SVG, in that when users upload a webp file, a PNG file is displayed to the user (I have no idea if in the long term we might do something more complex, but that's what is there now). Bawolff (talk) 20:42, 28 June 2015 (UTC)

•  Support (assuming Bawolff is correct, with the same thought as Rillke) ToBeFree (talk) 23:06, 28 June 2015 (UTC)
•  Support WebP has a lot going for it when it comes to usability in many scenarios. Image editor, image tool support seems to be fairly decent as well. Offnfopt^(talk) 02:13, 29 June 2015 (UTC)
•  Support as long as we get thumbnails. --El Grafo (talk) 11:55, 29 June 2015 (UTC)
•  Support Can't think of a good reason not to assuming, as other supporters do, that thumbs work. Storkk (talk) 14:17, 30 June 2015 (UTC)
•  Support I see no harm in allowing the format to be used on commons even if its not widely used in industry. Reguyla (talk) 20:26, 14 July 2015 (UTC)
•  Support --Steinsplitter (talk) 18:49, 16 July 2015 (UTC)
•  Support to simplify the Web[AMP] upload documentation, otherwise I expect more from BPG. –Be..anyone (talk) 02:09, 17 July 2015 (UTC)
•  Support Indeed.Mogoeilor (talk) 06:15, 24 July 2015 (UTC)
•  Support Good reason to support... --Learnerktm (talk) 08:33, 24 July 2015 (UTC)
•  Support --Tchoř (talk) 09:58, 24 July 2015 (UTC)
•  Support. I agree with Reguyla. KiwiNeko14 (talk) 13:26, 24 July 2015 (UTC)
•  Support Agree.--Alexander Misel (talk) 02:35, 25 July 2015 (UTC)
•  Support Nyat (talk) 13:01, 25 July 2015 (UTC)

Oppose

•  Oppose Where is anybody using this format? Or is it going to be used only for JPEG and TIFF files that have been converted to WebP? Smaller size is nice, but it's hardly a killer feature.--Prosfilaes (talk) 21:19, 29 June 2015 (UTC)
•  Oppose WebP is supported in very few browsers and picture editors. 37.97% of WMF browser traffic would get WebP images, the rest would get png thumbnails (calculated from stats:wikimedia/squids/SquidReportClients.htm and caniuse.com). It is also very unlikely given this lack of support that WebP images would get uploaded.--Snaevar (talk) 13:03, 25 July 2015 (UTC)
•  Oppose Would be another image editing obstacle.--Kopiersperre (talk) 17:50, 28 July 2015 (UTC)
•  Oppose The point of Commons is that anyone can use the images without having to buy the "fanciest latest software" to be their magic decoder ring for our files. Please remember the multitude of our users who are not upscale, first-adopters and in many cases are working on older computers. Ellin Beltz (talk) 16:40, 6 August 2015 (UTC)
•  Oppose google's evil -- Kays (T | C) 12:25, 26 August 2015 (UTC)

Discussion

I believe in the technical superiority of WebP but many companies who enabled WebP had a response of bad user experience (e.g. facebook). Though, for all WebP files uploaded there would be thumbnails in the wider supported PNG format available for download. Still, user could normally not just download the full resolution and re-use it as is due to missing support (not to mention modify and upload an enhanced version). Furthermore, the Firefox web browser by Mozilla does not support WebP but Mozilla may take into account if WebP was enabled on the WMF cluster. (A comment in the bug tracker referring to it as the chicken-egg-problem) --McZusatz (talk) 16:36, 28 June 2015 (UTC)

COM:VPP may be a better place, if you want opinions of other language Wikimedians too. Jee 03:15, 29 June 2015 (UTC)

I agree with McZusatz, that it would be difficult for users who are offered a file in a format that their software doesn't support. There have been occasional complaints about Ogg formats I think, where there are good reasons for choosing the format. The problem could get worse over time, if WebP fails to take off and is abandoned by Google: it may be difficult to know what to do with these files in ten years. This would be offset on the other hand by a saving in storage space and network bandwidth, but since storage constraints are rarely if ever discussed on Commons, I have to assume it's not an issue. If WebP was widely supported, perhaps there'd be little reason not to convert existing files into that format and discard the originals, if no information was lost. --ghouston (talk) 04:03, 29 June 2015 (UTC)

There are already multiple file formats that users are able to download that they may not have software to support. Just with the other formats, we can point users in the right direction to the various software options available so they can take advantage of the media files. The issue at hand is not regarding converting existing files, we're basely talking about allowing WebP files to get uploaded in the first place. I think we need to worry about getting WebP allowed before we even worry about issues like converting existing media. WebP has a feature set that is not available in any of the other allowed formats. The source code for the WebP libraries and tools is open source, so the format will not just disappear. 10 years is a long time when it comes to computers, by that time no telling what technology or file formats will be in use, by that time we may end up having to convert most the media to a now unknown format. We should worry about if the WebP format is useful now and not about trying to predict the unknown future of technology. Offnfopt^(talk) 04:56, 29 June 2015 (UTC)

Formats rarely just disappear, but I've certainly seen cases where it's hard to find a copy of a ten year old open source program and when it's found, you discover that it depends on long-obsolete libraries and can't be compiled without significant changes. --Prosfilaes (talk) 21:19, 29 June 2015 (UTC)

You're talking about a hypothetical issue that does not currently exist. That is not a reason to not use it. If everyone used that mentality when it came to Linux some 24 years ago, no one would have tried it and it may have not been further developed. WebP is still actively developed and it has been for 4 years. The latest commit to the repository was done yesterday. We already support WebM which is the sister format of WebP. WebP was developed from the compression used in WebM. If we are going to support WebM there is little reason to not support WebP since they are based on the same concepts. Offnfopt^(talk) 23:38, 29 June 2015 (UTC)

WebM seems to have wider support than WebP, e.g., it's supported in Firefox. However it seems that Mozilla have decided not to support WebP in Firefox, on the grounds that they could get the same benefits by writing a better JPEG compressor. --ghouston (talk)

Mozilla have not decided against supporting WebP. I've read through both their tickets in bugzilla regarding WebP and the stance is they are undecided. They haven't made any concrete decision against WebP as it stands now. The JPEG encoder you're referencing "mozjpeg" is just that a JPEG encoder. Due to the format they are optimizing it only supports lossy compression, no lossless compression, WebP supports both. If you compare various JPEG and WebP files you'll notice less compression artifacts when using lossy compression compared to JPEG. The JPEG format being optimized doesn't support multi-level transparency (i.e. 8-bit alpha channel) or even any form of transparency because again the JPEG format they are optimizing doesn't support it, WebP does. WebP also supports muti-level transparency with both lossless and lossy compression. These features are also supported with animated WebP files. At this point in time we don't have support for any format with such a versatile feature set. We have nothing to lose by allowing WebP uploads. I think we should give WebP a chance.Offnfopt^(talk) 01:44, 30 June 2015 (UTC)

You're talking about hypothetical support from Wikimedia, Mozilla and others, so I feel free to talk about hypothetical issues. A bunch of people had that attitude towards Linux 24 years ago, but see, people actually were in need of a free Unix kernel 24 years ago. I don't see the value in fancy new transparency for Commons, especially when nobody really supports it.--Prosfilaes (talk) 20:27, 30 June 2015 (UTC)

If you don't see value in the features of WebP then clearly you won't be using WebP. But just because you do not see the value of WebP does not mean you should limit others from taking advantage of those features. By allowing WebP will in no way negatively effect you. You will still be able to upload the same formats you have up till now. Offnfopt^(talk) 21:24, 30 June 2015 (UTC)

It will mean that I can't usefully download highest-quality versions of works on Commons, either for personal use or to reupload to Commons. The list of formats is limited so that people don't have to worry that the file they download is in some random format they'll have trouble handling.--Prosfilaes (talk) 22:58, 30 June 2015 (UTC)

If you truly want to take full advantage of any of this media you should want to have the right software for the job. If you don't want to install additional software then you can use the PNG image that will be generated by the wikimedia site. We shouldn't hold back progress just because there are those that don't want to adapt to change. There are multiple file formats that we already support that require 3rd party software to take advantage of, this is no different. Offnfopt^(talk) 23:53, 30 June 2015 (UTC)

Says the person writing in English, despite the fact there's been a century of better languages made to be international auxiliary languages. Says the person talking about a Unix kernel, despite the fact that Unix is a 45 year old standard that has seen many improvements. 20 years ago, I bought a program that converted 90 different image formats. It is simply not feasible to support all image formats, even if they are the shiny new thing, and dump the weight on the people who use Commons. We support odd video formats and sound formats for patent reasons, and DJVU and TIFF because that's what archives use.--Prosfilaes (talk) 01:31, 1 July 2015 (UTC)

Create PNG thumbnails of static GIF images

Static GIF files should have their thumbnails created in PNG. The advantages of PNG over GIF would be visible especially with GIF images using an alpha channel. (c.f. thumbnails on the side)

How a thumbnail of a selected GIF file looks like today.

How a PNG thumb of this GIF may look like after the software change.

Support

1.  Support No brainer. --McZusatz (talk) 18:25, 14 July 2015 (UTC)
2.  Support Indeed. The thumbnail of the GIF in it's file history shows this particularly well. Revent (talk) 19:49, 14 July 2015 (UTC)
3.  Support A definite improvement. BD2412 T 20:12, 14 July 2015 (UTC)
4.  Support I agree, seems like a great improvement for the users of our images. Reguyla (talk) 20:24, 14 July 2015 (UTC)
5.  Support Seems like a straightforward improvement. — Julian H.^✈ 21:02, 14 July 2015 (UTC)
6.  Support (please notify other projects about this proposal) --Steinsplitter (talk) 18:48, 16 July 2015 (UTC)
7.  Support Makes sense. --Leyo 23:21, 22 July 2015 (UTC)
8.  Support About time :D Absolutely supporting. -- Srđan 📣  05:13, 24 July 2015 (UTC)
9.  Support Agreed. See also GNU vs GIF --Pkunk (talk) 05:28, 24 July 2015 (UTC)
10.  Support Indeed.Mogoeilor (talk) 06:14, 24 July 2015 (UTC)
11.  Support Hogne (talk) 06:18, 24 July 2015 (UTC)
12.  Support Why not? And thanks for asking about! --Alex_brollo Talk|Contrib 06:21, 24 July 2015 (UTC)
13.  Support Raymond 07:10, 24 July 2015 (UTC)
14.  Support seems very logic to me, VIGNERON (talk) 07:22, 24 July 2015 (UTC)
15.  Support Sounds reasonable. — Pinus 07:41, 24 July 2015 (UTC)
16.  Subteno Simplaj sed efikaj! sısɐuuǝɔıʌ∀ (diskuto) 07:47, 24 July 2015 (UTC)
17.  Support--Assar (talk) 07:58, 24 July 2015 (UTC)
18.  Support I'm too lazy to investigate why this wasn't the way things were done in the first place; they probably should have been. --Gutza (talk) 08:04, 24 July 2015 (UTC)
19.  Support Vera ^(talk) 08:14, 24 July 2015 (UTC)
20.  Support Yann (talk) 08:30, 24 July 2015 (UTC)
21.  Support Thibaut120094 (talk) 08:36, 24 July 2015 (UTC)
22.  Support Sémhur (talk) 08:42, 24 July 2015 (UTC)
23.  Support Dsvyas (talk) 09:11, 24 July 2015 (UTC)
24.  Support —TheDJ (talk • contribs) 09:43, 24 July 2015 (UTC)
25.  Support Looks good to me. --Robbie SWE (talk) 09:44, 24 July 2015 (UTC)
26.  Support --Tchoř (talk) 09:56, 24 July 2015 (UTC)
27.  Support --Marceau (talk) 11:05, 24 July 2015 (UTC)
28.  Support --Patrick87 (talk) 11:54, 24 July 2015 (UTC)
29.  Support Syced (talk) 12:35, 24 July 2015 (UTC)
30.  Support --Mmh (talk) 13:18, 24 July 2015 (UTC)
31.  Support. For me, PNG thumbnails and GIF thumbnails are just like day and night: the improvement brought by PNG thumbnails is immediately visible because it makes the preview instantly more recognizable. KiwiNeko14 (talk) 13:23, 24 July 2015 (UTC)
32.  Support PNG looks better. --Daniele Pugliesi (talk) 13:45, 24 July 2015 (UTC)
33.  Support--Mavrikant (talk) 14:16, 24 July 2015 (UTC)
34.  Support Don't see no reason why not. Amqui (talk) 16:32, 24 July 2015 (UTC)
35.  Support Natuur12 (talk) 17:09, 24 July 2015 (UTC)
36.  Support --Prog (talk) 17:41, 24 July 2015 (UTC)
37.  Support Looks Good. --Ziad (talk) 19:25, 24 July 2015 (UTC)
38.  Support — In the gif case, you sometimes feel the need to click on the image, just to make sure you didn't miss anything. --Winter^eu 21:01, 24 July 2015 (UTC)
39.  Support--Antigng (talk) 06:36, 25 July 2015 (UTC)
40.  Support-- Balou46 (talk) 08:15, 25 July 2015 (UTC)
41.  Support can't imagine reasons why not support. --Edgars2007 (talk) 09:14, 25 July 2015 (UTC)
42.  Support. Strongly agree! 👦 Rachmat - t 10:03, 25 July 2015 (UTC)
43.  Support Nyat (talk) 13:00, 25 July 2015 (UTC)
44.  Support Finally!!! --Ernest-Mtl (talk) 13:02, 25 July 2015 (UTC)
45.  Support ☆★Sanjeev Kumar (talk) 19:23, 25 July 2015 (UTC)
46.  Support Palapa (talk) 20:32, 25 July 2015 (UTC)
47.  Support Agree! Ninja✮Strikers ^«☎» 09:59, 27 July 2015 (UTC)
48.  Support Abso-lutely. --w^{L <speak·creatively>} 15:26, 27 July 2015 (UTC)
49.  Strong support This should be happen when commons was born. --Liuxinyu970226 (talk) 22:59, 27 July 2015 (UTC)
50.  Support --99of9 (talk) 04:54, 28 July 2015 (UTC)
51.  Support--Dineshkumar Ponnusamy (talk) 09:24, 28 July 2015 (UTC)
52.  SupportI support it as it looks it could help someone.--Juandev (talk) 09:29, 31 July 2015 (UTC)
53.  Support --User:Armbrust (Local talk - en.Wikipedia talk) 13:53, 31 July 2015 (UTC)
54.  Support the gain in quality worth the loss in bandwith --Xavier Combelle (talk) 17:01, 31 July 2015 (UTC)
55.  Support Nonoxb (talk) 10:49, 6 August 2015 (UTC)
56.  Support I'm a peng! guy -- Kays (T | C) 12:26, 26 August 2015 (UTC)
57.  Support I seen several static GIF files rendered very badly. PNG thumbnail should not cause any technical problems. --Amitie 10g (talk) 21:20, 2 September 2015 (UTC)

Oppose

1.  Oppose I can read the words in the given GIF-example, the words in the PNG-example appear smeared. That is due to my bad eyes. I might wear glasses, but do mid-to-end-40 men wear glasses volontariliy? Very opposed to this bad idea. --Matthiasb (talk) 09:24, 24 July 2015 (UTC)

   I have very bad sight (and, yes, I do wear very strong glasses and I am mid-to-end-40 man, too), and the PNG thumbnail is better readable for me, than the GIF thumbnail. --Mmh (talk) 13:12, 24 July 2015 (UTC)

   Hmm, we could actually make the text sharper. I believe we don't add sharpness to png images to avoid ringing/other artificats, which are more visible for the type of content normally in pngs. Bawolff (talk) 20:31, 24 July 2015 (UTC)

2.  Oppose if the new thumbnails are larger files than the original gifs - see discussion below. File size is a big deal on mobile and a bigger deal on mobile in the global south (slow networks and expensive data relative to local wage levels). Filceolaire (talk) 09:05, 25 July 2015 (UTC)
3. Partially oppose -- The change to PNG thumbnails would be highly positive for GIFs with single-palette-color transparent background (not "alpha channel"!), and could slightly improve thumbnail quality for non-greyscale GIF images. However, for opaque grayscale GIFs, the PNG format has no technical improvement to offer over the GIF format, and in fact, in many cases with current algorithms, the PNG thumbnails would be larger in byte size than the GIF thumbnails, as is being discussed. Therefore I strongly oppose rendering static opaque grayscale GIFs with PNG resized thumbnails. For some past discussions, see Commons:Bots/Requests/GifTagger#Issues with greyscale and transparency, Template talk:BadGIF, etc... AnonMoos (talk) 09:40, 25 July 2015 (UTC)

   "However, for opaque grayscale GIFs, ... the PNG thumbnails would be larger in byte size than the GIF thumbnails, as is being discussed". Actually, the discussed file is larger due to the difference in transparency model. For opaque greyscale gif thumbnails, I would expect the file size to be less, as the compression algorithm in PNGs is generally supperior to GIFs. (However, this is something that should actually be tested). Bawolff (talk) 14:42, 25 July 2015 (UTC)

   I don't know what percentage would be larger under the current set-up, but historically PNG thumbnailing has been somewhat neglected, there have been some long-standing inefficiencies or problems, and not all changes have been for the better in all respects. For the latest anomaly, compare the 120px thumbnails of the file versions of File:Sefer raziel segulot.png (explanation on User talk:Cmdrjameson)... -- AnonMoos (talk) 02:33, 28 July 2015 (UTC)

4. Nominal oppose The .png is blurry here, the .gif is not. Also for some files .svg would be the best solution. Rich Farmbrough, 00:38 27 July 2015 (GMT).

    Comment But at least logos lack of svg support, as phab:T86229 is unlikely to be resolved. --Liuxinyu970226 (talk) 22:56, 27 July 2015 (UTC)

5.  Oppose GIFs should be abolished and converted to PNGs.--Kopiersperre (talk) 17:47, 28 July 2015 (UTC)

Discussion

• This is nothing we can rule for other projects depending on us so I would suggest asking them beforehand to raise their concerns. -- Rillke^(q?) 20:59, 14 July 2015 (UTC)

@Rillke: You mean a mass message to all VPs? --McZusatz (talk) 16:57, 16 July 2015 (UTC)

Yeah, I think this would be sufficient. -- Rillke^(q?) 17:02, 16 July 2015 (UTC)

Just to be clear, you are proposing a software feature, not some kind of manual effort, right? --Tgr (talk) 05:21, 24 July 2015 (UTC)

Yes, the only manual effort is to change a line in the mediawiki software to serve PNG thumbnails instead of GIF thumbnails. --McZusatz (talk) 07:23, 24 July 2015 (UTC)

The description is a bit vague. I assume you propose that GIFs should be first converted to PNGs in their original size and than scaled down to create a thumbnail? If not, please correct my assumption. In any case, I encourage you to put the detailed description to the header. Also, was this consulted with developers to find out, that it is doable? (Links appreciated.) If it isn't doable then the entire voting probably doesn't have so much sense...
— Danny B. 05:49, 24 July 2015 (UTC)

Creation of thumbnails is done by imagemagick and does not involve explicit conversion to PNG first. Instead, the PNG tumbnails is created from the GIF "on the fly". @Bawolff: Can you confirm? --McZusatz (talk) 07:23, 24 July 2015 (UTC)

Yes, that's correct. If this change was to be made, the file would be thumbnailed using image magick convert program, with the following command line invocation 'convert' '-background' 'white' '/var/www/w/git/../phase3/images/3/37/(R)-3-phenyl-cyclohanone.gif' '-thumbnail' '120x33!' '-set' 'comment' 'File source: http://localhost/w/git/index.php/File:(R)-3-phenyl-cyclohanone.gif' '-depth' '8' '-rotate' '-0' '/tmp/transform_495cd244452c-1.png'. I believe making the change would be fairly easy. However, it should be noted, that in this particular example, the png thumbnail (at least with this command, I'm sure the file size could be reduced significantly if hand optimized) is larger than the GIF thumbnail would be (and actually even larger than the original GIF file). This is presumably because in the GIF case the original image uses only 3 colours (and the gif thumbnail uses 41 colours), where the png thumbnail uses 355 colours (2 8-bit channels). Bawolff (talk) 12:31, 24 July 2015 (UTC)

@Bawolff: Increased size for thumbnails does not sound good at all, considering mobile users. Though, it should be noted that empirically (given the appropriate compression algorithm) PNG files are always smaller than GIF files with the same content. Do you think it is possible to pipe all PNG thumbnails through some PNG optimizer like zopfli (best open source PNG optimizer out there, to the best of my knowledge) or some less efficient but cheaper optimizer? --McZusatz (talk) 13:19, 24 July 2015 (UTC)

Well the thing is, that the content is not the same. All the extra shades of grey/shades of alpha that make the shrunk details more visible, take space. FWIW, pngcrush (which i just happened to have lying around), significantly reduced the file size, but... it was still bigger than the original gif. Lots of this is probably just that this specific example image is a bit of an edge case. As for PNG optimizers - if done immediately after file creation, there is a trade off between extra latency vs smaller size - a trade off that I think would probably be poor, especially for the slower optimizers. However if we did the compression after the fact, at times when nobody is requesting the thumbnail, it might make more sense. I suspect User:GDubuc_(WMF) would have thoughts on if png optimizers are a good idea. Bawolff (talk) 20:29, 24 July 2015 (UTC)

I doubt we can get both: Better quality and smaller file size. --McZusatz (talk) 22:12, 24 July 2015 (UTC)

Histogram showing the relative size distribution of compressed PNG thumbnails

Running over ~174 random ~120px thumbs gives that zopfli with default settings can compress most of them to 80% of their original size relatively fast.

for file in png_src/*;do echo $file;tools/zopfli-master/zopflipng $file out_png/$(basename $file);done

--McZusatz (talk) 22:12, 24 July 2015 (UTC)

Would it be possible for you to run this again and make the size of the compressed image relative to the size of the gif? Then we would see the size trade-off after conversion and compression. Jeblad (talk) 14:23, 25 July 2015 (UTC)

Good catch! And maybe also a set of grayscale GIFs vs. coloured etc. --McZusatz (talk) 15:39, 25 July 2015 (UTC)

i had no idea that tool offered such a high ratio of improvement. I agree we should def look into using it. Bawolff (talk) 16:13, 25 July 2015 (UTC)

I actually misread what you said to be an 80% reduction in size (not 80% of original size). /me gets slightly less excited, but still that's quite a saving. Bawolff (talk) 18:08, 26 July 2015 (UTC)

I support delivering PNGs by default. In my opinion GIF does not offer a single advantage over PNG (except animations). So actually usage of GIF should be avoided wherever possible anyway.
Note however, that the bad rendering quality of the example image is due to a limitation of the GIF file format: In GIF there's only one transparent color (there's no alpha channel as in PNG). Since the image has transparency the renderer tries to upscale it but is bound to this "1 bit transparency" which as a result looks very rugged. This could be easily resolved by removing the partial transparency in the image and replacing it by a plain white background (or rather converting the image to PNG). It's therefore not a real render issue but an issue of the file format itself. The comparison is therefore a bit "unfair" and we might even think about deprecating GIF to resolve the cause of the issue instead of concealing the symptoms. --Patrick87 (talk) 11:54, 24 July 2015 (UTC)

After a bit of high precision guesswork (!) it seems like we might end up with smaller files in mean after this change, but I would very much like to see actual numbers. Jeblad (talk) 01:05, 27 July 2015 (UTC)

A more elaborate report would take 1 or 2 days to create. My schedule allows me to create such earliest on Sunday; So everyone is welcome to beat me by that time. --McZusatz (talk) 14:46, 27 July 2015 (UTC)

• Comment: Would it not be better if we moved towards converting such gifs into svgs? -- とある白い猫 ^ちぃ？ 13:02, 24 July 2015 (UTC)

@とある白い猫: Conversion from gif to png is immediate (you need just a converter software) and the result in png is every time of higher quality. Instead to have an svg file with higher quality of gif you need to create it from zero and the result is better only at higher resolution, while for icons svg quality can be also worse of gif. For this reason, I disagree to "convert" gif to svg. Instead we can create an svg from a gif or png maintaining the original file whenever is necessary or we can suggest image authors to create svg instead of gif/png if they know how to do and if the image as to be shown larger (for example 200x200px or more). --Daniele Pugliesi (talk) 13:54, 24 July 2015 (UTC)

I am thinking about getting another mass message out there about the "converting the image to PNG" thing. --McZusatz (talk) 13:19, 24 July 2015 (UTC)

• is there a reason you are not implementing Graphs extension ? makes both obsolete ? Slowking4♡Farmbrough's revenge 02:53, 25 July 2015 (UTC)

How does enabling an extension convert all existing raster images to Vega visualization grammar all of a suddden? --McZusatz (talk) 08:04, 25 July 2015 (UTC)

• Comment: Why not just convert all static GIFs to PNG, which will result in PNG thumbs anyway? It's why we have {{BadGIF}} and {{Convert to PNG}}, the first of which notes, "Commons discourages the use of GIF files, except for animations." djr13 (talk) 12:28, 28 July 2015 (UTC)

Just as a side note: on systems with Retina displays the two thumbnails in the proposal above look exactly the same. --Dschwen (talk) 20:03, 25 July 2015 (UTC)

Page logs

File:Untitled.PNG was just fully protected at my request, since it's (not surprisingly) a vague and unhelpful name that's gotten uploaded repeatedly. However, when I visit it, I'm presented with what would be a confusing situation for someone who doesn't know what's going on: there's no "create" tab, and since protection isn't part of the deletion and move logs, nothing about protection is mentioned. It would be nice if the sidebar had a "Logs" link, but I don't see one; the only way I know to get the page's log is to go to Special:Log and enter the filename.

With this in mind, I'm proposing that we add a short link to one of the MW-space messages that appear on the page, either MediaWiki:Moveddeleted-notice or MediaWiki:Filepage-nofile-link. All we need is something like

View this page's logs

Putting it on Moveddeleted-notice would avoid the problem of people going to a never-touched image (e.g. because they had a typo in a filename) and seeing a log link there, but putting it on Filepage-nofile-link would allow the link to be presented on a title that has been protected although never edited; of course this is a rare situation, but it would apply to obviously bad filenames. Nyttend (talk) 21:16, 16 July 2015 (UTC)

 Support. Linking to logs is very useful not just for inexperienced users to figure out what's going on, but also for experienced users. I have a function in my monobook.js to add a log link to all pages in the tools section of the sidebar, and I use it all the time for things like figuring out who uploaded a deleted file or if it's been previously uploaded. —LX (talk, contribs) 06:20, 17 July 2015 (UTC)

• Maybe using "all page's logs"? And instead of https:// please use Special:Log/. Where should this link be located exactly (example please)? --Steinsplitter (talk) 07:01, 19 July 2015 (UTC)
• View this page's logs will possibly not explicitly address the issue brought up. This page is protected and therefore can't be created. View log. would be more explicit in this regard.  Support in general. -- Rillke^(q?) 08:06, 19 July 2015 (UTC)
•  Support --Yann (talk) 09:01, 23 July 2015 (UTC)

• This page (logs) has been deleted. The deletion and move log for the page are provided below for reference. <<-- Something like this? --Steinsplitter (talk) 10:57, 23 July 2015 (UTC)

• Steinsplitter, that sounds quite reasonable. I just want some way of presenting the log links in a convenient manner. You ask where the link should be presented: I was suggesting that we tack it on to MediaWiki:Filepage-nofile-link or MediaWiki:Moveddeleted-notice. Nyttend (talk) 21:09, 10 August 2015 (UTC)

Category slideshow for category and its subcategories

Fotomontage für Feature-Request: "Category Slideshow für Kategorie und deren Unterkategorien"

translated with Google Translate:

In my view it would be very nice if there would be next to the icon for the Main Category also an icon for Category slideshows category including its subcategories (see adjacent photo montage). If you want to look for example all pictures of Prenzlau, you would have to start 13(!) slideshow...

The original German text:

Aus meiner Sicht wäre es sehr schön, wenn es neben dem Icon für die Haupkategorie auch ein Icon für die Category Slideshow der Kategorie einschließlich deren Unterkategorien geben würde (siehe nebenstehende Fotomontage). Will man sich zu Beispiel alle Bilder zu Prenzlau ansehen, müsste man 13(!) Slideshows starten ...

--Molgreen (talk) 15:14, 30 July 2015 (UTC)

É uma ideia interessante. Há questões a considerar, com respeito à “profundidade” de subcategorias a expôr (uma questão tanto técnica como interfacial) e à ordem de exibição.

^{(corr. Google transl.)} It’s an interesting idea. There are issues to consider with respect to the "depth" of subcategories to show (a matter both technical and of UI) and the display order.

-- Tuválkin ✉ ✇ 20:14, 24 August 2015 (UTC)

Special:UnusedCategories

The page Special:UnusedCategories isn't very useful the way it is because category redirects are there listed too which are of course unused by this point of view. Therefore imo it would be better if this page didn't contain category redirects. --Achim (talk) 10:10, 1 August 2015 (UTC)

Achim I agree and so do a lot of other people. There has been several requests to fix this but its not very high on the developers list so it may be a while. Reguyla (talk) 21:31, 30 August 2015 (UTC)

Bureaucrats removing admin rights

Over at en:wp, bureaucrats are able and permitted to desysop users in a few specific cases, all of which have parallels here: when self-requested by the user in question, when the user in question has been inactive for a certain period of time (parallel to Commons:Administrators/Inactivity section), or when consensus is in favor of removal (parallel to Commons:Administrators/Archive/Successful requests for de-adminship). Is there any good reason why our bureaucrats shouldn't be able and permitted to do the same thing? As is, removals due to self-request and due to inactivity are uncontroversial (a bot could do the inactivity removal!), and three of the last four successful requests for de-adminship were closed by bureaucrats (the exception was by a non-bureaucrat, following the admin's self-request for removal) — if we trust them to assess consensus at such a discussion, shouldn't we trust them to implement the decision? Steward Billinghurst has told me that such a change would require a Phabricator request, but it's something that would readily be performed if we got consensus here in favor of it. If you're interested, you may wish to read a relevant en:wp discussion from four years ago (bottom section of the page).

With this in mind, the official proposal: should bureaucrats be enabled and permitted to remove administrative rights when self-requested by an administrator, when a request for de-adminship has succeeded, or when an administrator has become inactive? Nyttend (talk) 02:59, 6 August 2015 (UTC)

Thanks for starting this discussion, I was surprised to find out quite recently that enwiki bureaucrats do this. I'll recuse and leave it to non-crats to discuss. --99of9 (talk) 04:32, 6 August 2015 (UTC)

I think this should only be changed on this project if there is a realistic requirement for it and the comparatively lightweight desysop process is insufficient (noting that en.wp had quite different problems to Commons around this). Have there been past cases where this was needed? --Fæ (talk) 05:51, 6 August 2015 (UTC)

I don't think that it will simplify anything. Unless all stewards are busy in real life and will not perform requested action for weeks. --EugeneZelenko (talk) 14:01, 6 August 2015 (UTC)

At a similar discussion at another wiki (meta?) I said that I generally support this for all wikis. There is no actual need for this for Commons, though, as desysops don't happen really often. --Krd 14:15, 6 August 2015 (UTC)

I'm inclined to agree with Krd. I'd generally support the idea however it happens so rarely I don't really think it is worth worrying about. There is a process and stewards will act on the decisions of the community. --Herby ^{talk thyme} 14:18, 6 August 2015 (UTC)

I am generally in favor of the bureaucrats doing this but I don't really feel strongly either way for this project and I am fine with whatever decision the Bureaucrats want to make on the issue. If we have bureaucrats that want to do this, the precedent has been set, so we may as well use it. On the other hand, I do not see a real need for this either. Requests to the stewards for action is generally fast and its rare this project requires a desysop anyway. As I stated before, just because ENWP does something doesn't mean we need to do it here. This makes a lot more sense for ENWP to do because they are a much bigger project, have a lot more problematic admins and a lot more problems to address. Reguyla (talk) 17:13, 6 August 2015 (UTC)

I don't think we have so many request so stewards are bothered every month or so. Occational desysop request, two regular inactive desysopping per year. Not that much of stuffs. — regards, Revi 17:23, 6 August 2015 (UTC)

@99of9 - I hadn't realised Commons bureaucrats couldn't do this!
I would strongly support bureaucrats having this ability on commons (of course, as an enwiki bureaucrat I am used to the idea that bureaucrats do -sysop). The point about project scale makes sense, but on the other hand I think every project should be as self-governing as possible. Commons has sensible bureaucrats, who can be trusted with the extra ability. I think they should have it - it's not very time consuming to hold a quick discussion and, if the idea is generally supported, for a developer to enable this. WJBscribe (talk) 10:57, 7 August 2015 (UTC)

Generally I agree: bureaucrats should be able to do that. But actually the current situation also does not create problems, so this is not an important issue. Taivo (talk) 11:42, 7 August 2015 (UTC)

I generally support, but there is no hurry in implementing this.--Ymblanter (talk) 17:43, 7 August 2015 (UTC)

+1 --Steinsplitter (talk) 17:44, 7 August 2015 (UTC)

• I strongly disagree with the idea that a project is improved by doing without the stewards. The standard permissions are good. --Nemo 18:12, 7 August 2015 (UTC)
•  Strong support -- I know 99of9 will probably smack me with a mackerel for expressing support so soon :P , but I don't think there is a reason to mistrust our functionaries with removal of adminship. We have a twice-annual inactivity review, which saw 12 de-sysops in March 2014, 10 de-sysops in September 2014 and 10 admins de-sysopped in March 2015. So that is 32 times in 18 months when a burocrat could have removed the admin bit on inactivity grounds and 4 times when they could have done it because of de-sysop requests in 2014 and 2015. I think there is plenty there for burocrats to do instead of stewards, especially given that not all of them are global renamers (a function transferred to Meta) and we have a gang of new burocrats elected recently. So I say YES to giving them this right. P.S. If you haven't done so, come along and join the debate about admin activity requirements. Green Giant (talk) 21:07, 7 August 2015 (UTC)

Wikimedia Commons article traffic statistics for categories and for individual images

Translation of my proposal with translate.google.de:

In my view it would be very nice if there would be a "Wikimedia Commons article traffic statistics for categories and for individual images" (example: http://stats.grok.se/de/latest30/Allgemeine_Erkl%C3%A4rung_der_Menschenrechte)

Many greetings

--Molgreen (talk) 17:11, 16 August 2015 (UTC)

The German original of my proposal: Aus meiner Sicht wäre es sehr schön, wenn es für Kategorien und auch für einzelne Bilder eine Abrufstatistic wie in der Wikipedia geben würde (Beispiel: http://stats.grok.se/de/latest30/Allgemeine_Erkl%C3%A4rung_der_Menschenrechte) Viele Grüße

--Molgreen (talk) 17:11, 16 August 2015 (UTC)

It exists yet, for example: http://stats.grok.se/commons.m/201508/Hauptseite --Steinsplitter (talk) 17:14, 16 August 2015 (UTC)

Direct file views aren't included in stats.grok.se as far as I know, but they are available in a raw form - http://dumps.wikimedia.org/other/mediacounts/ Bawolff (talk) 07:02, 24 August 2015 (UTC)

Actually, direct file views are available (select the file on Commons in desktop view, click on the history page, and you can select the pageview stats). That said, most people want the indirect page views, which is the number of times the file has been viewed on Wikipedia and other projects (in all language versions). This is a bit like trying to collect page views for Wikipedia pages with lots of incoming redirects - you need to collect each instance of page view type separately. It can be done using the global usage tool, but is quite tedious. Jane023 (talk) 07:10, 24 August 2015 (UTC)

By direct view, I mean any view of the image (not the image description page). i.e. The number of hits the url at upload.wikimedia.org gets. That would include any time anyone viewed the image, no matter what page it is embedded in. The new mediacounts dump provides this, but nobody's made a pretty interface for it yet. Bawolff (talk) 16:03, 27 August 2015 (UTC)

SVG help button

Prototype

Hello!

I'm trying to improve usability of SVG contribution to Wikipedia. Since SVG is troublesome and buggy as I explained here, I wanted to improve this by adding a "SVG help" button to file description pages in case of SVG. Additionally it will only be visible if a loggedin user is visiting this page so it will have a small impact to the majority of visitors on commons. Since it is overall a simple task I've hacked a prototype of it: User:Menner/svg-button.js. It is a button with a pull down menu and four options to choose.

Can such a script be embedded on Commons by default? --Menner (talk) 16:47, 22 August 2015 (UTC)

• I think it should be implanted in MW directly instead of loading it via resource loader. But i think it will take ages until the wmf is implanting this in mw, so js would be a solution. The script does not support i18n. --Steinsplitter (talk) 09:54, 23 August 2015 (UTC)

Its too Wikimedia specific to be implemented in MediaWiki generically. Its possible that it could be implemented as a php extension that's only installed on wikimedia wikis (Or included in WikimediaMessages extension), but honestly, its probably a lot easier just to do in js. Bawolff (talk) 07:06, 24 August 2015 (UTC)

Obviously there is no general refusal of such a SVG button script. How can I start the vote/discussion to add this on commons as default by every user? --91.6.67.6 06:13, 31 August 2015 (UTC)

Creation of PD template for Korea between 1910 and 1945

I found an old korean picture from the 1930s. Discussing the actual copyright status in COM:VPC, I propose to create a PD template for korean pictures (in my sandbox) taken/published between 1910 and 1945 (when Korea was occupied by Japan and before its splitting in the two current States), in similar way as {{PD-China}}.

For now, the tag shows texts indicating that the work is in the PD in the three countries, in Japan, the Republic of Korea and the Democratic People's Republic of Korea, and the three license tags {{PD-Japan-oldphoto}}, {{PD-South Korea}} and {{North Korea}}.

How can we improve this license tag? and more important, is actually viable to implement it? Please discuss, is very important to the several korean works unproperly licensed. --Amitie 10g (talk) 03:45, 26 August 2015 (UTC)

The tag should not say "taken" -- if photos were published elsewhere, that becomes the country of origin, not one of the Koreas. Also, I'm not sure I would include North Korea here. It appears they were not a part of any copyright treaty until 2003, and their law is from 2001. I have no idea what that law did to existing works... If they retroactively restored everything, then they have 50pma terms which cannot be guaranteed to have passed yet. There are no provisions in the law that I can see about what to do with existing uses of previously OK-to-use works, which you would normally expect if protection was being created for existing works. So, maybe it only applies to works published 2001 and later. It may be a law more for show than actual practice as well, which means it's anyone's guess what their protection for pre-2001 works is. Really, using the South Korea tag is probably enough for Commons purposes, since it was at least simultaneously published there, and that country probably has the shorter term anyways. Could add Japan I guess too.Carl Lindberg (talk) 07:15, 26 August 2015 (UTC)

Well, then I'll remove the DPRK, leaving just RoK and Japan, but I still considerig to keep the term taken, because is part of the {{PD-Japan-oldphoto}}; both term may coexist depending the date of making and publishing, IMHO. --Amitie 10g (talk) 09:14, 26 August 2015 (UTC)

No, Carl is correct, "taken" should not be in the summary at the top; this template is only appropriate for works that were published between 1910 and 1945 in occupied Korea. Works that were created between 1910 and 1945 in occupied Korea but published anytime or anywhere else should use the copyright template for where they were published (since the Berne convention defines the country of origin as where something was first published). For example, imagine a photo taken in 1940 in occupied Korea by a photographer who died in 2010 but first published in 2006 in the U.S. Such a photo could not use your proposed template as the photo's country of origin would be the U.S. and since the U.S. is pma+70, it's copyright would not expire until 2080. —RP88 (talk) 20:00, 26 August 2015 (UTC)

Whm, Carl is right, considering the overlapping the conditions of the both the Copyright Law of Japan and the RoK. Therefore, I added at the bottom the following centense

«This license applies only to works created in Korea and first published in that country. For works first published outside Korea, please use {{PD-South Korea}} only.»

Therefore, this template applies only for works first published (and created according to the Japan Copyright Law, but that term is somewhat questionable) in Korea and the author died after 70 years. How we can deal with the both Copyright Laws and the copyright status? --Amitie 10g (talk) 21:03, 26 August 2015 (UTC)

You should never use PD-South Korea for works first published outside Korea. Works first published in country X should use the appropriate rules for that country.--Prosfilaes (talk) 23:26, 26 August 2015 (UTC)

Whm you're right. Then, I changed to the country of the first publication instead. What about the prhase «applies only to works first published in Korea, and the author born in Korea and died after 70 years»? --Amitie 10g (talk) 04:38, 28 August 2015 (UTC)

Legal threats and blocking

Anyone object to this addition to the blocking policy? I self-reverted immediately after adding it; this was easier than attempting to explain the wording that I want and the location where I'd like to see it.

Rationale — I found such a threat and was curious how we handled them, since I routinely see en:wp using its legal threats policy but had never seen such a thing here. Not finding anything in the blocking policy, I ended up searching a while before I found the topic being addressed. There being lots of similarities between en:wp and us, addressing this difference seems helpful, and this difference being minor enough that it doesn't belong at Commons:For Wikipedians, I figured it would be helpful to include for future reference. Thoughts? Nyttend (talk) 00:18, 29 August 2015 (UTC)

I disagree with the outcome of the previous discussions – there was also Commons talk:Blocking policy/Archive 1#Legal threats – but I do agree that the prevailing position should be documented. —LX (talk, contribs) 08:41, 29 August 2015 (UTC)

Hi, Actually "Legal threats" can be a reason for blocking. As the previous discussion mentioned, there are 2 different situations (copy-paste from Jim):

• a threat of having a lawyer issue a takedown notice to Commons or of suing WMF to force the takedown of an image and
• a threat of suing an individual editor or Admin for any reason.

The first is OK, the second is not. Regards, Yann (talk) 10:11, 29 August 2015 (UTC)

I disagree. The second can be okay as well. If someone is harassing or threatening me, I would consider suing. In this case I am the victim, why should I be victimized even more by being blocked? --Sebari (talk) 15:17, 29 August 2015 (UTC)

Will you then sue the person who blocked you? Legal threats have a huge chilling effect, and induce a lot of stress. If you can't resolve things within Commons, then you probably shouldn't be here.--Prosfilaes (talk) 22:24, 29 August 2015 (UTC)

If you think I should not sue someone who, to give an extreme example, issues death threats, you should most definitely not be here. --Sebari (talk) 08:44, 30 August 2015 (UTC)

I think anyone who issues death threats would be blocked as well ;-) If something warrants an actual lawsuit, go right ahead -- actually filing a real lawsuit against someone should not be grounds for blocking. But threatening it as an escalation of an argument in discussions here is a different matter. That has been the policy on en-wiki for quite some time. If someone is being abusive, there are other avenues to follow -- it should be pretty obvious for a situation which would legitimately be grounds for a lawsuit. I would agree though that DMCA threats are not the same and are OK -- that is copyright owner's right. In looking at the original proposal, that did seem to require a user to cease editing if they did file an actual (non-DMCA) lawsuit -- I don't think I'd support that. Barring discussion of the lawsuit itself maybe, but not all editing. Carl Lindberg (talk) 15:46, 30 August 2015 (UTC)

Can we offer any good example of someone who should be issuing a takedown notice instead of just putting it up for DR? The first is just as much a sign of problems as the second.--Prosfilaes (talk) 22:24, 29 August 2015 (UTC)

Hi, It would probably in case when a DR is closed as kept, and for other reasons than copyright. Regards, Yann (talk) 00:02, 30 August 2015 (UTC)

•  Comment en:Wikipedia:No legal threats is very clear: "That users are involved in a legal dispute with each other, whether as a result of incidents on Wikipedia or elsewhere, is not a reason to block, so long as no legal threats are posted on Wikipedia." Taking legal actions against another person is one's basic right and we need not police it. But a threat like "I will sue you unless you stop" should not be posted on wiki. That's all. We need not bothered about take-down notices; it is a matter between WMF and the person. It is a common practice in OTRS too (if I remember well). Any mail with a threat tone will be forwarded to legal than replying by our volunteers. But we can prohibit posting taken-down threats like "I'll file a take-down unless you delete it" on wiki. (Sebari has the right to sue any; but should not make such threats on wiki.) Jee 02:27, 30 August 2015 (UTC)
  • If it is worded like this, it is fine. --Sebari (talk) 08:44, 30 August 2015 (UTC)

Idea Portal for any Wikipedia user

translated with Google Translate:

The following links an implementation of a portal for ideas I like very much: simple, user-friendly and clear and with a voting option. I would like that very well for every Wikimedia user ... https://ideas.microfocus.com/mfi/novell-zcm

The German original of my proposal:

Der nachfolgende Link einer Umsetzung eines Portals für Ideen gefällt mir sehr gut: einfach, bedienerfreundlich und übersichtlich sowie mit einer Abstimmungs-Option. Das würde mir sehr gut für den jeden Wikimedia-Benutzer gefallen . . . https://ideas.microfocus.com/mfi/novell-zcm