Commons talk:File types/Archive 2

Upload problem

ogg files will not upload using the upload from menus. What dir would it have uploaded to if it di? Maybe I can FTP it into the dir 24.249.248.8 15:34, 18 November 2008 (UTC)

Sounds like an upload form problem. By the way, you have to be logged in to an account to upload... AnonMoos (talk) 11:32, 20 November 2008 (UTC)

encapsulated PostScript (.eps)

Is encapsulated PostScript a free format?—msh210 21:26, 28 January 2009 (UTC)

It's defined by Adobe, but that by itself wouldn't necessarily keep us from hosting such files here (we do host PDF files). However, the fact that just about everything that EPS files would be useful for here on Commons can also be done by SVG files, and that the SVG format is more "lightweight" than EPS and fully open, does mean that EPS files are unlikely to be allowed... AnonMoos (talk) 07:54, 29 January 2009 (UTC)

Tiff

According to Special:Upload, tif and tiff are now allowed.[1] --Nemo 16:09, 17 March 2009 (UTC)

What on earth for?… ¦ Reisio (talk) 08:52, 18 March 2009 (UTC)

This file-format is with 16bit per channel and different layers interesting for interchange in production phase. --Kolossos (talk) 21:18, 21 March 2009 (UTC)

Do we have the exact date of the change, so we can put it to the allowed list with a date and link to the reference? Esby (talk) 09:20, 14 April 2009 (UTC)

JPEG 2000

Even though we may not be able to generate thumbnails for them, someone raised a question on the village pump about allowing JPEG 2000 files on Commons, though I'm not sure if its legal enough for Commons. ViperSnake151 (talk) 02:32, 26 March 2009 (UTC)

That was me. I argue we should allow JPEG 2000 because many public domain sources (e.g. archive.org and several museums) archive their raw scans or photos in JP2 format. I actually have some ready to upload as soon as we turn this on. I don't think patents are a significant issue with JPEG 2000. Dcoetzee (talk) 07:42, 7 April 2009 (UTC)

Usage of MKV as a video container?

Could the MKV file format allowed as a video container? Supposed the contained streams are using an open codec and that they are not subject to copyright, of course. Esby (talk) 09:18, 14 April 2009 (UTC)

Good question. Anyone know why it's not permitted on Commons? mahanga (talk) 01:47, 4 January 2010 (UTC)

See UED77's comment in Archive 1#Video_containers. I'm not sure the Ogg files we have now all contain data in free formats, or whether we'll need to make sure even for Ogg in the future (I'd imagine so). As with so many problems, the resolution of bug 4421 could resolve the issue. ¦ Reisio (talk) 07:37, 4 January 2010 (UTC)

Proposal to enable uploads for DNG files

See Commons:Village_pump#Proposal_to_enable_uploads_for_DNG_files. Dcoetzee (talk) 09:57, 8 June 2009 (UTC)

The JPEG Description is confusing and contradictory

The JPEG description is very confusing and contradictorily. It's basicaly saying, that you should upload your photos as PNG files: "If you have a choice of file formats in which to save a photograph, scan, or other such thing, save it as PNG". But the Contributing your own work guide is saying that you should use JPG for phtos: "Photography: JPG". Somehow this antilogy should be clarified. --PhilipMay (talk) 14:32, 20 July 2009 (UTC)

PNG is preferred for archival storage, when someone else may edit the file further in the future (since most edits to a JPEG file will involve irreversible generation loss, with certain very specialized and limited exceptions). However, for actually displaying photographic-type images within Wikipedia articles, JPEG format is in fact greatly preferred, since Wikimedia downsizing of photographic PNG images produces large thumbnails which take up a great amount of bandwidth, and can be slow to load... AnonMoos (talk) 22:26, 20 July 2009 (UTC)

Well... You say: "PNG is preferred for archival storage" and "for actually displaying photographic-type images within Wikipedia articles, JPEG format is in fact greatly preferred". I am still confused. Should I upload my own photos in PNG or JPG format? The contributing your own work guide clearly sais JPG but when and in which case should I use PNG? Or should I upload the images in both formats? --PhilipMay (talk) 12:35, 21 July 2009 (UTC)

Best would be uploading in both. This however depends also on your original files. If your files from the camera or scanner are already jpeg and not PNG then uploading the jpeg is the solution, cause saving in PNG wouldn't be of any benefit. However if you have your files in a lossless format like tiff or raw, then convert them to PNG and upload them as such, with a jpeg version to be used in articles, cause jpeg gets more sharpening on mediawiki.--Diaa abdelmoneim (talk) 12:07, 21 July 2009 (UTC)

Thanks for the answer(-s). But this redundance of images sounds crasy for me. The (by far) best solution would be to generate sharpened JPG thumpnails for PNG images. Is this a big problem? What do you think? --PhilipMay (talk) 12:35, 21 July 2009 (UTC)

Another problem is that PNGs over 12MP don't have previews. Sharpening need too much resources for PNGs. The question is whether you have your files in a compressed format or not.--Diaa abdelmoneim (talk) 12:30, 21 July 2009 (UTC)

I have my photos in the Nikon Raw format and I am using Lightroom for post processing. So the solution PNG + JPG should work for me. But this discussion is not only about me - it's about "how it should generally be done". I know that software development is not easy - but I think that my "PNG image to JPG thumpnails" idear should be implemented - if possible. --PhilipMay (talk) 12:35, 21 July 2009 (UTC)

Converting to PNG is the best solution. This would give higher res non compressed files. Then another copy as jpeg. There is a technical problem with your solution. We need more processing power for that. Currently the thumbnails of PNGs are jpeg but over 12million pixels don't have Jpeg thumbnails. Sharpening needs even more processing power. So for the next few years please upload PNG and JPEG files. Oh forgot if it's from your camera then tiff would be better because it preserves the Metadata. So give it a shot and show us what you've got.--Diaa abdelmoneim (talk) 13:57, 21 July 2009 (UTC)

What metadata does tiff retain that png cannot? —Darxus (talk) 16:50, 26 August 2009 (UTC)

(unindent) The Commons is an online image archive mainly. I think it is a mistake to also try to be an archive for high-resolution, print-quality images. If that were made our goal, then over time we would have to greatly expand our server capacity, and accompanying bandwidth, maintenance, and staff expenses. That would only be possible if we allowed optional advertising to pay for it.

I think we should encourage jpg photos for the most part for now, and not extremely large ones that use many megabytes. Only certain historic or other important photos need to be in png, large-version, format.

I also think the Mediawiki software should use jpg thumbs for png photos. The png thumbs are often 50 kilobytes or more. This really slows down page loading for dialup users. A jpg thumb looks exactly the same as a png thumb to most people.

If the Mediawiki software can convert SVG images to png thumbs, then it can convert png images to jpg thumbs. It does not increase server load since the thumbs are cached.

If png photos had jpg thumbs, then I would encourage more uploading of png photos. But not until then. And even then we would not need extremely large versions of photos in order to be a good online image archive. Print-quality images should not be our goal until we have some discussion and consensus about the money needed to support it. --Timeshifter (talk) 08:44, 22 July 2009 (UTC)

SWF and FLA formats

For people working with Flash editors, including many modern artists and animators, their source FLA files and resulting SWF files are the only raw sources for their work, with no obvious conversion path to another format. Moreover, these formats are not encumbered, they don't yet have fully functional free toolchains, but there is a decent free player (Gnash).

Can SWF be accepted? If not, what is the best alternative for artists who want to freely license their work? [I suppose posting to IA and adding an external link.] Is there a place on commons to discuss how to move towards supporting embedded flash or other non-gif animation and interactive formats? +sj + 03:32, 22 July 2009 (UTC)

Commons:Village pump --Timeshifter (talk) 08:09, 22 July 2009 (UTC)

Is flash really an open file format? How well does it convert to svg? —Darxus (talk) 16:53, 26 August 2009 (UTC)

I don't know. See en:Adobe Flash. --Timeshifter (talk) 23:22, 26 August 2009 (UTC)

It's open(ly spec'd, like OpenGL, which is not the same as "free"). The Flash program can export to multiple video and raster formats, including animated GIF; the "conversion path" is as obvious as File > Export (or that plus converting an AVI or MOV, etc. to Ogg/Theora). ¦ Reisio (talk) 07:52, 4 January 2010 (UTC)

remove DjVu because non-open and pratical encoding problems

According to common definitions is not an open file format, see my entry about it in the [DjVu http://en.wikipedia.org/wiki/Talk:DjVu]. In addition there is a practical problem that Free Software encoders are only simple, they cannot produce hight quality files (and the cause are the patented parts). Because of those two problems I suggest to disabllow DjVu as uploading fileformat. Ber-rename (talk) 12:40, 30 April 2010 (UTC)

Originally, it was allowed as a convenient way of including raster scans of multi-page documents, back when PDF files were displayed as uninformative icons (i.e. not previewed). AnonMoos (talk) 14:13, 30 April 2010 (UTC)

How about OpenDocument?

Hi,

I just tried uploading a .ODS-format spreadsheet to include on the Wikipedia:Twin-Lead article, which allows someone to put in various parameters and see what the outcome was on the characteristic impedance... figured it'd be a useful tool, and a sensible place to keep it.

However, .ods isn't an accepted format for whatever reason. I could convert it to PDF or DjVu, but those aren't editable, and the output would not get re-calculated. Perhaps the OpenDocument formats might be worth considering?

Regards, Stuart Longland

Redhatter (talk) 00:48, 26 June 2010 (UTC)

.jpe extension

I was wondering, is there any particular reason why JPEG images with the extension .jpe don't work here? Andros 1337 (talk) 01:12, 29 October 2010 (UTC)

Probably not any very profound or essential reason. However, ".JPE" is a little lame -- ca. 1994, the semi-traditional Unix extension (allowing long filenames) was ".jpeg" while the DOS extension (confined to three letters) was ".JPG"; ".JPE" is neither one nor the other. You can change the uploaded file name to be different from the local disk file name at the last minute in the upload form. AnonMoos (talk) 03:50, 29 October 2010 (UTC)

Blender 3D .blend files

Is there a good reason not to allow .blend files created by Blender? As far as I can tell, there's nothing proprietary about the format. This would be helpful to me because I'm working on a Blender textbook at WikiBooks. --Stepheng3 (talk) 17:17, 8 November 2010 (UTC)

I would like to add my vote to the above. I have been doing some diagrams for the Blender 3D: Noob to Pro book, and while I can upload the finished renders in PNG or JPEG format, I would like to offer up the original .blend files for others to hack on as well. Ldo (talk) 22:51, 13 December 2010 (UTC)

Wikimedia software is probably never going to generate thumbnails for such images, but they might fit in with the "Commons:Restricted uploads" proposal (see below). AnonMoos (talk) 00:24, 14 December 2010 (UTC)

Thumbnails could be added by the uploader as a separe file ? Lionel Allorge (talk) 21:19, 22 December 2010 (UTC)

Meanwhile maybe you can upload your .blend files to blenderstuff.org or to BlendSwap. Lionel Allorge (talk) 21:19, 22 December 2010 (UTC)

jpg thumbnails

JPG thumbnail, slightly sharp?

File:Philips Pattern PM5644.png

PNG thumbnail

Note that currently JPEG thumbnails receive extra sharpening, while PNG thumbnails don't. Hence, uploading in both formats may be a good idea if the PNG thumbnails look a bit blurry.

If this is not the past? Please give a example image for this. For text this is not a solution!? In addition, I think that PNG is now sharper than in the past. -- Perhelion (talk) 19:33, 14 November 2010 (UTC)

Category:Test patterns has a few patterns in both JPG and PNG versions (scroll down), and the JPG thumbnails do look slightly sharpened compared to the PNGs. I have placed two examples to the right, but also compare the related File:Telefunken FuBK.jpg and File:Telefunken FuBK test pattern.svg. I am unsure what you mean by text. -84user (talk) 22:24, 14 November 2010 (UTC)

Lossless Video format missing

There seems to be one kind of media that is missing from the kinds supported here, namely a Lossless video format. I think this is important for archival and derivative making purposes, but unfortunately there does not seem to be such a free format available. On the other hand all the bits necessary are available. One could prescribe a matroska profile (as google is doing with WebM) which would contain FFV1 or HuffYuv video stream and FLAC audio. (probably one would have to implement a bot based 'thumbnailing' service which would produce Ogg/Theora preview clips of the lossless videos) What do you think? How feasible is this? How useful do you think this would be? --Inkwina (talk · contribs) 20:37, 17 November 2010 (UTC)

You do know that lossless video is liable to generate huge files, at any reasonable combination of pixel resolution and frame rate? AnonMoos (talk) 23:21, 17 November 2010 (UTC)

It is true that encoding to lossless video can generate large files, but there are exceptions such as animated illustrations and screen captures which generate "normal" size files. How about offer lossless for advanced users (similar to how TIFF is mainly used by image restorers)? I for one would find it useful, having created a few Lagarith Lossless encodings which otherwise demonstrate annoying artifacts when encoded to Theora. See also my slightly related experiments in Help talk:Converting video#Using GraphEdit to convert Windows Media Video. -84user (talk) 00:04, 18 November 2010 (UTC)

Good luck, but I think that between animated GIF on the low end and OGV on the high end, it's not necessarily widely felt that there's an important gap that needs to be filled between the other two... AnonMoos (talk) 23:52, 29 November 2010 (UTC)

I think there is - animated GIFs are severely limited by the 256 colour restriction (e.g. you can't antialias paths adequately). I think MNG would be a good format to support for the purposes described by 84user. As an aside I'm still pushing for DNG support for raw versions of photographs. Dcoetzee (talk) 00:49, 2 December 2010 (UTC)

However, MNG never really caught on, apparently at least partly because it was squeezed between animated GIF and full-video. The newer option being proposed is APNG. AnonMoos (talk) 01:04, 2 December 2010 (UTC)

Expanding file type support

Our current limitations on file types have the effect that we cannot retain sources for many file formats. This seriously damages the ability of end users to re-use content (e.g. a bitmap of a 3D image is dramatically less useful than a source file that can be rendered and edited in Blender). The primary reason these files aren't consistently supported are security concerns. For this reason, I've proposed Commons:Restricted uploads. The page also lists some possible alternative approaches. I'd appreciate feedback.--Eloquence (talk) 19:54, 29 November 2010 (UTC)

I agree. We need xcfs for coming up with cheaper printing alternatives of the same material. AshLin (talk) 06:17, 21 January 2011 (UTC)

Recommended XCF complete missing

Is lacking any information, with except of that mention. --Perhelion (talk) 20:51, 3 December 2010 (UTC)

XCF is for uploading raw GIMP working files, but the Wikimedia software doesn't generate thumbnails for them (unless something has changed relatively recently). AnonMoos (talk) 00:27, 14 December 2010 (UTC)

Request: Open Document Format for Spreadsheats (*.ods)

For a project I need to upload a *.ods file to Commons, so that it can be edited by a multitude of contributors, on a public domain basis. *.ods is part of the Open Document Format (like *.odt etc.) and is an Open Standard. I would like to ask to enable it for uploading to Commons. The aim of the project is to generate a list of postal codes for a multitude of Cities and Counties, for use in Openstreetmap-based navigation programs, and probably for use on Wikipedia/Mediawiki as well. Thank you, Longbow4u (talk) 10:40, 10 March 2011 (UTC)

Probably more likely to be allowed under "restricted uploads" (see above) than as a basic file type... AnonMoos (talk) 17:36, 10 March 2011 (UTC)

Chemical markup language files missing

For molecules, the 3D form is of great interest (often more than 2D structure plots). I therefore want to add some http://en.wikipedia.org/wiki/Chemical_Markup_Language (CML)-versions of 2D chemical structures. These can be created wit the Open Source and free Software http://en.wikipedia.org/wiki/Avogadro_%28software%29 . My idea is to link the CML files with the 2D structure plots so that people are easily able to open it in Avogadro (or another program) and can see how the molecule looks in reality (3D) and they can even edit it. For example, I created a 3D version of this structure: http://commons.wikimedia.org/wiki/File:Lignin_structure.svg This cost me some time and I want that other can benefit from that work. I therefore need that commons allows files with the extension .cml. --Muso (talk) 00:23, 12 June 2011 (UTC)

Probably more likely to be allowed under "restricted uploads" (see above) than as a basic file type... AnonMoos (talk) 05:54, 12 June 2011 (UTC)

When will the feature be available? The proposal was made more than half a year ago and I cannot find any news regarding this topic. How can I at least vote for this feature? --Muso (talk) 14:42, 12 June 2011 (UTC)

Support for .pdf files

I successfully uploaded a .pdf file, see: File:World Population 2010.pdf. I chose this format because I wanted to retain resolution from a chart I created in Excel. Unfortunately the thumbnail version is very low resolution, and I don’t see .pdf mentioned as a supported commons file format. How nan I learn more about commons support for .pdf? Can you suggest a preferred format for Excel crated graphs? Thanks --Lbeaumont (talk) 15:25, 26 June 2011 (UTC)

PDF files are displayed a whole page at a time (not cropped to a particular region of the page) with JPEG thumbnails. The preferred format here for such charts is SVG... AnonMoos (talk) 17:28, 26 June 2011 (UTC)

I'm also not much informed (seams limited to upright format). You could better ask (for converting) in the COM:GL/ILL. -- Perhelion (talk) 10:10, 27 June 2011 (UTC)

What is a reasonable way to upload a wikiversity pdf fullscreen presentation + source ?

i've started creating a Wikiversity course wikiversity:Special relativity and steps towards general relativity. For people interested in the (plans for) different types of "learning resources" at Wikiversity, see wikiversity:Help:TYPES. In particular, Wikiversity is not supposed to compete with Wikipedia articles or Wikibooks books - see e.g. wikiversity:Help:Article.

The first half of the material for the course consists of:

• original source:
  • latex .tex file (my work), 110kb of text
  • xfig .fig source files (my work), typically 1-2kb of text (tiny!)
  • one-line script (my work) for creating a partial or full screen viewable .pdf file, for a lecture-type live presentation by a teacher
• non-original source:
  • WMCommons image files, mostly .svg, some other formats
  • a few en.Wikipedia static image files
  • one WMCommons animated .gif file
• intermediate files:
  • Commons (+w:) files, mostly converted locally to .eps postscript files
  • .eps files rendered from .fig source files
• final:
  • two pdf files (one for special relativity = SR, one for a few steps towards general relativity = GR)

So my question is, what is the best way to upload the original material and some of the rendered material in a way that makes it relatively wikified - other Wikimedians can edit, check the edit history, discuss on the talk page, etc. - but also not too difficult to recreate the final "usable" pdf files, i.e. what sort of script should i provide and how should it be uploaded? My tentative answers are:

• The .fig files are in principle renderable output as svg, so probably uploading an svg rendered output version + the source .fig text together should be easy - just take a long time because there are many :). Some of them could potentially be used in Wikipedia articles - where they were absent (where i was unhappy with the actual figure, the question of the preferred image to use would have to be discussed on a case-by-case basis at those WP article talk pages). So, upload to Commons?
• The latex source file could be uploaded verbatim as a slightly big text file - 110kb is not so big. So, upload it to Commons as verbatim wiki page content along with the rendered pdf files?
• Uploading the two rendered pdf files to Commons once all the source files are in place should presumably be acceptable on the grounds that it's used in another WMF project, and it's a format that IMHO is optimal for physics/maths type Wikiversity lecture material.
• The script is probably the biggest question. For security reasons, my guess is that a script should certainly not be uploaded as an executable file. The script is presently just a commented-out line in the .tex file, a chain of latex etc commands which can be easily copied/pasted to the command line. However, this assumes that all the image files have been converted to .eps files and placed in (or softlinked to) an appropriate local directory. A minimal script should offer the options of downloading image files from Commons/WP and/or producing .eps files from the .fig files, while not encouraging excessive use of bandwidth (e.g. downloading 40 URLs each time the script is executed without any download delay and repeatedly executing the script after every minor change). My feeling is that what needs to be done in the script is something like the question of a package management system for an operating system, e.g. apt in debian, so it would make sense to have a fairly intelligent, well-developed system and not just a plain shell script. On the other hand, maybe a plain script is enough to get started, and later on a more scalable system could be developed if this approach starts being seriously used in Wikiversity. People interested in improving the package would keep their own copy of a script and comment in/out files that they know have been modified. Each editor would have to be careful not to accidentally include a non-freely licensed image.
• intermediate files: Uploading intermediate files - especially in .eps format - to Commons sounds like a bad idea. On the other hand, reconverting files locally requires some more complexity in the script - i.e. possibly a download plus a conversion rather than just a download. My guess is that these should not be uploaded.

i'd rather get some feedback on this before starting any uploads. Boud (talk) 11:11, 29 June 2011 (UTC) (minor correction: "rendered" was incorrect Boud (talk) 09:29, 6 July 2011 (UTC))

i guess i can follow the User:Nichalp/Upload script example for uploading a script as a subpage. Any more alternative recommendations? Boud (talk) 13:20, 5 July 2011 (UTC)

I am sorry but I find your post rather confusing and way to long (by the way, length of your post is inversely related to how many people will bother to read it). It is unclear if you are wandering about mechanics of uploading large number of files or how to handle different file types. If you are uploading large volume of images I would suggest using Commons:Tools/Commonist before looking into other tools. If you have very large volume (thousands) than a specialized bot might be able to help you, if you ask here. As for file types, you should first read Commons:File types for files supported by commons and other wikimedia projects. The file types you mentioned in your post do not seem to be covered in this list. I would suggest to convert latex to either wiki-text and use directly or change to PDF and upload to commons. I am unfamiliar with xfig but I assume you can export it to SVG. Hope this helps. --Jarekt (talk) 16:37, 5 July 2011 (UTC)

Sorry that you found my post confusing. i stated in the section title and in the first sentence that this relates to a Wikiversity course and linked to it. i guess i assumed that the reader would be familiar with the standard way of producing scientific (physics, astronomy, mathematics) documents, i.e. w:LaTeX, so i didn't think of stating overtly that the final files are produced in a chain from original source files and non-original source files, through intermediate files, out to final files in pdf form. It's somewhat analogous to wiki source text which is output to final html form, but a better analogy is the difference between a .tar.gz software source package and an executable binary created from the .tar.gz file. In the same way that it would be pointless to expect or hope users to edit the binary executable directly, it would be pointless to expect or hope Wikimedians to edit the two final pdf files for the course. Instead, the source files - maybe also intermediate files - should be available for editing, while the final pdf files should be available for people who just want to use them.

Yes, i did read the article which this talk page is attached to before adding my question. I didn't see it answering my overall question.

Regarding your specific responses:

original files - .fig files: It sounds like uploading the output .svg file along with the .fig source as wiki-text source associated with the file would be reasonable, so that people can easily edit the .fig source and then upload the new output .svg file, or alternatively edit the .svg. On a quick test i made, the .svg format file is 3 times the size of the .fig format file, because of all the xml-like tags. Xfig does not seem to import .svg, only export it, but if people edit the .svg version, a discussion of tools to use and preferred format could take place on the wikipage of the file being worked on.

original files - latex/full package/pdf: converting w:LaTeX source to mediawiki-text and then from mediawiki-text to a fullscreen presentation in a browser is an interesting idea. i suspect that the conversion would only be semi-automated - it would probably be easier to write directly in mediawiki-text, using internal and external wikilinks, <math>the math tag</math> for the main content of the what-was-LaTeX-source, and the [[File:filename.fmt|pixel width etc]] way to embed Commons figures (image files). This would need a mediawiki-text to fullscreen presentation convertor, and it seems from this D'Arcy Norman blog post that this 'Wikipedia Presentation' script can be installed for use with greasemonkey, and then be used for viewing a mediawiki-text page as a fullscreen presentation. Some problems: the script seems to be non-free, since no licence is stated, there seem to be some bugs, and it doesn't seem to have been updated for five years.

Do you or anyone know of a free-software mediawiki-text to fullscreen slide presentation converter that is actively maintained? Using a non-free script would defeat the whole point of contributing to WMF projects: we don't want someone to come along later and tell us we can no longer use/modify/redistribute the tools we use.

In any case, in the short term, uploading the latex source + a script (for creating the pdf file from all the source files) as verbatim content in wiki-text that is associated with an uploaded .pdf file is probably the best approach, along with a recommendation that the long-term format might better be mediawiki-text + a free-software converter to fullscreen slide presentation format. As long as the licensing is clear, anyone who has the time to do a conversion will be able to do it.

Boud (talk) 09:29, 6 July 2011 (UTC)

Please add new formats: KML, FLA, ODP & OO2

Please allow uploads of KML, FLA, and OO2 filetypes. --SJ+ 18:04, 9 August 2011 (UTC)

Comment added: https://bugzilla.wikimedia.org/show_bug.cgi?id=2089 --SJ+

What to compile FLA with, and what into? If it can be compiled into a free format accepted at Commons, but not using free software, check Commons:Restricted uploads. --AVRS (talk) 21:15, 9 August 2011 (UTC)

Epub?

What (if any) are the thoughts/plans on adding epub files? Jbarta (talk) 19:07, 14 September 2011 (UTC)

Where are the archives?

The first post on this page is 16 April 2011, and the last post in /Archive 1 is dated 1 October 2008. Where are all the posts in between? — Edokter (talk) — 12:51, 24 December 2011 (UTC)

• Fixed. The new archive page name had been set to “20” instead of “2”, and the link still pointed to “1”. Added a box with links to both pages. --AVRS (talk) 16:02, 25 December 2011 (UTC)

WebM

When is WebM going to be supported? The difference between WebM and Theora is basically the difference between VP3 and VP8. WebM can challenge H.264 whereas Theora can't, and because of that eventually WebM will become the open source standard. "VP8 has a better quality per bit rate than Theora." -Mike Shaver, Mozilla VP Engineering.--Brian Dell (talk) 23:24, 16 April 2011 (UTC)

I second that, although I don't know where to ask for more info. Beuc (talk) 13:19, 2 October 2011 (UTC)

bugzilla:30653 → bugzilla:27699. --AVRS (talk) 14:36, 2 October 2011 (UTC)

+1 - KTucker (talk) 00:22, 11 November 2011 (UTC)

Is there a reason .webm / VP8 are not allowable upload formats? - KTucker (talk) 22:21, 14 January 2012 (UTC)

JPEG 2000 ?

What's the position on JPEG 2000 ?

I'm currently gathering up some engraved images from 19th century books scanned by the Internet Archive, which uses JP2 for its raw scans.

Is JPEG 2000 allowable here, or are there patent problems? (Or software availability problems on some platforms?)

Someone raised this question once before in the talk archives of this page, but didn't appear to receive a very definite answer. Jheald (talk) 17:14, 2 March 2012 (UTC)

I don't know that there are any major stumbling blocks which would prevent it from being used here. However, it doesn't seem to have caught on very widely, and adding it as an accepted format would take Wikimedia developers' time and attention from other issues. If you want to get the format added, you should explain why adding it is a real priority... AnonMoos (talk) 08:16, 3 March 2012 (UTC)

Ogg, .ogg or .ogv video?

Resolved

I have been trying for days to upload a video as .ogv, I will try .ogg extension next. 1024 x 708, 67mb, no sound track.--Canoe1967 (talk) 19:14, 18 March 2012 (UTC)

Was there any error message when you tried with “.ogv”? Note that files can be renamed later. --AVRS (talk)

The blue upload spinner just goes at normal speed for hours, then I get the yellow upload failed triangle. I have the file on a cloud storage server if someone wants to look at it and possibly upload for me. I can fix the PD tag, etc. after you upload.

(deleted url, file removed)

I may try as jpg extension next and have it renamed after upload.--Canoe1967 (talk) 14:59, 19 March 2012 (UTC)

I finally got it to ulpoad. It seems that Handbrake uses Matroska which isn't allowed yet.--Canoe1967 (talk) 16:07, 6 April 2012 (UTC)

Why not WAV files? There's no LOSSLESS format allowed?

It seems crazy WAV files are not allowed. There's this new thing called "Windows". It's an operating system. A lot of people use it. A few people would like to share lossless sound files that work on Windows computers. Ywaz (talk) 13:11, 6 April 2012 (UTC)

It's not free!? -- πϵρήλιο ℗ 13:30, 6 April 2012 (UTC)

1) WAV is proprietary. 2) Lossless audio/video files can get very large very quickly... AnonMoos (talk) 13:34, 6 April 2012 (UTC)

FLAC in Ogg container is supported (do not confuse with FLAC in FLAC container or Ogg/Vorbis). For some reason, the page says FLAC is not supported when referring to the plan of adding .flac → .oga conversion. Somebody please correct this. --AVRS (talk) 07:57, 7 April 2012 (UTC)

FLAC is a free file format (e.g. openly described and free of charge), so you can play FLAC files on Windows, or convert them into WAV, for free. This is a web site, it needs compression: even JPEG is still used! --AVRS (talk) 08:08, 7 April 2012 (UTC)

Oops, I forgot FLACs could be embedded in OGGs for some reason. Need to move a couple files from Commons Archive to here. Dcoetzee (talk) 19:18, 7 April 2012 (UTC)

FLAC failed

This file: File:Alexander Misharin resignation address.ogv doesn't play sound for all browser plugins. I re-converted with vorbis audio and the new file (see other versions) seems to work better. I don't know why, but someone may wish to look into the reason and possibly fix the broken file before it gets deleted. It is far smaller. I couldn't replace it so I had to upload a new one.--Canoe1967 (talk) 14:58, 16 May 2012 (UTC)

That’s because browsers don’t support FLAC. Just do what you would with an image of over 12.5 megapixels. --AVRS (talk) 12:32, 17 May 2012 (UTC)

But note that the smaller file’s picture quality is lower. There is a site for originals in non-free formats somewhere… --AVRS (talk) 12:41, 17 May 2012 (UTC)

In that case should we put a note about using FLAC in uploads because browsers can't hear them? A list of which browsers can hear and which can't may help as well. I think I converted mine from the original .flv link that the uploader provided.--Canoe1967 (talk) 21:38, 17 May 2012 (UTC)

My note.

Quality depends on settings, not just the format. I mentioned Commons Archive because both Theora is (like Vorbis) lossy, so the file could be transcoded later with a better video codec (e.g. WebM, or something that appears in the future) from a stored original. You can also combine the Theora and FLAC tracks in one file, if the worse one is to be deleted.

--AVRS (talk) 14:05, 19 May 2012 (UTC)

Thank you for clarification and the edits to the project page. I am going to wikify the bad file again for deletion. http://amisharin.ru/objects/blog/1336998272Misharin_otstavka_.flv is the original .flv if you would like to look at that format. I think my working version may be of good enough quality to remain for now.--Canoe1967 (talk) 19:38, 19 May 2012 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. --Canoe1967 (talk) 02:18, 13 July 2012 (UTC)

Discussion of PNG thumbnails on Commons:File types page

New PNG thumbnailing software, supposedly better than the old software, has been installed since that passage was written... AnonMoos (talk) 00:11, 13 July 2012 (UTC)

Feel free to re-word it if you wish. If it is reverted then edit war over it until all involved are blocked. After the blocks expire then seek consensus. I think that is normal commons procedure.--Canoe1967 (talk) 02:15, 13 July 2012 (UTC)

If I felt confident that I understood the relevant implications of the software change, then I would have reworded already... AnonMoos (talk) 03:29, 13 July 2012 (UTC)

I added a possibly out-dated note for now.--Canoe1967 (talk) 04:50, 13 July 2012 (UTC)

Support for Ogg Opus audio files (*.opus)

Probably someone should open a feature request in the bug tracker for this. I'm not sure whether it is sensible to wait for some official browser support in order to be able to use it with support for inline playback right from the start..?
In any case, I want to create some first awareness for the format since noone here seems to be talking about it yet.

Opus is the upcoming IETF internet standard for lossy audio. In terms of audio quality it is already better than practically any other codec in use today and has probably an unparalleled set of useful features. It is a better replacement for both (Ogg)Vorbis and Speex. (And of course everything is free software, open standard, royalty free and all.)
Perspectives for widespread support are good, likely much better than with Vorbis that never made it to something as official as an IETF RFC. Support is already there in Firefox 15 beta (final release in August) and other software based on Gecko version >15 and support in other applications is growing fast.
The final format specification and version 1.0 of the reference software are going to be released in the next few weeks. It is finished and ready for use right now though; it is basically just waiting to get its RFC number. So maybe we can have it supported at official primetime...--Flugaal (talk) 23:33, 21 July 2012 (UTC)

GIF animation clamping

It should be mentioned that GIF animation may be "clamped" in certain browsers (>20 FPS if IE and >100 FPS in Firefox). See WebKit bug 26455 for details. Dispenser (talk) 21:58, 11 September 2012 (UTC)

Support of WebM files

Hello.

When the support of WebM files will be available ? --ComputerHotline (talk) 09:47, 16 May 2012 (UTC)

WebM support, as indicated in COM:WEBM, is tied to the deployment of the mw:TimedMediaHandler extension. You can see the status updates on this page. Jean-Fred (talk) 12:34, 16 May 2012 (UTC)

Now added :) --SJ+ 02:16, 15 December 2012 (UTC)

OpenDocument for wikibooks

I know it has been requested before but not with this particular reason. I need to upload some kind of editable document file for "my" wikibook (In Swedish: http://sv.wikibooks.org/wiki/Matematik_f%C3%B6r_%C3%A5rskurs_7-9/). More specifically ods-files as examles (as it is a math book) and some kind of editable odt document. If a specific file is just to be read or printed then I could just use a normal page or a pdf but if I am to make something that the reader can download and start to edit (such as a work sheets) then those formats wont do and odt would be good. If I also do make some odp files that I would like to share to be used by other teachers then that format might be needed too. I hope someone could help me raise this question or give me some alternate solution. Averater (talk) 12:03, 10 November 2012 (UTC)

Found this: https://bugzilla.wikimedia.org/show_bug.cgi?id=2089 . It seems the same reason has been raised before (since 2005!). But I still need help finding a good solution of how to add these kind of files to my wikibook. Averater (talk) 12:16, 10 November 2012 (UTC)

Maybe you could use http://commonsarchive.org/wiki/Main_Page as an alternative. --McZusatz (talk) 12:25, 10 November 2012 (UTC)

"hard limit of 12.5 megapixels" for PNG and GIF

This was actually raised a few months back (though not for animated GIFs?)... AnonMoos (talk) 07:21, 18 December 2012 (UTC)

File:Test.animation.25MP.gif

25MP animated gif

Worksforme?! --McZusatz (talk) 11:26, 18 December 2012 (UTC)

Compression

Regarding compression for PDF files: I'm thinking about uploading rather big files of book scans in PDF format, not for viewing but for downloading. It would be ressource saving on both ends to have them compressed (e.g. GZIP-Format). Is this ok & if not, where is the problem? --WolfgangRieger (talk) 16:32, 28 February 2013 (UTC)

Gzip is not allowed because you can basically put everything into it. (Viruses as well) --McZusatz (talk) 18:12, 28 February 2013 (UTC)

Does not compute ... The contents could easily be checked for allowed file types only. BTW, PDFs can also have harmful content. --WolfgangRieger (talk) 19:20, 28 February 2013 (UTC)

Also files should be able to be embedded into articles directly. .gz wont allow thumbnails. --McZusatz (talk) 23:09, 28 February 2013 (UTC)

WolfgangRieger -- since PDF version 1.2, PDF can have internal "Flate" compression, which is the same algorithm as used in gzip. Also, in many cases, the content of HTTP messages delivered across the Internet can be gzipped and gunzipped on the fly... AnonMoos (talk) 02:57, 1 March 2013 (UTC)

Sorry, I was not thinking. The contained image data of the scans is already compressed and there would be no big saving. Silly me. --WolfgangRieger (talk) 09:41, 1 March 2013 (UTC)

Any priority for Google Summer of Code projects?

The Wikimedia Foundation is planning to participate again at Google Summer of Code. There is a discussion about proposing projects to support x3d or KML in Commons. What about having a catch-all entry for unsupported file types in Commons/MediaWiki? We could explicitly point to KML, x3d and link to the full list here. Are there other formats that we should highlight to potential GSOC students? Also if you want to volunteer as mentor that would be great.--Qgil (talk) 14:50, 26 March 2013 (UTC)

See COM:UNSUPPORTED and its companion bug bugzilla:42725 − all formats there have been discussed before (I can try to dig the Village Pump discussions if needed).

I think there is a strong case for Raw image format (DNG) − bugzilla:19153 ; and I suppose Wikisource folks might be super interested in a ePub format − better check with them first if it is still needed.

Jean-Fred (talk) 14:56, 26 March 2013 (UTC)

Ah, I misread your post − I thought you meant a catch all entry here or on bugzilla, not for the GSOC. Sory for the confusion. Jean-Fred (talk) 10:48, 29 March 2013 (UTC)

VP8 now patent encumbered

Press release

Now Google has licensed for MPEG LA patents for their use in VP8 it's no longer free in the sense of being unencumbered by patents. It's still royalty free, though the precise license terms for sublicensees are unavailable: [2]. But that's the same as h.264 which is free for non-commercial use, but not used here because of patents. It may be subject to further licensing requirements, or even be banned, as Nokia are suing HTC over VP8 in Europe:[3][4].

The question is does anything need to be done about this? I would prefer it if the policy were able to support patent encumbered but free formats, especially h.264. But if that's not possible then should the use of VP8 be re-examined? --JohnBlackburne (talk) 20:19, 7 April 2013 (UTC)

It seems that encumbrance hasn't been confirmed yet? Check w:JPEG#Patent_issues. If you have FUD, you can keep the originals and upload also Theora versions.

Free for noncommercial use is not enough.

--AVRS (talk) 09:07, 8 April 2013 (UTC)

At least we should wait until "We anticipate having the terms of our sublicense ready in the next few weeks. When those terms are ready we will blog about them here, so watch this space." [Quote from 1] --McZusatz (talk) 18:22, 8 April 2013 (UTC)

Here's what looks like a draft agreement: [5]. Not sure when it went up as it's undated and I've just noticed it. There's also a FAQ [6]. Quite interesting and unlike typical open source licenses.--JohnBlackburne (talk) 22:40, 2 May 2013 (UTC)

SWF not generatable with free tools?

This is incorrect: there's Flex. This was created by Adobe, initially as a paid product but for most of its life as an Adobe product it was free. But recently Adobe handed it to Apache, and it is now available from them under the Apache License [7]. Flex being command line is not everyone's first choice for making Flash/SWF/AIR content but that's a user preference, not a limitation of the software which supports all Flash/SWF/AIR features.--JohnBlackburne (talk) 19:01, 18 September 2013 (UTC)

I didn't say it is not generatable at all. I mean not all SWF files are playable with free software; not sure about generation. --AVRS (talk) 19:25, 18 September 2013 (UTC)

Is it recommended to convert TIFF files to PNG?

My understanding is that they're both lossless, so a conversion should be lossless as well, right? If PNG is preferred over TIFF, then would it make sense to recommend conversion in the guideline? Curly Turkey (talk) 21:47, 14 December 2013 (UTC)

TIFF files can contain metadata and multipage documents. If none of this applies to the files, PNG is preferred. --McZusatz (talk) 22:52, 14 December 2013 (UTC)

PNG can also have much of the metadata that Tiff files can. The lossless compression algorithm used by PNGs often results in smaller sizes then the compression (or lack thereof) often used by Tiff files. On the other hand tiff is favoured by some archive folks, and they have tools that work with tiff (I guess). When you upload a tiff file to commons the thumbnails are pngs, so might as well just keep the format the same as whatever format the file is originally in. Bawolff (talk) 05:30, 16 January 2014 (UTC)

No, thumbnails are not displayed as PNGs. They are displayed as JPEGs. I checked. And that's actually the reason I say you shouldn't change them. TIFFs allow us to do something PNGs don't, having a lossless archive copy while using allowing lossy compression for download. For photographs, the difference is extremely large.

One thing you can do, though (assuming the file isn't mirroring some other file) is optimize the compression. There seem to be a lot of TIFFs that are completely uncompressed. I wouldn't do this for no reason, but if you are editing the file, I don't see any reason why you shouldn't. I personally recommend running the edited file through FileOptimizer before uploading. (To keep the metadata, make sure keep metadata is enabled in the JPEG tab of the options.) Trlkly (talk) 17:42, 16 January 2014 (UTC)

Sorry you're right, not sure what I was thinking. Default is JPEG. It is actually possible to request a png thumbnail using the lossy=0 parameter. ::::Compare:

vs .

Bawolff (talk) 22:51, 16 January 2014 (UTC)

Too bad that doesn't work for other types of files. It'd be fun to use lossy=1 to make a large PNG render as a JPEG. Trlkly (talk) 01:30, 11 March 2014 (UTC)

{{Compressed version}} apparently doesn't care about the achive format, you could use it also for lossy JPEG thumbnails of PNG images. BTW, I "think" (please correct me) that TIFF compression can be lossy (and actually permits JPEG), that could be a very bad idea for {{LargeTIFF}} or similar archived versions. –Be..anyone (talk) 12:10, 11 March 2014 (UTC)

RFC to Allow MP4

Just a heads up, there's a discussion at Commons:Requests_for_comment/MP4_Video to allow MP4 video (A patented format that is currently disallowed on that basis) on Wikimedia. Its a complex issue (in my opinion anyways), and I encourage everyone to read the RFC and comment about how they feel. Bawolff (talk) 05:22, 16 January 2014 (UTC)

Support for OpenDocument file format upload

OpenDocument Tracked in Phabricator Task T4089

Spreadsheets Tracked in Phabricator Task T45151

Please see Commons:Village_pump/Proposals#Support_for_OpenDocument_file_format_upload. Jean-Fred (talk) 14:08, 6 July 2014 (UTC)

Unarchived and tracking added. The proposal is kept in the 2014-07 VPP archive, closed as no consensus. –Be..anyone (talk) 21:39, 28 February 2015 (UTC)

No easy way for playing MIDI files on Mac OS X

On Mac OS X 10.8+, there is no easy way for playing MIDI files in the browser since Quicktime support for MIDI files was dropped. MIDI files can be played using GarageBand, TiMidity++ or the legacy QuickTime 7. There is a hackish way for making your own browser plug-in from an 10.6 or 10.7 QuickTime [8] that involves using an outdated legacy plugin (really a very serious security issue). VLC for Mac cannot play MIDI files either, but there may be a way of building your own VLC FluidSynth plug-in [9].

The current project page says that MIDI files are “not very well supported”. May I suggest adding a sterner warning detailing that Mac OS X no longer supports MIDI? -- j. 'mach' wust | ✍ 14:44, 4 April 2015 (UTC)

They're supported among musicians. I'm not sure that the issues that you raise will have much to do with MIDI files being allowed on Commons, since MIDI is the quasi-standard compact instructions-based music format, without significant competition in that role (certainly among free file formats). The difference between MIDI and waveform audio is like the difference between a player-piano roll and a CD -- or more abstractly, like the difference between a vector SVG image file and a JPEG... AnonMoos (talk) 22:25, 4 April 2015 (UTC)

I did not want to question the benefits of MIDI. I would only suggest that we more strongly advise against using MIDI files, seeing users of a major OS will not be able to use those files unless they manually install third-party software. And there is no browser plugin, so the files have to be downloaded. That is quite different from OGG files: You can just click on them and they will play, right there in the browser. You don’t have to download anything, let alone install third-party software.

But of course, the page already discourages using MIDI files and recommends OGG. 77.56.74.82 18:43, 5 April 2015 (UTC)

MP3 now usable?

With the expiration of U.S. Patent 5,812,672 on 2015-Sept-22 see: MP3 – Licensing, ownership and legislation is MP3 now patent free and can it be used on Wikimedia? Other US patents commonly claimed as MP3 patents such as PATENT 6185539 and PATENT 6009399 were filed in 1997, which is well after the MP3 standard came out (ISO/IEC 11172-3:1993 came out in 1993). Since the standard came out in 1993, countries where patents can at most last 20 years after publication are also safe for MP3. Jrincayc (talk) 02:57, 14 October 2015 (UTC)

Hello. Please ask Commons:Village_pump/Copyright Jrincayc--Pierpao.lo (listening) 06:10, 13 April 2016 (UTC)

I've moved MP3 from non-free to requested (phab:T120288, phab:T115170). Apparently talking about 2017. –Be..anyone 💩 02:59, 26 April 2016 (UTC)

WebP

Tracked in Phabricator
Task T27397

phab:T50519 was closed as resolved mumbling something about MediaWiki 1.26. We are at 1.27, but my VP8L test upload failed immediately, "WEBP not supported". What's the problem? –Be..anyone 💩 11:33, 12 April 2016 (UTC)

It would probably be better to ask the question someplace where MediaWiki developers hang out (this page is not one of those places)... AnonMoos (talk) 13:59, 12 April 2016 (UTC)

Yeah, but the task number on the project page below COM:UNSUPPORTED is now wrong for WebP. –Be..anyone 💩 21:41, 12 April 2016 (UTC)

Support request on MediaWikiWiki. –Be..anyone 💩 10:54, 24 April 2016 (UTC)

phab:T27397 found by Ciencia Al Poder.

Lutar, crear
poder popular

–Be..anyone 💩 18:00, 24 April 2016 (UTC)

Thumbnails and JPG, PNG etc.

Professional photographer User:Katy Blackwood raises an excellent point on her user page and in a personal template, that JPG files tend to be oversharpened by the thumbnail engine, yielding artefacts that lower the quality of sharp images (which is damaging to professionals whose career depends on such details). User:Adam Cuerden has raised that issue during his talk at Wikimania 2016 as well, so the issue is quite widely known. It might be opportune to mention this in the guidelines, so that interested authors could know the workaround and other users understand the reason for the unJPEGness of some files and refrain from uploading JPEG versions. Rama (talk) 10:58, 27 June 2016 (UTC)

I'll be honest - I think we need some sharpening, as ImageMagic tends to produce a blurry thumbnail. But how much it should be sharpened.... I think we're probably on the high side, at the least. PNG is too little, JPEG, a little too much for anything that's not made up of distinct lines. We should NOT suggest workarounds, though; we should fix the problem by tweaking defaults and allowing the sharpening factor to be set for individual images (if possible). Adam Cuerden (talk) 16:02, 27 June 2016 (UTC)

Supporting .stl

Hi

Can someone tell me if .stl is a free file format? I can't work it out. The filetyype was created in 1988 so will it run out of legal protection soon and then become an free file type?

Thanks

--John Cummings (talk) 10:02, 17 August 2016 (UTC)

Split advice in 'Images' section into new sections 'Photographs' and 'Scans and non-photographic images'

The section headed 'Images' tries to do too much. It would be better if the section was split into two new sections 'Photographs' for still photographs and 'Scans and non-photographic images' for diagrams, screenshots, and scans of prints and slides. That would make it much easier for users to find the information they need and would allow the advice to be better resolved and tailored. Any comments? Best wishes. RobbieIanMorrison (talk) 11:00, 6 February 2017 (UTC)

Archival format for digital photographs

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 2.9.4.1) 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. This post covers digital photographs and not scanned prints and slides. Some points to take into consideration follow:

TIFF

GIMP 2.8 will not transfer metadata from the RAW file to the exported TIFF file. 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:

• 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

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:

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. 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

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)  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. 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. 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". 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. PNG is a better choice if lossless compression is required. But generally the authors recommend that you choose JPG over RAW for circulating files. And for long-term storage, the authors strongly prefer JPG or XCF. RobbieIanMorrison (talk) 19:08, 5 March 2017 (UTC)

References

WebP support

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

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

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:

• Template talk:BadJPEG#This template is 14 years out of date. GIF also does not have compression artifacts, and has been out of patent since 2003

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

• Commons:Chart and graph resources

--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

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)

Update audio codec recommendations

According to en:Opus (audio format), the Opus codec is an effective replacement for both Speex (obsoleted by Xiph.Org) and Vorbis. Since MediaWiki supports .opus files, should this be our recommended format for general audio files over Vorbis? Opus is arguably better in every respect, but Vorbis has been around longer and has more support from operating systems and browsers (though the same can be said for mp3 vs ogg). clpo13_(talk) 20:29, 2 January 2019 (UTC)

@Multichill: and others:

What's the status of rules and preferences on Wikimedia Commons regarding files in the MP3 format?

In particular is the advice on this page still current, that "As of December 2017, Commons only accepts MP3 uploads by admins, image reviewers, and extended uploaders due to concerns about the capacity of the community to monitor for copyright violations"?

I ask in part because the Commons article on Commons:Extended uploaders begins with, "This page is presently inactive and retained primarily for historical interest. Extended uploader has been discontinued per community consensus and all user rights have been granted to both the autopatroller and the patroller groups."

This may be a distinction without a difference, because this is the first I've heard of "Extended uploaders", "autopatroller" and "patroller" groups, in spite of having a "Global edit count" exceeding 8,000 since 2010-03-26 including 267 on Commons.

More specifically,

• I hope to attract people affiliated with the Grassroots Radio Coalition to use Wikiversity to collaborate on producing training materials shared between listener-sponsored radio station members of the Grassroots Radio Coalition,
• MP3 is the only audio format that I've used at KKFI, a listener-sponsored radio station in Kansas City,
• I'd like to be able to encourage people to upload material in MP3 format to Wikimedia Commons if that's feasible, and
• the Wikiversity article on v:Audacity says, "Wikiversity only uploads OGG files. Attempts to upload other file formats gets a very vague error message so you must use a program like Audacity to do the conversion."

Comments? Thanks, DavidMCEddy (talk) 12:29, 3 September 2019 (UTC)

For all supported forms of lossy audio, the original format is the best one to upload, never convert if at all possible. This goes equally for MP3 as Vorbis. As Opus is the clear technical winner of not just the free format war, but all lossy formats at this point, I would say that's easily the first choice for original compression unless there's a specific constraint; it's been in all current browsers for years. (Heck, Edge supported Opus before it supported Vorbis.) When the original isn't in a supported format, it's a judgement call whether to convert to FLAC or to a supported lossy format. Same if you can't upload the original MP3 because it's too much hassle to get the rights, though at least then you can ask someone else to do so. As for Wikiversity, it intentionally allows a very constrained subset of formats that the rest of Wikimedia supports. SilverbackNet^talk 17:58, 17 October 2019 (UTC)

Image use instructions

The section "Animated GIF" now says that "inline animations should be used sparingly". This seems odd. The rest of the page is about uploading, not use. Is this about use in galleries, policy pages or what? I suppose it is a guideline of some Wikipedia, which for some reason has been repeated (or written) here. In that case I suppose the paragraph should be removed. If the reason is some other, one should explain what use this is about. --LPfi (talk) 15:38, 6 June 2019 (UTC)

@LPfi: I use 3 animated gif files on my user page: File:Qxz-ad2.gif; File:Movicons2-hello.gif; and File:Welcomebanner.gif. The latter 2 have been there for 9 years. Is that wrong?   — Jeff G. ツ _{please ping or talk to me} 16:01, 6 June 2019 (UTC)

I think they (at least the one I spotted) make reading the adjacent text significantly harder, so I think the "niceness" value should be given less weight than the accessibility issue. I would however give significant leeway for designing user pages. If this is a significant problem, the guideline about user pages should note it. The issues are different on different pages, and users adding content to pages are probably not coming here for advice, so if we want to keep the paragraph, there should be links to here and the paragraph should include a discussion presenting the issues. --LPfi (talk) 09:09, 7 June 2019 (UTC)

@LPfi: I added alt text to my uses in these edits.   — Jeff G. ツ _{please ping or talk to me} 17:18, 7 June 2019 (UTC)

The issue is that something that moves or changes shape distracts from the reading. I have to make an effort to concentrate on the text, which I wouldn't need otherwise. With my former web browser it was easy to turn off such animations (still two or three clicks before reading instead of just reading), but on this I do not know an easy way to do it. With fvwm it is easy to move some other element (the clock, an xterm, ...) over the disturbing image, but e.g. windows insists the active window being on top. I suppose some users will have real difficulties reading the text, but as this is not Wikipedia, they can just skip reading with not much harm done. --LPfi (talk) 15:38, 9 June 2019 (UTC)

Permit uploading fonts

Hello,

have you ever thought about permitting users to upload fonts to commons? This would permit people such as myself who ardently write wikibooks to gain greater control over the typesetting of their scribbles. --Mathmensch (talk) 13:06, 22 February 2020 (UTC)

Hi Mathmensch, I am not sure if the existing Webfonts would fit your needs? They can be used on Wikibooks too. For a complete list of existing Webfonts with examples see de:Hilfe:Schriftunterstützung/Webfonts. If you need other fonts the fonts could by uploaded to the WMF server via a software patch. The font must be licensed under a free license. Raymond 15:49, 22 February 2020 (UTC)

Hello Raymond, thank you very much indeed. This is exactly what I was looking for. --Mathmensch (talk) 09:36, 23 February 2020 (UTC)

Use of 16-bit tif format to preserve depth of colors

I think this discussion is relevant here: Commons talk:Quality images candidates#Use of 16-bit tif format to preserve depth of colors --Trougnouf (talk) 14:49, 4 December 2020 (UTC)

Guidance on pdf vs svg

Inkscape has become significantly better at converting PDFs, and rsvg significantly better at rendering them. But this page, which should provide guidance, just notes that yes, SVG is good and PDF is also good for vector files. Is there any kind of consensus on how strongly to prefer SVG over the original file? Or always upload original PDF even if it's less accessible? SilverbackNet^talk 18:25, 17 October 2019 (UTC)

PDF's strength is stuff laid out on a certain-sized page in multi-page documents. If you have a single vector graphic which is not tied to the layout of a particular page, then SVG would generally be preferable. AnonMoos (talk) 10:46, 9 December 2020 (UTC)

To add on AnonMoos, the thumbnails of the PDFs uploaded here are in JPEG, so even if the image is vector, when rendered as a JPEG thumbnail, it could look bad. This is not the case with SVG, whose thumbnails are rendered as lossless PNGs instead. SVG is designed for web publishing anyway, unlike PDF, so you should always use SVG when publishing graphics to the web. pandakekok9 13:56, 9 December 2020 (UTC)

I need "permission" to upload files

Hi I need permission to upload these files: Quran recited by Maher I want to save them in this category: Category:Qur'an recited by Maher Al-Mueaqly. If "I'm not allowed to do it", can someone do it for me? Thank you. --El Mono Español (talk) 16:11, 27 January 2021 (UTC)

@El Mono Español: You need permission from Maher himself, as the recording has its own separate copyright. pandakekok9 04:57, 28 January 2021 (UTC)

@Pandakekok9: I don't think so, since the are other audio files from him without his permission. For example: File:Surah Al-Baqara (002) Maher.ogg - File:Surah Al-Baqara (002) Maher.ogg--El Mono Español (talk) 23:13, 28 January 2021 (UTC)

@El Mono Español: Interesting. I can't see proof though that Maher released his recordings to the public domain. I'm going to ask Ahm masum where he got the CC0 from, as I doubt that Wikimedia chapter members would just upload files without permission. pandakekok9 03:31, 29 January 2021 (UTC)

Thank you. Let me know when it's cleared up and I'll upload the rest of Maher's work. Grretings--El Mono Español (talk) 12:46, 29 January 2021 (UTC)

MP3

Well we see the words MP3 and then we go convert our files -- only later do we notice that way below it says something else. Therefore at the first time you say MP3 you better add an asterisk. Thanks. Jidanni (talk) 04:12, 1 February 2021 (UTC)

@Jidanni: Does this make it better? pandakekok9 04:21, 1 February 2021 (UTC)

Better, yes, but not good. Why is MP3 said to be "highly recommended" in the first place? –LPfi (talk) 12:36, 1 February 2021 (UTC)

OGA 10 times bigger

Okay, I converted my AMR to OGA_ 10 times bigger file size. But that's the recommended free format ... Jidanni (talk) 04:22, 1 February 2021 (UTC)

@Jidanni: You should use the Opus codec, and set the bitrate to 64kbps. If it's too compressed, then try 96kbps. Vorbis and MP3 are essentially made obsolete by Opus. pandakekok9 05:15, 1 February 2021 (UTC)

You also used FLAC, which is lossless, instead of a lossy format. So it obviously would make the already lossy compressed audio bigger. pandakekok9 05:19, 1 February 2021 (UTC)

Data file guidelines?

Do we have any policies or guidelines on use of the data namespace? Now Commons:File types#Data files just refers to the MediaWiki help pages, which say little about how they are to be described and categorised here. –LPfi (talk) 12:41, 6 March 2021 (UTC)

@LPfi: Categorization is not allowed. Neither is normal attempted deletion. :(   — Jeff G. ツ _{please ping or talk to me} 09:27, 22 March 2021 (UTC)

I noticed when I tried to add a category. But where is our guideline and help page? Or rather: Why is there none? –LPfi (talk) 09:31, 22 March 2021 (UTC)

@LPfi: Those are good questions, I wish I had answers to them.   — Jeff G. ツ _{please ping or talk to me} 02:48, 23 March 2021 (UTC)

Proposal: Commons adopts EPUB file format for book uploads

I am seeking signatures of support for Wikimedia Commons to adopt the EPUB format as an acceptable file type for Commons files. Please comment below with support or to identify barriers to adoption.

EPUB is a popular format for reading books. It is one of the top recommended formats of the Internet Archive, which is a major Wikimedia partner for accessing books. It is free and open, and previous review has suggested that anyone could make it an accepted format for upload in Wikimedia Commons.

About EPUB

• en:EPUB
• EPUB (Q475488)
• w3c documentation on EPUB
• w3c documentation comparing book formats

Wikimedia Commons documentation talking about file formats

• Commons:Project scope
• Commons:Project scope/Allowable file types
• mw:Manual:Adding support for new filetypes

previous discussion mentioning EPUB in Commons

Tracked in Phabricator
Task T19858

• Epub? Jbarta 2011
• ePub files on commons? AnonMoos 2010
• DjVu is dead. We should deprecate it for new uploads. Snaevar, many others 2019
• Tech News April 2019

questions

• Is anyone aware of additional previous Wikimedia discussions about this? Can you link to them or describe where you remember them?
• Can anyone identify any legal barriers or aspect of non-freeness in this format? It seems open, but it is wise to check.
• Does anyone have knowledge or opinions about the relative popularity of this format in comparison to others for books? Are there numbers anywhere about the relative use of available book formats? It would be helpful to demonstrate that EPUB is in use or otherwise confirm that the numbers are not available to consider.

next steps

There are technical difficulties in adopting a new file format and probably the path to getting this format adopted includes a request to technical staff at the Wikimedia Foundation. Before beginning that process, discussions like this one confirm that there is social acceptance of and support for the idea. This could take years to get in the work queue but let's see what others think. It is essential that we get comment from Wikisource which would probably be the most affected project since those editors work with texts, but as files are hosted in Commons, I thought I would ask here first.

1.  Support Blue Rasberry (talk) 15:04, 25 March 2021 (UTC)
2.  Support.   — Jeff G. ツ _{please ping or talk to me} 04:08, 13 May 2021 (UTC)
3. your signature here

Proposal for JP2 / JPEG 2000

• Commons:Village_pump/Proposals#Commons_should_support_JP2_file_format

Blue Rasberry (talk) 16:06, 6 April 2021 (UTC)

MPEG listed in both accepted and non accepted

MPEG is listed in both accepted and non accepted. Or is one talking about version one and one talking about version 2 or what? Be extra clear. Jidanni (talk) 02:48, 13 May 2021 (UTC)

ABC notation

MIDI files from GNU lilypond are accepted. There is an argument to accept ABC notation files. ABC music is human readable. Whilst lilypond files can be created with text input, the format is less intuitive.Tradimus (talk) 14:46, 10 August 2021 (UTC)

Ogg preferred over MP3?

Currently is says that MP3 files should only be uploaded "if an ogg or lossless version can't be found." I don't see any reason why we should prefer Ogg over MP3 now that MP3's patents have all expired. MP3 is playable on a much wider variety of devices, especially on mobile, and the quality range is comparable. Yes, Ogg might have slightly more efficient compression, but it's a tiny difference and we aren't worried about storage capacity for audio. I would like to propose that the above wording in quotation marks be deleted from the sentence. Nosferattus (talk) 17:49, 20 August 2021 (UTC)

I disagree. ogg's Vorbis and Opus are both superior in quality compared to MP3. And we already automatically convert oggs into mp3 anyway. MP3 should only be a last resort. pandakekok9 03:30, 21 August 2021 (UTC)

PDF format missing

Hi, PDF file type is missing in the "Permitted file types" in Special:Upload. Yann (talk) 14:47, 6 October 2021 (UTC)