Commons talk:File types

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search
This talk page is automatically archived by ArchiveBot. Any sections older than 180 days are automatically archived. Sections without timestamps are not archived.

WebP support[edit]

WebP is supported since March, and there are already ~100 Webp files on Commons (according to Special:MIMESearch/image/webp). Any objection to adding an entry to #Images?

(Since I’m no image-format expert, not sure I can come up with a good blurb on when WebP should and should not be used ; but at best I can put in something very generic :)

(cc @Rama: and @Yug: who were debating that format earlier).

Jean-Fred (talk) 10:19, 17 July 2017 (UTC)

Hi, It seems the thumbnail creation of WebP is broken, i.e. File:Album en blanco y negro.webp. Many of these files are copyright violations. Regards, Yann (talk) 15:06, 17 July 2017 (UTC)
What makes the copyright issue worse is that neither google images nor tineye seem to accept webp images. It would be good if someone could modify MediaWiki:Gadget-Tineye.js and MediaWiki:Gadget-GoogleImages.js to use our png thumbnails to feed the search engines instead (these work). Not sure where to request such a change, though. --El Grafo (talk) 15:25, 17 July 2017 (UTC)
Not sure if the issue of image search is with Google. I was able to find the source of File:Antinoo.webp with the feature "searching an image on Google" with Chrome. Regards, Yann (talk) 15:29, 17 July 2017 (UTC)
Whoops, you're right: entering the url directly works with both Google & Tineye, so I guess it must be a problem with the gadgets. --El Grafo (talk) 15:38, 17 July 2017 (UTC)
Given the ratio of good/bad files (10/90), this should be disabled completely... Yann (talk) 15:47, 17 July 2017 (UTC)

MP3 transcoding & upload[edit]

This is now legally allowed (https://phabricator.wikimedia.org/T120288#3316046).

While enabling Mp3 uploading will come with the natural drama. It would be a good idea to make a formal request to enable transcoding (separately from uploading) in commons. This has no impact on patrolling, and will enable more devices to access commons audio without special hardware. This format has had hardware and software support for longer than wikis have existed, and makes a lot of sense until something better comes along (or becomes free). 197.218.89.77 14:22, 18 July 2017 (UTC)

FWIW, there's already a task in Phabricator: --El Grafo (talk) 15:06, 18 July 2017 (UTC)
It is probably stalled (and overshadowed) by the whole discussion about allowing uploads in commons (https://phabricator.wikimedia.org/T167815) which is kind of odd considering that there are wikis that allow local uploads and that could make use of it regardless of what commons decides, e.g. probably mediawiki.org. It is also not a formal request, but a random task made by a developer.
The task phab:T165717 also still claims to be waiting for legal approval, which has already been granted.
P.S. The subject page is now inaccurate because MP3 is now legally permissible, the only thing stopping it in an agreement to activate it.197.218.89.46
I'm pissed. After 7-8 months since MP3 decoding support dropped in RedHat Fedora Linux and we still have no support.

Let's just allow .mp3 uploads (T162395) so we have something before Wikimania. No transcoding support needed since MP3 is supported in every browser. And thanks to WMF's WP0 fucking us we have people on audio/video copyright patrol. I have an AcoustID IRC bot running for basic MP3 matching (converting to a web tool). I also have an agreement with ACRCloud (strings attached) to scan music, if volunteers can't keep up. —Dispenser (talk) 03:32, 19 July 2017 (UTC)

Yes it is a pretty bad situation. Those tools should considerably mitigate this problem. But as long as no community holds a discussion and submits a request, they aren't likely to do anything about it any time soon. The easiest way to avoid drama is to do nothing, or prolong deployment indefinitely. It would be preferable if Wikimedia held a sitewide discussion about allowing any format that is free, and letting communities block them through either using abusefilter or configuration requests. There is no gain in rehashing the same discussions over and over again each time over "potentially" free formats each time (e.g. mp4, 3d, mp3). There is also a molecule format that merely lacks resources to get done(https://phabricator.wikimedia.org/T18491), and will likely elicit the same issues.
Many formats can facilitate vandalism, regardless of popularity. Those zero pirates have clearly shown that.
Anyway, for now the only option seems to be "waiting". 197.218.92.88 17:02, 20 July 2017 (UTC)

GIF is fine for images with 256 colors or less, and no transparency[edit]

Please change the section on GIF. PNG is NOT superior to GIF images when there are 256 colors or less, and no transparency. The images look the same.

GIF is no longer under patent. So PNG substitution for GIF is no longer necessary for images with 256 colors or less, and no transparency.

And GIF is much easier to use for editing images with 256 colors or less, and no transparency. GIF naturally uses far fewer kilobytes than PNG images, unless special effort is made to limit the color palette in PNG editing. Most uploaders do not have this skill.

See the discussion here:

By the way I started that page that is linked in the GIF section:

--Timeshifter (talk) 18:16, 30 November 2017 (UTC)

It seems you misunderstand something. Did you know that GIFs get automatic replaced by bots on EnWP and Commons?! I take a short, very first look in your uploads and what I see is also a very wrong use of the JPEG format. (It is hard to belief, you are a 10 years relatively active Commons user). Sorry, but you shifted 10 years to late to this talk page.
The only halfway argument what I see is "GIF is much easier to use", which seems nonsense for me too. As I said, please read this help page. Nothing more to say. -- User: Perhelion 23:46, 4 December 2017 (UTC)
Like most editors I usually upload what I find. I link to the source. I don't have the skill or time to convert to small-kilobyte PNG images. I leave that to others with more time and skill. I work in other areas. I sometimes add and remove text to images to correct headings, or to move headings to a better location in the graphic. If possible I use GIF as the final format if the graphic looks good with it. If not, I use jpg. Depends on if there are color gradients, etc.. So sometimes I have to use jpg as the final format. As I said, I don't understand how to create the equivalent PNG image with as low kilobytes. I gave up long ago on that, as have most uploaders.
I haven't see any robots replacing GIFs with other formats such as SVG or PNG.
I see notices added to GIF and PNG images when SVG images are available. The GIF and PNG images are not usually deleted without discussion, because many times the SVG does not match the GIF or PNG image, or has problems such as too small text, bad design, etc.. The article editors decide which image better serves their purposes. It takes skill to make quality SVG images. I use SVG images when they look as good or better than the PNG or GIF image. --Timeshifter (talk) 05:05, 8 December 2017 (UTC)
Timeshifter -- Color GIF images which naturally have less than 256 colors are usually candidates to be replaced by an SVG. If a color GIF image has been artificially reduced to 256 colors to fit within the GIF format, then PNG would not require such reduction. The only area where GIF truly holds its own (other than animated images) is in the case of grayscale images... AnonMoos (talk) 01:11, 5 December 2017 (UTC)
There are not enough SVG editors. So telling people not to upload perfectly adequate GIF graphics is dumb. Many graphics START as GIFs and are INTENDED to have 256 colors or less. So converting them to PNG is doubly dumb, because they are no better as PNG images. In fact, they may easily be made worse because the editor may not keep a limited 256 color palette in PNG, and end up with far more kilobytes for the same image.
PNG is fine for graphics that start out with more than 256 colors. But PNG has become a religion to some clueless people who don't understand the roots of the whole PNG versus GIF copyright issue. Now no longer relevant since both formats are free of patents.
Converting them to SVG is great, but many people uploading graphics do not have that skill. --Timeshifter (talk) 05:05, 8 December 2017 (UTC)

WAV and FLAC players[edit]

I noticed moving a WAV and FLAC file to a new name causes the player not to work on them unless the file is reuploaded. Anyone have this problem? – Illegitimate Barrister (talk • contribs), 02:40, 5 April 2018 (UTC)

Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons_talk:File_types&oldid=295567208"