Commons talk:File types

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

Archival format for digital photographs[edit]

The page currently states: PNG is good for ... print-quality photographs. But this advice is questionable and TIFF might offer a better option. TIFF has the advantage of retaining the Exif and (if I am not mistaken) IPTC metadata, including, if the camera supports it, GPS location and timestamp information. It would be really helpful if this recommendation could be resolved and added to this help page. (Note also the discussion above on thumbnail sharpening.) Best wishes. RobbieIanMorrison (talk) 11:09, 6 February 2017 (UTC)

TIFF has a number of its own problems, such as that it's not actually a single image file format, but rather a loose file container for an indefinite number of image subformats, so that it's almost impossible to write a software program that will correctly understand or process all theoretically valid TIFF files. Any kind of metadata can be stored in a PNG file; the real question is having a standard way of doing so, so that different programs can access it. Various people have been working on this, but not sure that anything is widely accepted yet... AnonMoos (talk) 08:15, 7 February 2017 (UTC)
Hello AnonMoos (also Julian Herzog). Thanks for your thoughts. This question certainly needs resolution. I did some trials based on my own workflow using GIMP 2.8.18 on Ubuntu 16.10 (while noting that 2.8.20 is now current). I also searched the web for advice and read the archives for this page. The GIMP development branch (from version now has support for viewing and editing Exif, Adobe XMP, and IPTC metadata and this support will be included in the next production version 2.10.[1][2] This post covers digital photographs and not scanned prints and slides. Some points to take into consideration follow:
GIMP 2.8 will not transfer metadata from the RAW file to the exported TIFF file.[3] It makes no difference which GIMP preferences have been set or which TIFF export options (including type of compression or not) have been selected.
GIMP 2.10 will fix this problem. From the draft change log on the GIMP developer wiki:[4]
  • the Image → Image Metadata dialog will show Exif, XMP, and IPTC information
  • PNG, JPEG, and TIFF exporters will now have Save Exif, Save IPTC, and Save XMP options within the Advanced group of settings
In the interim, the metadata can be easily transferred using ExifTool (tested with version 10.23):
$ exiftool -verbose -tagsFromFile image.raw image.tif
PNG does not officially support Exif. However ImageMagick, ExifTool, and Exiv2 all support a work-around. Phil Harvey (author of ExifTool) posted the following to stackoverflow in 2014:[5]
ImageMagick stores EXIF information in a PNG "Raw profile type APP1" zTXt chunk when converting from JPEG images. This method of storing EXIF in PNG images is also supported by ExifTool (and I believe Exiv2 too), but it is not part of the PNG or EXIF specification.
ExifTool can read, write, or create Exif, XMP, IPTC and ICC (color management) data using a non-standard but somewhat common format.[6] ImageMagick convert will also copy this information across when undertaking a conversion. My trials with Exiv2 version 0.25 001900 (64 bit build) confirm that the utility will also read this metadata (I did not try to create or modify metadata though, but this functionality should also work).
The metadata can be transferred using ExifTool, although this form of metadata storage is not standardized:
$ exiftool -verbose -tagsFromFile image.raw image.png
XCF (the native GIMP format) is supported by Wikimedia Commons and does contain the Exif metadata embedded in the original RAW file. It is unlikely that Wikimedia Commons will generate a thumbnail from an XCF file, but that is okay because this is an archive format and there will be an associated lower quality JPEG image for general usage.
It did cross my mind to use XCF as an archive format until GIMP 2.10 is released (that could be many months). But I can see some downsides for this as well, including the requirement to have GIMP or GIMP-supporting software to view and manipulate the image file. In addition, (as I understand it) there are no guarantees on the stability of the XCF format. I am also rather tempted to use the development version 2.9.4 of GIMP and the concurrent risks of unresolved software, but there are a ton of dependencies to confront.
After further experimentation, ExifTool provides an ideal solution. The metadata can be shifted from the RAW source programmatically. See the two command lines above. The only outstanding question is whether to choose TIFF or PNG as the archive format. On balance I think TIFF wins out. PNG has the advantage of being almost universally readable on the internet, whereas TIFF has a long history as a raster file format and is widely supported by image viewing and image manipulation applications. Moreover the TIFF standard explicitly supports metadata, while the storage of Exif metadata and such in PNG files is customary at best. The fact that TIFF can be used in diverse ways is not relevant here as we know we are simply repackaging a RAW digital photograph using GIMP or Adobe Photoshop (or some other photographic processing application). Any comments? Best wishes. RobbieIanMorrison (talk) 01:20, 10 February 2017 (UTC)
RobbieIanMorrison -- unfortunately, your procedure reminds me of something I saw in the early 1980s, where the basics of the MS-DOS, Apple II DOS, and TRS-80 TRSDOS operating system file listing, file copying, and file deletion commands were listed, and you were supposed to choose between them on that basis... AnonMoos (talk) 13:54, 10 February 2017 (UTC)
Follow up: The book of GIMP authors Lecarme and Delvare (2013, chapters 19 and 20) [7] make very different recommendations from those above.
The authors suggest using GIMP's native format XCF as your long-term or archival format, preferably with gz or bz2 compression. But remember that the undo history for the current session is not saved. Nonetheless they note that XCF is not intended to be a universal format, but rather for work in progress.[7]:543 Notwithstanding, XCF is an open format and is supported by Wikimedia Commons as such.
If you must use a lossless format for distributing images, the authors suggest PNG.[7]:542 But they generally recommend JPEG at 85 quality. They remark "images at values greater than 85 generally look the same, and the loss of quality is practically indiscernible at such values. The degradation usually becomes apparent only if the value is less than 50".[7]:538 The authors add that the TIF format is a container for several formats "so there's no guarantee that all the features specified in an image will be properly handled by an application.[7]:521 PNG is a better choice if lossless compression is required. But generally the authors recommend that you choose JPG over RAW for circulating files.[7]:521 And for long-term storage, the authors strongly prefer JPG or XCF.[7]:523 RobbieIanMorrison (talk) 19:08, 5 March 2017 (UTC)


  1. GIMP gets advanced Exif, XMP, IPTC metadata support. Libre Graphics World (29 October 2013).
  2. (19 October 2013). "Gimp 2.10 bekommt Metadateneditor für Exif und Co". LinuxMagazin.
  3. GIMP doesn't save EXIF on TIFF files.
  4. Release:2.10 changelog : Metadata. GIMP developer wiki.
  5. Does PNG contain EXIF data like JPG?. stackoverflow (23 July 2014).
  6. Harvey, Phil. ExifTool by Phil Harvey. See table displaying supported file types.
  7. a b c d e f g () The book of GIMP: a complete guide to nearly everything, United States of America: No Starch Press ISBN: 978-1-59327-383-5.

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 (

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). 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 ( 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 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.
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(, 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". 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)