Commons:Village pump/Proposals/Archive/2015/06

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search

There should be a "Convert to JPEG" template

For images like: File:Spanking Bench.png & File:Spanking on Bondage Furniture.png —User000name 09:04, 6 June 2015 (UTC)

Are there particular technical problems with files in the (open) .png format that would be solved by conversion to jpeg? --MichaelMaggs (talk) 09:19, 6 June 2015 (UTC)
If you consider higher bandwidth use and file size than required a particular problem, you could solve one by conversion to JPEG. -- Rillke(q?) 18:04, 6 June 2015 (UTC)

Searching by text, not by category

Could you please, please, please provide a way to search the collection by textual contents (title, author, description etc.) rather than by category? The category classification may be useful to some users, but it is a haphazard maze that is far more effective at hiding images than at helping the user to find them.

The world is not a tree, and trying to chop it into the shape of one is a self-frustrating project. Cateories are not real; they are a figment of our minds, and what may seem a logical classification to one person will make no sense for another. Even a large full-time editorial board with strict coordination would find it difficult to classify images in a natural category system; there is no hope that that an uncoordinated and understaffed bunch of volunteers, no matter how well-meaning and devoted, will succeed at that task. At best, categories should be treated as keywords, meant to ensure that searches for some term relevant to an image will find it, even if the term does not appear in the title or description.

The default search should be a full-text search, sorted by matches in the title first, then by matches in the description, then by categories. Please... --Jorge Stolfi (talk) 22:54, 7 June 2015 (UTC)

If you prefix the search term with 'insource:' (without the quotes) the search will be applied to the actual wikitext, instead of to file and category names. See https://www.mediawiki.org/wiki/Help:CirrusSearch for more options. Revent (talk) 23:22, 7 June 2015 (UTC)
Er, as far as I know, the default search is a full-text search (random example), albeit one where category title matches rank fairly high (rightfully so IMO) − the only caveat is that *if* (and only if) there is an exact match in a category name, then you get redirect to that category. Jean-Fred (talk) 11:09, 8 June 2015 (UTC)

Idea: Website where I can upload not-free-yet pictures, and they get upload to Commons when copyright expires

I took many pictures of modern art paintings at a museum. I uploaded the public domain ones to Commons, and wonder to what website I could upload the others.

I got the idea of such a website, please tell me if that exists already:

  • The website should keep the uploaded images, and provide visitors with as much as what the copyright laws allow (for instance only metadata, and in some cases a small thumbnail)
  • The website should upload images to Commons as soon as they become public domain (the website should make calculations and keep track of that)
  • The website should allow visitors to provide metadata, such as title, author, year, description. This metadata should be semantic/searchable, for instance one could query all paintings painted in 1925.
  • Pictures that are reusable except for commercial use (like pictures of sculptures in Japan) should be available for download with a specific license excluding commercial use.

Illustration: http://i.stack.imgur.com/UYAb9.png Thumbnail of my picture of a 1925 painting realized in France by Catalan painter Joan Miró (1893-1983), owned by MOMAT and kept in Japan, will become public domain in 2053 if my calculations are correct and if laws do not change

My goal is that:

  • Wikimedia Commons receives the images as soon as legally possible.
  • Copyright length calculations are double-checked and organized, I don't have to keep track of all laws by myself.
  • If the painting is bought by a collector and kept private forever, at least we have a picture that will eventually be released.
  • If the museum burns, at least we know that a picture exists.
  • Have my pictures go to the greater good even if I die before 2053. And even if my backup disks fail before 2053, which is probable as well.

Has anyone heard about such a website? If not, anyone willing to create it or help? :-) Cheers! Syced (talk) 03:45, 9 June 2015 (UTC)

If they are things that would obviously be in scope once expired, a workaround would be to upload them, then immediately DR them with the "Undelete in XXXX" category added to the DR page, and a note as to why. It's not ideal, but works... if doing so, I'd suggest you ping an active admin to speedy close the DR. Revent (talk) 03:52, 9 June 2015 (UTC)
Interesting hack! Not for the common contributor though I guess. Category:Undeletion_requests contains a few dozens files for each year, suggesting that it is mostly for files uploaded by mistake, rather than a concerted effort to build a future collection. Lengths calculations are done case-by-case manually, which is error-prone. Also, such files lack metadata, so if this way of doing things becomes popular, it will become difficult to find out whether a given painting is already present or not. Thanks for the tip! I am still hoping there is (or will be) a dedicated tool for this though :-) Syced (talk) 06:15, 9 June 2015 (UTC)
It is, indeed, not a elegant (or really recommended) solution. We shouldn't really be intentionally storing things that way on any kind of scale, but for particular cases where there is a reason to suspect the work might not be permanently available, or (as I have done before) where you've done work cleaning up a book scan that's PD in the home country, but under the URAA, and want to make sure the clean version is not lost, it works. Revent (talk) 06:55, 9 June 2015 (UTC)
As a 'second thought', glancing back at this, I should clarify for the record... something like this should really only be done in a case where the content is both 'legal in the US' and 'legal to upload', and simply not yet allowable by Commons policy (typically, still copyrighted in the source country due to a term based on date of death instead of publication date). Still not really recommended, but possibly 'reasonable' in specific cases. Revent (talk) 18:32, 10 June 2015 (UTC)
If the pictures are in the public domain in Canada (50 pma only), you can upload then on Wikilivres. Regards, Yann (talk) 07:00, 9 June 2015 (UTC)
Depending on the country of publication, you could upload at least some of them to specific Wikimedia projects that have an exemption doctrine policy but such files would have to meet strict criteria. The alternative is a hypothetical non-free wiki which is what I think you're suggesting but that idea is stuck in the pipeline somewhere. Green Giant (talk) 08:20, 9 June 2015 (UTC)

Raise awareness of OTRS by including it in the Upload Wizard

Tracked in Phabricator
Task T36332

This entry at the help desk (permalink) made me aware that there are currently no instructions whatsoever in the Upload Wizard on how to proceed if a) permission to upload a file was given by a third party and b) if the uploader holds the copyright but permission is required nevertheless (e.g. copyrighted material from a company website). How can we expect people to file a permission via COM:OTRS if there's no way for them to know something like this even exists? I suppose we could avoid a huge pile of DRs, {{No permission}}s and frustration among users if we would make this more clear to the typical newbie uploader. At least a) could be handled quite easily by modifying the Upload Wizard. There was already a bug filed for this phab:T36332, but is was closed as "invalid" because of community consensus was not demonstrated. There, it was proposed to change the current wording in the Release rights step of the wizard (when This file is not my own work. is chosen) from 

The copyright holder published this work with the right Creative Commons license
Not all Creative Commons licenses are good for this site. Make sure the copyright holder used one of these licenses.
[license options]

to something like 

The copyright holder published or wants to publish this work under a Creative Commons license
   If the work is already published under that license online add URLs and short quotation of the permission text to the source field above. Also add the tag {{LicenseReview}}.
   If the work is not already published under that license online please follow the steps described at COM:OTRS (the copyright holder has to send an email) and add {{subst:OP}} to the source field above.
Not all Creative Commons licenses are good for this site. Make sure the copyright holder used or wants to use one of the following licenses:
[license options]

(Adding stuff to the source field was proposed as a workaround, since UploadWizard doesn't offer a permission field.) So: let's discuss this, find a consensus, re-open the bug and hand it back over to the developers. --El Grafo (talk) 09:05, 3 June 2015 (UTC)

  •  Oppose We already use OTRS far too much, the vast majority of declarations could be published with the benefit that any reuser could verify the details. The current default for secrecy just encourages information hoarding and cover ups when errors are made (which are far more often than is made public). --Fæ (talk) 10:40, 3 June 2015 (UTC)
    • If someone uploads a photo and the copyright to that photo obviously belongs to photographer Bob Jones (it's published on Mr. Jones' photography website, as are a host of other photos clearly taken by the same person), how would you suggest that the uploader authenticate the permission from Mr. Jones, if not via email? If the uploader says he is Mr. Jones, how are we to know that he is telling the truth? I could write out the COM:CONSENT form on a file description page claiming to be Barack Obama but that doesn't make it true. I don't see a good way to verify identity other than an email system where we can see that the email was sent from bob@awesomephotographsbybobbyjones.com. --B (talk) 22:01, 5 June 2015 (UTC)
    • Currently, OTRS is the only option we have and until someone comes up with a working alternative we better make the best out of it. Letting people upload stuff and telling them about OTRS afterwards is both very bad style (newbie uploaders get pissed) and a waste of resources (people need to tag files and calm down rightfully pissed uploaders, admins need to delete files that were uploaded because people didn't know the rules). --El Grafo (talk) 09:03, 7 June 2015 (UTC)
  •  Support It seems a sane idea. Yann (talk) 04:03, 6 June 2015 (UTC)
  •  Support Seems very helpful along with the automated responses. Jee 11:17, 6 June 2015 (UTC)
  •  Support good idea! Natuur12 (talk) 14:10, 6 June 2015 (UTC)
  •  Support Excellent idea. Thibaut120094 (talk) 14:29, 6 June 2015 (UTC)
  •  Support - I understand Fae's concerns but until there is a realistic alternative... Green Giant (talk) 18:06, 6 June 2015 (UTC)
  •  Support – glad to see that it only takes more than 3 years to implement such simple improvements. I don't understand Fæ's concerns at all, as currently uploaders are only being made aware of OTRS while the suggested wording also prominently refers them to our LR process. (Harmonised punctuation with the other options.)    FDMS  4    02:57, 7 June 2015 (UTC)
  •  Support makes sense. --Steinsplitter (talk) 10:32, 7 June 2015 (UTC)
  •  Support. Very good idea. -- Geagea (talk) 00:18, 8 June 2015 (UTC)
  •  Support I like it too. The more information we provide up front the better. A lot of people are very confused about it. --Jarekt (talk) 02:52, 8 June 2015 (UTC)
  •  Support Seems a good idea to me. ColonialGrid (talk) 14:29, 8 June 2015 (UTC)
  •  Support It seems a good idea. -- Christian Ferrer 18:07, 8 June 2015 (UTC)
  •  Support Sounds like a sound idea, as it is long overdue. Kevin Rutherford (talk) 12:24, 9 June 2015 (UTC)
  •  Support Not including the OTRS option is unnecessarily opaque, it seems to me. Walter Siegmund (talk) 14:53, 9 June 2015 (UTC)
  •  Oppose: My 1st idea, just by reading the edit summary in my watchlist, was to oppose. Now I read everybody’s input so far and I amm still against. Of course the fundamental issue here is the Upload Wizard, which needs to be improved (or removed…?) in so many ways — I am all for that. However OTRS seems to me better be kept as a last resort option, for the reasons given above by User:Fæ; the concerns expressed by others could be addressed by adding suitable instructions to the Upload Wizard, instead of presenting OTRS upfront as the one-stop all-purpose solution for remote license verification.
Frankly it is much simpler for everybody if our uploader asks WhatsHisName S. Photographer to upload a public permission somewhere in his website WhatsHisName.net than have him send an e-mail with the same permission to OTRS from an address @WhatsHisName.net. (This replies User:B’s question above.) Anyone can see the said webpage, linked in the permissions fields and subjected to {{License Review}}, while an e-mail to OTRS takes longer and is (in most cases, needlessly) secret.
-- Tuválkin ✉ ✇ 19:30, 9 June 2015 (UTC)
Simpler for everybody? Even using a CMS, creating a web page or uploading a permission statement to a private web server is hardly "simpler" than sending an eMail.    FDMS  4    21:35, 9 June 2015 (UTC)
Let’s put it this way: «If your image/file is already available online under an unsuitable license or otherwise you need to confirm its permission, you can either
  • send to OTRS an e-mail from a legitimate address stating your permission terms, and then wait 60 days, or
  • upload the same permission text somewhere in a legitimate website address, and then wait 3 days for {{License Review}}.»
And let them decide which is preferable. -- Tuválkin ✉ ✇ 23:12, 9 June 2015 (UTC)
Sure, but all this proposal is saying is that OTRS should be mentioned during the upload process as an option. I don't see there to be a valid reason not to mention a valid avenue for licencing images. Also, mentioning OTRS pulls the wizard in line with the upload form, which does mention OTRS. ColonialGrid (talk) 13:42, 10 June 2015 (UTC)
@Tuvalkin: I totally agree that {{License Review}} often is much quicker and more comfortable to use. In those cases where it's appropriate to use it, it should be preferred, of course. Maybe you've missed it, but the proposal actually does include this path and it comes right before the OTRS path. If that's not clear enough, we can still change the wording – you ideas would be very much welcome. --El Grafo (talk) 08:25, 17 June 2015 (UTC)
  •  Support Although I do agree this makes sense and seems like a good idea I also agree with Fae that OTRS already has pretty heavy workload and lengthy backlogs are common. Additionally I am not a huge fan of the lack of visibility of what goes on in OTRS with the excuse of "privacy". Reguyla (talk) 00:31, 10 June 2015 (UTC)
  •  Comment: "the copyright holder has to send an email" is incorrect. The copyright holder may just need to add the license statement to their website or wherever the files are published. I'd make the sentences less verbose, to reduce chances of errors and other mismatches with the actual instructions. --Nemo 23:56, 13 June 2015 (UTC)
    • @Nemo bis: Well, in that case you would wait until the license has been added to that website and proceed as described in the first option ("already published under that license"). Nevertheless, we can make the second one shorter. How about this:
If the copyright holder wants to release the work under that license via e-mail please follow the steps described at COM:OTRS and add {{subst:OP}} to the source field above.
--El Grafo (talk) 08:00, 17 June 2015 (UTC)

Marking Commons:Username policy as a policy

Please see Commons talk:Username policy#Making official for a RFC on making the proposed username policy official. Thank you, Tiptoety talk 00:12, 26 June 2015 (UTC)

Renaming categories that contain cfd templates

There is an issue that happens occasionally when moving categories to a new name. If a category page contains a {{Category for discussion}} template, say {{category for discussion|1=|and-so-on...}} the shown template message provides a link that points to the appropriate cfd discussion page. Well, but if then the category gets a new name and the contained cfd template is of course also "moved", that link points to nothing. It looks like a newly generated incomplete cfd request (can be seen here for example). So one laboriously has to look for the previous name of the category (which could be deleted in the meantime) and figure out the link to the matching cfd page for to get there. The problem can be solved easily using the parameter 1= of the {{Category for discussion}} template by entering the previous name of the category (as can be seen here). Summarized: If a category is renamed and if it contains a cfd template whose parameter 1= is empty, then the old name of the category should get added automatically to the template's parameter: 1=Category:Previouscatname . --Achim (talk) 18:00, 19 June 2015 (UTC)

Any idea where to drop this suggestion? --Achim (talk) 17:50, 25 June 2015 (UTC)
IMO the 1 parameter should be set by the AjaxQuickDelete gadget itself. That could be suggested here or by just pinging Rillke.    FDMS  4    19:05, 25 June 2015 (UTC)
Thanks. Thought about it: The other way round should work as well and might be easier to implement: If it were ensured that {{Category for discussion}} always uses parameter 1 (per default pointing to the cat name if it's empty otherwise) the problem should be solved, too. Of course then it must not be replaced in case of a category move. --Achim (talk) 09:00, 27 June 2015 (UTC)

looking for feedback

Saludos!

Im the coordinator for the Wiki Learning Tec de Monterrey User Group and Ive just put an idea in the Idea Lab at Meta Oral documentation of Mexican artisans Essentially, the idea is to videotape interviews with Mexican artisans and clips (perhaps more) of the creation of handcrafts such as pottery, basketmaking, etc for upload into Commons. The idea originated with comments during a presentation at Wikimania London, but we are now able to proceed with the idea not only because of the Museo de Arte Popular's long-standing support of Wikimedia but also because we have a dedicated group of students who have completed or are completing Wikimedia-related videos. Right now Im looking for feedback for the idea on Meta, and if you have an idea how to support us, Im all for that!Thelmadatter (talk) 18:52, 27 June 2015 (UTC)

Collections of/by institution

Wouldn't it make more sense to have a category tree like the following, instead of a piecemeal one divided by arbitrary institution type (library, museum, etc.)?:

  • Collections of institutions
    • [other subcats]
      • Collections by institution
        • Collections of type by institution
          • etc.

The distinctions between types of institutions blur (the special collections of libraries basically are museums, and plenty of museums have libraries), there are other types of institutions, e.g. archives, private foundations, religious centers (Vatican, LDS), it may take unnecessary research to figure out if something 'really is" a museum vs. a library, the distinction seems questionably meaningful in our context, and we'd have a richer array of extant categories in which to organize. — SMcCandlish [talk] [cont] ‹(-¿-)› 00:23, 17 June 2015 (UTC)

I'm not quite following why it is necessary to have a parent category called "Collections of institutions", and then a subcategory "Collections by institution". What's the difference between the two? Can we flatten the category tree by trying not to have both of these categories? Also, what are the "[other subcats]" of "Collections of institutions" that you envisage? — SMUconlaw (talk) 02:02, 1 July 2015 (UTC)

Add Template:Commons upload tools or a link to Commons:Upload tools to Special:UploadWizard

Let's face it: In its current state the UploadWizard can be a major pita. We've been told that the developers are working on a major overhaul of the Wizard's back-end, but as far as I'm aware that may still take quite a while. We have several other methods for uploading content, but they are completely hidden from the casual user. Whenever you ask a frustrated user something like "have you tried turning it off and on again using Vicuna/Commonist instead" you get an answer similar to "I didn't even know something like this existed". In fact, I got that answer from rather experienced uploaders as well. I therefore propose to include Template:Commons upload tools at the bottom of the Special:UploadWizard starting page, or at the very least include a link to Commons:Upload tools (entitled alternative upload methods or something similar) right next to the "back to the old form" at the top of that page. --El Grafo (talk) 13:51, 17 June 2015 (UTC)

This is technically not yet possible: 1 --Steinsplitter (talk) 14:15, 17 June 2015 (UTC)
Well, I wasn't assuming that anyone here could actually do anything to that page. But the stuff above has taught me that it's better to have documented community consensus before you file a feature request. So here I am, asking for opinions. --El Grafo (talk) 14:42, 17 June 2015 (UTC) Or can our local admins edit the target of (mwe-upwiz-subhead-alt-upload)? Then we could point that to Commons:Upload tools and add the old form there under "Integrated tools" (the latter should be done anyway).
This seems to be pretty trivial and does not need consensus. Technically i can atm edit only the header but not the footer. Filed phabricator:T104009. --Steinsplitter (talk) 16:52, 26 June 2015 (UTC)

Thanks for doing this, I noticed and have been using it a lot. Jane023 (talk) 08:23, 24 July 2015 (UTC)

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

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)

Oppose

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)
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump/Proposals/Archive/2015/06&oldid=183377450"