Commons talk:File types/Archive 1

To add

I'd like to see a complete list of file extensions allowed here. The list is in the MediaWiki configuration file; I imagine it takes shell access to read it. dbenbenn | talk 30 June 2005 01:55 (UTC)

GIF doesn't match colors exactly, since it's limited to 256. - Omegatron June 30, 2005 03:32 (UTC)

No MP3 is hurting us

Hi there, I'm a member of the Audio Wikinews subproject on the Wikinews project, and I have a request to allow MP3 files to be uploaded. We're aware that Vorbis is a superior format compared to MP3, however the lack of popularity of Vorbis has forced our project to be taking a blow away from the potential it could have. I've just recently started a podcast-formatted RSS feed for our deliveries, however due to the nature of Vorbis and the lack of players that support the format - we are unable to reach a large audiance. Our hopes would be to have our news program listed on the popular iTunes directory of podcasts, however we cannot do this without Commons supporting MP3 as a file format. --Mrmiscellanious 17:34, 20 July 2005 (UTC)

personally i think we should encourage uploads in wav or flac to preserve full quality and avoid transcoding issues. possiblly with other formats as well. unfortunately converting from flac to other formats is probablly too cpu intensive to do on the server side and there would also be patent issues with us running a mp3 encoder there. (btw does anyone know how free AAC is?) what do others think? Plugwash 18:27, 20 July 2005 (UTC)

• AAC is also proprietary. We basically need MP3, WAV or FLAC would be a little hard for me to upload on this thin pipe. --Mrmiscellanious 21:41, 20 July 2005 (UTC)

• But we can easily recommend audio players that play OGG (assuming we don't already). Almost every open-source media player that I know of supports the format, so there's no reason why it shouldn't be accessible to everyone. The fact that Windows Media Player and iTunes don't support OGG Vorbis shouldn't force us to cater to the lowest common denominator. --Ardonik 18:14, 24 July 2005 (UTC)

The phrase "lowest common denominator" is misdirection, this is media, and as such putting that media in a format most usable should be the goal. Why make audio at all, why cater to the "lowest common denominator", when the content is freely available as text. The decision comes down to this, do you want to help people by making information available to them, or do you want to congratulate yourself for license purity? Also, to address the point directly, he's trying to make a podcast, which is a way of "distributing audio content for mobile devices", so the functionality of software players is not relevant. - cohesion 05:22, 2 January 2006 (UTC)

There are some hardware-"mp3-players" who play Ogg Vorbis. Not so easy to find and mostly not cheap. ( see PortablePlayers) But there is one mainstream player; the Samsung Yepp players. --Walter 08:41, 26 July 2005 (UTC)

---

I usually subscribe some podcasts. I download them and play them on my Muvo pocket mp3 player. Can't play ogg on muvo. We should learn a litle about podcasts. It would help on this file format issue. --OsvaldoGago 18:54, 24 July 2005 (UTC)

Jimbo has decreed on wikitech-l that we can't allow "file formats that can not be used by legal free software". So no, we can't host MP3 or AAC. dbenbenn | talk 07:14, 24 July 2005 (UTC)

Indeed. Quite frankly, the answer to the complaint is "tough". Sorry, but it's not our doing. If you care more about producing "mostly free" than "completely free", Wikimedia may not be the organisation for you. :-(

James F. (talk) 23:34, 25 July 2005 (UTC)

Maybe you should write to the Muvo people and ask them to add OGG support. If enough people do, maybe they will support OGG in the future. -- Duesentrieb 10:01, 26 July 2005 (UTC)

Or just convert the files. How hard is that? - Omegatron 17:52, 26 July 2005 (UTC)

It's impossible if you have objections to massive data loss. These are lossy compression formats. Someday the patents will expire, but the original data will be long gone. See my "proposal for original data" below. AlbertCahalan 21:48, 8 April 2006 (UTC)

---

Audacity is a free Open Source program (GNU-GPL) who imports and exports mp3. If having mp3 format on the commons isn´t ilegal, we should have mp3.--OsvaldoGago 17:18, 2 August 2005 (UTC)

Patents are national, not international. Wikimedia Commons is hosted in the United States, which recognizes software patents. But a lot of the Audacity developers aren't in the United States. Have software patents been ruled valid in Europe? --Damian Yerrick 18:11, 12 November 2005 (UTC)

I think there are international patents on MP3. Anyway, there are plenty of open source programs for dealing with MP3; w:LAME is, according to Wikipedia, probably the best. Apparently the idea is that the LAME source code is legal, as a "description of patented technology". But if you compile the code, you're breaking the law. Anyway, Jimbo decided we're going to go with OGG, so that's just how it is. User:dbenbenn 23:22, 25 December 2005 (UTC)

"Have software patents been ruled valid in Europe" last i checked the EPO (which is independent of the EU) was issuing them but most (all?) EU countries courts were saying they were invalid. The EPO is trying to push through an EU directive to make them valid accross the EU but i don't think they have succeeded yet. Plugwash 22:27, 7 July 2006 (UTC)

do not allow OpenOffice file format

OpenOffice is now whit version 2.0 changing its default file format from ther own to a new standard. It makes more sence to use the new "Open Document Format for Office Applications Version 1.0" and not the old OpenOffice "classic" file formats --Walter 09:10, 26 July 2005 (UTC)

+1

Other two reasons to use the new Open Document Format (please follow the link):

• Also the "old" Openoffice 1.x supports Open Document Format
• Most word processor and spreadsheet(except Microsoft office) (will) support Open Document Format. See w:List_of_applications_supporting_OpenDocument --Qualc1 20:34, 27 December 2005 (UTC)

• I agree. Support for this format should be dropped. Xosé 13:10, 6 May 2006 (UTC)

I also agree with this. Discard support for old OpenOffice format. ODF does the trick and does it very well.--Saoshyant (talk, contribs) 19:41, 21 August 2007 (UTC)

Why can't we upload SVGs again?

Why can't we upload SVGs again? - Omegatron 21:55, 27 July 2005 (UTC)

We can. Someone with acces to the servers would need to install and configure the software required for that (mainly sodipodi, I think). Last time I asked for it, people seemed to be buisy doing other things... -- Duesentrieb 03:41, 28 July 2005 (UTC)

I don't mean server-side rendering or whatever. I just mean uploading them as source files for other images, with the standard "Warning: This file may contain malicious code, by executing it your system may be compromised."

Currently it says '".svg" is not a recommended file format. See Commons:File types for more information.' - Omegatron 14:46, 28 July 2005 (UTC)

According to Brion on IRC, if we started uploading SVGs, the software would create lots of broken thumbnails which would have to be cleaned up later. He doesn't want to allow SVG uploads until the thumbnailing system is working right for SVGs. dbenbenn | talk 15:08, 1 August 2005 (UTC)

As of today, SVG support has finally been enabled! Please try it out and report any problems. -- Duesentrieb^(?!) 12:29, 10 September 2005 (UTC)

If you try to make it too big it gets pixelated? User:Omegatron/sandbox#SVG_rendering — Omegatron 19:10, 12 September 2005 (UTC)

The 3000px thumbnail on that page uses 744px-223.svg.png. That is, MediaWiki refuses to scale an SVG larger than its "native" size. How lame! dbenbenn | talk 22:21, 12 September 2005 (UTC)

Reported as bugzilla:3449. dbenbenn | talk 22:27, 12 September 2005 (UTC)

As Brion just pointed out, MediaWiki only scales up to the larger of the native size or 1024px. I guess that makes sense: you pretty much never need an image larger than 1024px, and if you really absolutely do, you just modify the SVG so the native size is bigger. dbenbenn | talk 22:52, 12 September 2005 (UTC)

Scaling up works fine for me: User:Duesentrieb/Sandbox. I have not tried > 1024 pixel, though.

However, the "high resolution version" link is broken, though. I hope this gets fixed. -- Duesentrieb^(?!) 23:00, 12 September 2005 (UTC)

This is really cool.  :-) User:Omegatron/Sandbox

Who do I say thanks to? — Omegatron 01:05, 13 September 2005 (UTC)

Fonts don't render the same as Inkscape. What fonts does the renderer use?

I used alt+down arrow in Inkscape to approximate subscript. SVG scales down much better, though. — Omegatron 00:49, 15 September 2005 (UTC)

SVG is a markup language, kind of like HTML - fonts are left to the renderer. If you want to make sure that text looks the same when rendered elsewhere, you may want to convert the text to pathes before saving the SVG. This would make it harder, however, for others to modify the text afterwards - but still for better than with bitmaps.

That being said, font handling is IMHO one of the major problems with compatibility between renderers, which is, indeed, a PITA. -- Duesentrieb^(?!) 08:44, 15 September 2005 (UTC)

Well, which program/library is used to generate the PNGs from the SVGs? — Omegatron 04:59, 16 September 2005 (UTC)

currently librsvg is used, but that can be configured. Alternative options would be Apache Batik and SodiPodi/Inkscape. -- Duesentrieb^(?!) 10:28, 16 September 2005 (UTC)

The dotted line in my image is staying the same dash width. Is this a setting inside the SVG that I can change or is it a setting in the renderer? I drew it in Inkscape.

I want the smaller versions to look as if the original was a raster image and the dotted line was just shrunk along with everything else.

Is there a better place to ask these questions? — Omegatron 05:59, 17 September 2005 (UTC)

This seems to be a bug in the librsvg library, i have filed a bugreport bugzilla:3488. If this is really true for all images using dashed lines, this should probably be reported to the rsvg people - As rsvg seems to be best at rendering svg in most respects, we are probably stuck with it for now. -- Duesentrieb^(?!) 12:51, 17 September 2005 (UTC)

In Mozilla it looks good, but in Internet Explorer I have a ugly grey backround. Kolossos 13:56, 29 September 2005 (UTC)

Internet Explorer 7 is the first IE that supports PNG's native alpha-channel transparency--Hhielscher 20:20, 17 October 2005 (UTC)

• Problems with svg-Images: Currently the commons-renderer seems to be not willing to create PNG-thumbnails from my uploaded svg-images. One example is Image:CoA Meckesheim.svg another is Image:Sperrklinke Schema.svg which was allready working before. Has this something to do with the server changes in the last days? Btw both images render fine with the adobe svg-plugin. Maybe the Url to the thumbnail [1] might help to find the problem. --Dr. Schorsch 15:15, 3 November 2005 (UTC)
  • Image:CoA Meckesheim.svg doesn't display because it uses the <image> tag to include "Loewe3.png". The other one displays fine. dbenbenn | talk 04:05, 4 November 2005 (UTC)

• Oops, thanks for the hint, I did not mention this when displaying it with the Adobe-SVG-Plugin. I just removed the "image"-tag in Image:CoA Meckesheim.svg, but still don't get a thumbnail or rendered display. The file itself still displays perfectly with the adobe plugin. Is there any "syntax-checker" for svg files on the net that would help to prevent unrenderable files? -- Dr. Schorsch 14:34, 7 November 2005 (UTC)

Hm, rsvg (which is used on the server, too) and ImageMagick both creash when trying to load this image with the (misleading) error message "document is empty". Sodipodi and the Acrobat plugin show the image without problems. Why this is so is hard to tell - maybe because it contains a very very complex path (the lion?).

As to a "syntax checker": the file is ok syntactically (i.e. it's well formed XML). You can try to render it with rsvg - if that works, it should work on the commons too, unless you are using <image> tags to include bitmaps or it contains javascript (that will work in rsvg but is forbidden on wikimedia servers). -- Duesentrieb^(?!) 16:09, 7 November 2005 (UTC)

Inkscape failed to load that version, and correctly pointed out that there were three garbage characters at the beginning of the file. Fixed now. Also, there's an SVG validator at [2]. dbenbenn | talk 16:45, 7 November 2005 (UTC)

Thanks to dbenben for fixing it! Looks great now, doesn't it? -- Dr. Schorsch 17:26, 7 November 2005 (UTC)

Aw crap - those where probably UTF byte order indicators. Which are in theory valid in UTF-8, but in practice confuse a lot of apps, and also are completely pointles. They should always be present for UTF-16, but never for UTF-8. -- Duesentrieb^(?!) 17:49, 7 November 2005 (UTC)

Xvid is free enough for Debian

I can play Xvid AVI files on a Linux box. It's a Mac, with Debian, and no 3rd-party binary stuff added.

For those that don't know, Debian is fanatical about freedom. Debian even rejects the GNU Free Documentation License as being not free enough. Debian has been known to remove firmware images from the Linux kernel.

So if Xvid is good enough for Debian, it should be good enough for the commons.

Converting is a very lossy process. Don't we want quality?

AlbertCahalan 01:13, 30 August 2005 (UTC)

We don't just accept any old format just because it's free-license, there has to be a decision made on each (see the above query about the also-free SVG). I personally think Xvid is a great format due to its freedom and purity, but I don't know if it's as widely used as OGG. The goal of Wikimedia using OGG was partly that users download one plugin and can access all the visual/audio media we supply with just that one download, rather than one plugin for video and another for audio. Either way, Xvid's implementation here isn't likely a speedy process I'm afraid. :( Garrett 02:02, 30 August 2005 (UTC)

Nope: OGG ist just a container format, it does not say anything about the codec you need. For audio, OGG files usually contain Vorbis encoded data, for video, the Theora codec should be used - which is not very well known, and has to be downloaded and installed separately. One could have OGG files containing Xvid data, or MPEG, or whatever - but for the commons, it should be vorbis/theora (which are also the formats recommended by the OGG people).

As to Xvid: As far as I understand, the codec is free software, and the format is open, but not free - see COM:VP#Chose_one_format_for_a_specific_purpose - Arnomane said there: Xvid's source code itself is free but it uses patented MPEG-technology. So if you use Xvid you have to pay royalties to the MPEG consortium. I fear he's right. -- Duesentrieb^(?!) 08:36, 30 August 2005 (UTC)

i'm no expert but its not impossible that like with mp3 and gif that the patent claims on decoders are far far more shakey than the ones on encoders.

Btw you say ogg is a container format and you are technically right but in reality ogg is almost always used with vorbis for sound and theora for video. Plugwash 13:05, 30 August 2005 (UTC)

I disagree - the majority of video files encapsulated in Ogg containers (or "Ogm" to help Windows users) aren't Theora, 'cos it's currently useless. It's often Xvid, indeed.

Divx, Xvid, and other video codecs remain non-free for the purposes of Wikimedia, much as it pains us.

James F. (talk) 15:33, 31 August 2005 (UTC)

Hmm my experiance with Xvid videos is they are normally in an avi container. Plugwash 15:54, 31 August 2005 (UTC)

Both are true: must xVids are in an AVI container, and most OGG-videos are encoded in xVid format. No contradiction here, this only indicates that a) AVI is used more than OGG, and b) xVid is used more than Theora. If we insist on free formats, we have to stick with OGG/Theora, even though this is not well supported yet (even on linux, I had to re-compile mplayer by hand to get it to play theora files). -- Duesentrieb^(?!) 16:12, 31 August 2005 (UTC)

The standard builds of VLC (at least for windows) seem to play theora without a hitch and don't go messing with things like directshow codecs like some players do. imo if we are going to reccomend a player for theora it shuold be vlc. Plugwash 16:46, 31 August 2005 (UTC)

VLC woun't run at all on my box. But that's probably because i'm using an ancient redHat system... if VLC works well for most people, we should indeed recommend it. -- Duesentrieb^(?!) 18:15, 31 August 2005 (UTC)

Picking 1 format is fine when dealing in lossless conversions. I have Xvid; it's what my camera produces. Converting to some other lossy format is destructive. AlbertCahalan 00:39, 1 September 2005 (UTC)

XVID is entirely free down to each bit, and The Deb community is knowing what they are doing. At last i wanna say that using ogg is not a drawback but currently the most technological advanced container. I would recommend Xvid over any other codec any time as it currently gives the smallest file size, best compression and speed. Also check out the constant codec comparisons (doom9.org etc.)Slicker 10:46, 17 April 2006 (UTC)

Xvid is not patent free. See the XVID FAQ. I don't care about Debian. Their legal department knows simply nothing. Sad but true. Arnomane 10:57, 17 April 2006 (UTC)

KML and KMZ file formats for simple GIS data

Is there a possibility to upload KMZ and KML files in the nearest future. These are XML file formats, and they can be viewed and edited by free software Google Earth. I have some interesting localisations for tourists in Cracow. But I can't share those because of file-type restrictions. DrJolo 11:43, 4 September 2005 (UTC)

Please, use this en:Wikipedia:WikiProject_Geographical_coordinates from there you can go to kvalenberg.com and from there since a week to Google-Earth. Google-Earth is nice, but not realy free. Kolossos 14:05, 29 September 2005 (UTC)

An other think we should talk about is use for complex-paths or image-overlays. I tested with Image:Munich 1858 - London, John Murray, 1858.jpg, there is now a external link to google-earth image-overlay. What do you think about it? Kolossos 09:36, 7 October 2005 (UTC)

I would like to see support for .KMZ files, as well. - Cybjorg 18:30, 21 January 2006 (UTC)

 Support KML files are not just used for coordinates - they are also used for polygons, paths, overlays etc. (i.e. not just simple GIS data). There are lots of situations where a KML file could add significant value. Yes, Google-Earth is only free-as-in-beer, not free-as-in-speech, but that is not the case for the KML format. The specification is published and anyone can use that format for any purpose, including writing their own applications to read and write that format. The situation is analogous to PDF. Adobe products are closed-source, with a free-as-in-beer reader widely available. However, the format is published and anyone can write their own software to read and write that format. Wikimedia allows PDF files, so why not KML? I also support allowing KMZ and would make the same argument about the ZIP format that KMZ uses. It's a published specification and anyone can write their own code to read and write that spec with no restrictions, so I also advocate allowing KMZ (KMZ is just a zipped archive of KML files and possibly images for those that weren't aware). Stephen.frede 04:09, 4 March 2006 (UTC)

proposal for original data

Sometimes conversion to a supported file type is lossy. For video, this is just the nature of the way we store nearly all video. For office documents, there may be some unsupported feature. For images, there may be colorspace or lens information. Some images come in raw format, and could be improved by future software if we keep the original.

Problem is, there are security issues, and we don't wish to encourage crummy data types.

To solve this, let us have a .orig file extension that maps to the application/octet-stream MIME type. Clicking on such a document will only allow saving to a file, even if the web browser ignores MIME types.

So then I may rename a file from something.bad to something.bad.orig if I wish to retain a copy here. I'll then upload in a desirable format or two, or I'll ask here for help converting the file.

AlbertCahalan 02:49, 7 October 2005 (UTC)

I'd prefer adding .zip as a file type. It would allow easier integration with a GUI's existing file type association system. --Damian Yerrick 00:20, 14 November 2005 (UTC)

The whole point of using .orig is to delibrately break GUI file type association. These files are not to be downloaded for any old random use. They would exist only to better comply with the GFDL and to avoid irreversible data loss. It would be expected that the files are downloaded only to re-convert them or to examine the original for data such as copyright markings. When a new free format replaces .ogg we can convert from pristine originals instead of from a first-generation or second-generation copy. AlbertCahalan 01:37, 14 November 2005 (UTC)

True, a .zip.orig file can be renamed to .zip and thus be made usable on Microsoft Windows or most X11 based environments, whose file type associations are based on metadata within the file name. But what if somebody on the Mac wants to edit a file and then reconvert it? Is it possible under Mac OS, without using "hacker" tools that don't come with the operating system (or which have Big Scary Warnings around them), to change a file's type and creator metadata after saving it, so that the file can be turned back into a working zip file for use with whatever compression programs are popular on the Mac? Or has this feature been added to Finder in Mac OS X? --Damian Yerrick 03:29, 28 November 2005 (UTC)

MacOS X uses several ways to determine file type. There is the traditional Mac type info. There is the file extension. There can also be a MIME type now. 24.110.60.225 00:32, 2 January 2006 (UTC)

Could somebody alert the developers to this idea? I don't know how best to reach them. AlbertCahalan 01:37, 14 November 2005 (UTC)

One more thing: perhaps the .orig should be added automatically. (with or without asking the user if they'd rather cancel) AlbertCahalan 01:40, 14 November 2005 (UTC)

Nothing has been done in the last six months. Is there a reason for this? Or is everybody waiting for me to step up to learn PHP, SQL, and MediaWiki internals and write a patch myself? --Damian Yerrick (☎) 23:10, 18 June 2006 (UTC)

ScreamTracker 3.x module (.s3m)?

I want to upload the "source code" (or the "transparent copy" in GFDL parlance) for the recording Suppress fundamental.ogg, but the upload form rejects files in ScreamTracker 3.x module format (.s3m). The s3m format is editable by the GPL program ModPlug Tracker as well as many other trackers. A standard MIDI file using General MIDI instruments doesn't suffice in this case because by the nature of the article that will link to this file (en:Missing fundamental), I need to specify the exact characteristics of the two instruments used to play back the sequence. --Damian Yerrick 04:27, 9 November 2005 (UTC)

Aloowing lots of obscure formats is not a good idea, we should only support the most common ones. Also, if the link goes directly to the file or to the description page depends on how you write the link: use [[:Image:Filename.mid]] to link to the description page (note the leading colon). -- Duesentrieb^(?!) 11:31, 9 November 2005 (UTC)

If the editable version of a given file is in some obscure format, what's the best way to uphold the "transparent copy" requirements of the GFDL? Or what's the best way to use non-obscure file formats to make a recording such as this, where I need to specify both the instruments and the sequence? --Damian Yerrick 15:35, 11 November 2005 (UTC)

MIDI can't do that? Well, anyway: the formats that are already allowed agre generally considered "transparent" enough - the GFDL is very unclear about this anyway (one more reason to use CC-by-sa). You could add a note that you'll provide the original file on request, or link to your personal homepage (if you have one) and host the files there.

The article is about characteristics of an instrument. A standard MIDI file on a web page cannot specify the characteristics of the instrument; it allows only to choose from a set of 128 predefined General MIDI instruments, whose characteristics will vary significantly from machine to machine. Specifically, the recording made for the article needs to use the same sampled instrument, the first time with significant energy at the fundamental frequency and the second time filtered to remove the fundamental component entirely. MIDI can do that only by using a "sound font", but is there a cross-platform way to specify that a MIDI player program will use a particular sound font? And even then, it just shifts the requirement from being able to upload *.s3m (ScreamTracker 3.x modules) to being able to upload *.sf2 (sound fonts). --Damian Yerrick 19:35, 11 November 2005 (UTC)

Personally, I would like to allow uploads of arbitrary file formats for stuff like this. But it does not look like it's going to happen, and it would also encourage people to not provide their material in a for that is a) open and b) beasily (dis)played. Opening up to all formats would probably mean that people would upload their stuff as MPG, BMP, and what have you. -- Duesentrieb^(?!) 16:21, 11 November 2005 (UTC)

But .s3m is doesn't have the problems of .mpg and .bmp. It's publicly described (at wotsit.org), unlikely to be patent-encumbered, and easily played in free software. --Damian Yerrick 19:35, 11 November 2005 (UTC)

Oh, and see the section above for a proposal to solve this problem. -- Duesentrieb^(?!) 16:22, 11 November 2005 (UTC)

Bug in SVG-render-engine

I found a(nother) bug in the SVG-render engine: Image:LCD-Layers.svg has a radial fill pattern on plane #3 which should be repeated alternating. This works well, if you display it with the Adobe-plugin or with w:Inkscape, but the Wikimedia-renderer does not repeat the radial pattern. Does anyone know where to file such a bug? Thanks -- Dr. Schorsch 11:24, 4 December 2005 (UTC)

• g* that is not a bug that is the alpha channel. Your swf viewer uses a white background!Slicker 10:38, 17 April 2006 (UTC)

We are using rsvg as a renderer, which is maintained by the Gnome project - thus, bugreports should go to Grome's bugtracker. But try it with the latest version of rsvg first, chances are, it's already fixed. In that case, it will work on the commons too in a little while. -- Duesentrieb^(?!) 13:59, 4 December 2005 (UTC)

Where "little while" might mean 6 months.  ;) User:dbenbenn 21:29, 4 December 2005 (UTC)

Video

do we take video if so what format are we going to use, I would recomnd the h.264 codex

As it says on the project page, we only take w:OGG (w:Theora). pfctdayelise 04:31, 23 December 2005 (UTC)

We should change policy for videos due to the fact that there is no Mac encoder, and that w:OGG is a lossy compression system for video that require lossless compression have way of haveing there video content added to wikimedia (w:Kylehamilton). kylehamilton 09:36, 23 December 2005 (UTC)

As far as I know, there is no lossles video compression that works well enough - i.e. the files would be much too big to handle over the web.

As to supporting other formats/codecs: if you know any codec that is a) completely free (no patens, open spec, free software), b) works well and is c) better supported than ogg theora, please tell us.

Encoding OGG on Mac should work with VLC... or is that feature not available on the MAC version? Using VLC for encoding is a little tricky (arcane command line stuff), but it should work. -- Duesentrieb^(?!) 12:11, 23 December 2005 (UTC)

Slideshow

For slideshows, wouldn't w:s5 be a better format. Of course theres the javascript issue, and the multi-file issue. Maybe they could be zipped/g-zipped/archive format of choice, and then given the extention ".s5". Just a thought. Bawolff 22:39, 2 January 2006 (UTC)

Ogg FLAC

FLAC is a lossless audio compressor. The Commons only accepts Ogg, which usually means Ogg Vorbis, which is lossy. I was reading the man page for FLAC, and I noticed the --ogg option:

When encoding, generate Ogg FLAC output instead of native FLAC. Ogg FLAC streams are FLAC streams wrapped in an Ogg transport layer. The resulting file should have an '.ogg' extension and will still be decodable by flac.

I guess that gives us a way to upload lossless audio! In particular, here's what I think is the ideal way to upload audio that you make yourself:

1. First, losslessly compress it as Ogg FLAC, and upload it with a .ogg file name
2. Then, lossily compress it as a regular Ogg Vorbis, which saves a lot of space. Upload the new file with the same name.

That way, the lossless version is still available for conversions or recoding, but the version that's actually downloaded and used by people will be the small Ogg Vorbis file. (Basically, it's just a way of "thumbnailing" an audio file, since MediaWiki can't do that automatically.)

Does anyone have any comments about that? Can we officially recommend this as a "best practice"? User:dbenbenn 18:54, 13 January 2006 (UTC)

That sounds pretty nifty. Maybe we could even make a cute little template to put a "Download lossless version" link on the file page. ¦ Reisio 20:00, 13 January 2006 (UTC)

 Support — I absolutely agree with the idea of OggFLAC files being overwritten by lossy Oggs to keep two versions. —UED77 23:08, 13 January 2006 (UTC)

I agreee that it's a good idea to use FLAC for lossless audio, and supply a compact Vorbis version for every day use. Hoevery, I don't think it's a good idea overwrite the lossless version with the compressed one - it would be much better to have them separately, for clearity and consistency. I would suggest to use xxx.flac.ogg and xxx.vorbis.ogg as a naming scheme. -- Duesentrieb^(?!) 23:45, 13 January 2006 (UTC)

Y'know, I bet for an experienced programmer it'd be child's play to set it up so Commons does it automatically. We're not talking about much...

• use file to determine if a new upload is an Ogg FLAC
• run ffmpeg -i file1.ogg -acodec vorbis file2.ogg (or whatever)
• do the normal setup for a file page
• add a link to the FLAC file on the file page

Perhaps before we decide on this we should track down a programmer/admin/whatever or two and run it by them - maybe they can have it done in a short amount of time and save us from having to redo a lot. ¦ Reisio 01:51, 14 January 2006 (UTC)

Sure, make a patch and post it to bugzilla. Or, at least, make a feature request there. -- Duesentrieb^(?!) 13:38, 14 January 2006 (UTC)

Problem - according to Commons talk:Sound, FLAC is mostly useless at present, because of current filesize caps. ¦ Reisio 23:43, 15 January 2006 (UTC)

True. I was thinking of "short" sound files, where the FLAC version is small enough to fit in the upload limit. Like Category:English pronunciation, for example. User:dbenbenn 07:39, 16 January 2006 (UTC)

As I recall, there was a discussion about lossless audio, similar to the one we're just having, where someone explained that disk space probably wouldn't be an issue, but bandwith would. (I cannot find the discussion.) It would therefore make sense to apply the file size limit to the Vorbis thumbnail, rather than to the uploaded FLAC itself. Also, one might question if having a limit at all is a good idea. We will probably, in the future, be sorry that we once had it. The bandwith issue could possibly be resolved by allowing downloads of huge files (as opposed to scaled-down versions) only at very low speed. What do you think? —Bromskloss 23:41, 22 May 2006 (UTC)

FLAC would be great for things like User:Omegatron/Gallery#Audio, too. — Omegatron 08:03, 7 May 2006 (UTC)

I've used Ogg FLAC a few times now, for example at Image:Piano Sonata No. 11, Variation 3.ogg. The first revision in the file history is FLAC. I then uploaded a lossy-encoded version, to save bandwidth. So the faster-to-download version is used by most people, but the FLAC is available as an archive. User:dbenbenn 15:44, 7 May 2006 (UTC)

Ah! I did not know that was possible! You should clarify that in the file description, and make an explanation of how to do that on this page. I would have done the same with things like if I knew how.

It would be nice if it supported the .FLAC extension, though. — Omegatron 00:44, 3 June 2006 (UTC)

Xiph guy here. Personally, I do not understand why not allow FLAC in its native container. yes, anyone may use it within Ogg, too, but the FLAC container is the most common thing in the wild. Also, please notice that Ogg FLAC does not use the .ogg extension anymore. We have just changed some of our projects file extensions and MIME types. FLAC is still .flac and application/flac, but Ogg FLAC is now .oga and audio/ogg --Saoshyant (talk, contribs) 19:02, 28 August 2007 (UTC)

ogg video

I've got a couple of short videos I took that I thought would be relevant for the commons, but they're all in .mov format and of course I can't upload them. Does anyone have any ideas on a relatively simple way to convert them to .ogg format? The main page has info for audio, but is noticeably silent on the subject of video. --Bachrach44 19:29, 13 January 2006 (UTC)

I think it depends on your operating system. For Linux there is the ffmpeg2theora tool to convert .mov to Ogg Theora. As I don't use Linux, I could not test it before. Perhaps you would like to read w:en:Theora, paragraph "Encoding to Theora" for more infos. I think there is no similar tool for Windows OS yet. If you find a solution, please drop me a line, because I would like to convert also .mov to Ogg Theora. Greetings, Longbow4u 12:13, 14 January 2006 (UTC)

As with so much excellent software made by users of nonWindows OSes, there are Windows binaries of ffmpeg2theora. I'll go ahead and add some video info to the main page. ¦ Reisio 21:28, 15 January 2006 (UTC)

I belive VLC (available at least for Linux, Windows, and MacOS X) can convert pretty much anything to ogg/theora. But as far as i know, it's a bit tricky and requires you to fiddle with arcane command line option. I don't know about any easy to use, clicky-interface converter for theora. -- Duesentrieb^(?!) 13:37, 14 January 2006 (UTC)

3D in the Commons.

I don't know much about 3D, but I believe that it having 3D objects and scenes in the commons may be useful for other Wikimedia projects.

3D is also an area where a free open source library could be very useful for other Wikimedia projects, so I think Wikimedia Commons should allow 3D files.

I propose that we start (or maybe continue) studying an open 3d file type for the Commons (if it exists).

In terms of Open Source software for 3d I use Wings 3D (just for fun), but Blender is more popular among more serious users. --OsvaldoGago 22:12, 21 January 2006 (UTC)

One thing you can do is to make a free texture-library here, I mean optimizes images with a size of 1024x1024 or so and with invisible borders. So we need no change in the software. Kolossos 15:12, 4 February 2006 (UTC)

Yep strong support from my part. The upload of blender files etc, should be permitted.Slicker 10:34, 17 April 2006 (UTC)

I think the same. 3D models, motion controllers and many other 3d-related items should be included in the Commons. A 3D scene usually includes everything in a virtual 3d world, so let's start with Blender Scene (".blend") files, please.

So let's move this forward. It is an open filetype. What do we do, submit something on meta? Bugzilla? This could really potentially be a catalyst for some pretty interesting things. But could this present security concerns? Emesee (talk) 07:25, 14 July 2008 (UTC)

Are VRML and X3D open ? I think X3D is because it is XML based. Both are text based formats as well so are truly open source .. they are not binary formats. I really want to see this because I am in the process of converting the official NASA model of the ISS ( http://www.nasa.gov/multimedia/3d_resources/assets/iss-hi-res.html ) into an open format as I think it should be available to everyone. DJ Barney (talk) 01:09, 24 March 2009 (UTC)

Powerpoint PPT

I wanted to upload my slides for the Wikimania Conference, but PPT file format isn't allowed. Can this be changed, please ? --Wikinaut 18:47, 7 April 2006 (UTC)

No. PPT is a propriatery format, only open format files are allowed on commons. Also, MS Office files are containers that can contain many things, including viruses. Please convert the file to PDF, you can upload that. -- Duesentrieb^(?!) 19:00, 7 April 2006 (UTC)

According to this page we also accept SXI, which is OpenOffice's format for slides. Probably a high chance that things could go wonky when converting PPT > SXI, though. Caveat emptor. pfctdayelise (translate?) 15:40, 8 April 2006 (UTC)

Still use Openoffice rather than PDF for that case.Slicker 10:35, 17 April 2006 (UTC)

we can't use GIF yet w/o a policy change

According to wikipedia, the final GIF patent does not expire until Friday, 11 August 2006. Something is seriously wrong here.

• We allow GIF, in violation of the supposed standards around here.
• We disallow far more important formats like MP3, MPEG2, and MPEG4.

How do we fix this? Waiting months while violating a supposed policy is not cool. There are clearly two fixes possible:

• We delete all GIF files right now. (seems like the most likely answer)
• We relax the policy to include MP3, MPEG2, MPEG4, etc. (perhaps anything with an open source player)

What is it going to be? Tap dancing around the issue? Covering the eyes and ears?

AlbertCahalan 03:21, 14 April 2006 (UTC)

So, you are saying, because we made a bad decission once, we are supposed to extends and continue that bad decission? GIF is mainly supported for historical reasons. -- Duesentrieb^(?!) 08:42, 14 April 2006 (UTC)

Maybe you aren't aware but we are actively replacing gif's by png's and got some trouble with local Wikipedias upon our position that gif is deprecated. The reason why we were accepting gif's initially (which I also think was not the best idea) was that png animations aren't that easy possible AFAIK and animations are important for educational purpose (for example we have a nice animation of the function of a steam engine) so gif's in Commons are accepted for animations only until we are able using svg animations (currently it is prohibited server side uploading animated svg's out of security reasons). Arnomane 09:54, 14 April 2006 (UTC)

The GIF patent, as you've stated, will expire soon. Given that we only have a handful of GIFs, I believe we can safely keep them without having to worry about being approached to pay up — the four months will be over quickly. Besides, as Arnomane stated, APNG and MNG are still very cumbersome. As for the other file types you've mentioned, just because a file type has an open source player doesn't mean it's open source. Besides, they are still very much patented. You can't expect to slip by with a ton of MP3s for I-don't-know-how-many years until Thomson's patent expires, given that they are known to be actively enforcing it, and that the format itself is notorious. —UED77 23:06, 15 April 2006 (UTC)

Furthermore, even if we did decide not to host GIFs until August, deleting them all would be extremely foolish. A much better technical solution would be to simply make them unreadable on the server. Then they could easily be restored after the patent expired. User:dbenbenn 23:20, 15 April 2006 (UTC)

According to wikipedia, the .mp3 patent expires April 2010, and Thomson is not enforcing it against free software. The .mp3 situation is thus approximately the same as the .gif situation. AlbertCahalan 23:03, 16 April 2006 (UTC)

It appears that .swf files are unencumbered. Open source players and authoring tools both exist. So we have the odd situation where a patent-encumbered animation format (.gif) is allowed, while an unencumbered replacement (.swf) is banned. This is sick. Frankly it looks like something unrelated to patent concerns is driving this, such as an infatuation with "cool" and "trendy" formats. SVG and Ogg Vorbis are cool and trendy, while .swf is not. I think .gif lives because it helps block adoption of .swf. Prove me wrong though, either deleting the .gif files or allowing these other formats. AlbertCahalan 23:03, 16 April 2006 (UTC)

The SWF spec is a trade secret, and the license does not permit free viewer implementations. --Damian Yerrick (☎) 23:07, 18 June 2006 (UTC)

BTW, there is no patent that covers serving any of these files from a web server, so it's not as if Wikimedia would be in danger. Well actually, it appears that Wikimedia resizes the .gif files. Resizing requires compression, which means that Wikimedia violates a patent for .gif files. One would hope that Wikimedia doesn't resize audio files, so unlike .gif there would be no violation with .mp3 files. AlbertCahalan 23:03, 16 April 2006 (UTC)

What's wrong with "resizing" audio files, such as to crop something to a 10 seconds, downmix to mono, or transcode to 32 kbps in order to make a preview? --Damian Yerrick (☎) 21:35, 27 January 2007 (UTC)

How again is GIF patented? All of Unisys's U.S. and foreign patents on LZW compression have expired years ago, and those claims of IBM's U.S. patent that describe LZW compression have no chance of holding up in a court of law, as Unisys's patent would be considered prior art. --Damian Yerrick (☎) 23:07, 18 June 2006 (UTC)

Please ENABLE SUPPORT for Macromedia / FLASH

This would allow way smoother animations, that are faster loading and would allow technical interactive animations. See my profile on wikipedia 'Slicky'Slicker 23:10, 15 April 2006 (UTC)

If you convince Macromedia to release a full spec of their formats along with a free software / opensource version of their player, i'm sure we'll be happy to accept flash. -- Duesentrieb^(?!) 23:14, 15 April 2006 (UTC)

libflash-mozplugin almost does the job. It's not quite stable yet, but it does run most things I run into. I'd use it, except that crashes are not isolated well. When libflash-mozplugin dies, so does the browser. With a few bug fixes, or the use of Linux's seccomp feature to isolate crashes to the plugin, flash ought to be acceptable. (if you still don't run Linux, you probably like crashes, so no problem) There are some Open Source authoring tools out there, including a perl module I think. AlbertCahalan 06:54, 16 April 2006 (UTC)

The fact that there is OSS software for viewing/editing Flash/Shockwave files is a good thing. That does not make this a free format though. It's still not documented or standardized, and it's probably even encumbered by software patents. There's free software for viewing and editing MPEG, too, but it's not a free format, so it's not acceptable here. As I said: as long as macromedia does not officially change policy, flash support is unlikely to happen.

"probably even encumbered by software patents", as opposed to .gif which is definitely encumbered by software patents? It's clear that wikimedia cares little for the patent issue; there ought to be an effort to replace the patent-encumbered .gif files with apparently-unencombered .swf files. AlbertCahalan 22:59, 16 April 2006 (UTC)

Which patent in which country encumbers GIF? --Damian Yerrick (☎) 23:15, 18 June 2006 (UTC)

Ther eare also technical reasons: you would probably want to be able to embed flash animations into pages, just like images. I would definitely not like that, because it would cause pages to load slower, and worse, hog CPU power as long as the page is open (when working on wikipedia, I often have dozens of tabs open with different pages). It would also prompt people that do not have flash installed yet to go to a commercial website to download and install propriatery software not endorsed by wikimedia.

Furthermore, the mechanisms for embedding such content in webpages is still not really standardized and flacky at best (<object> vs. <embed> tags, etc). Also note the recent announcement by Microsoft that embedded media will no longer work seemlessly in Internet Explorer, because of a patent suit they lost. Some JavaScript trickery is required, which again will not work for all people. This is gettign more and more ugly.--by anonymous

The goal of Wikimedia is to provide free content in free formats, accessible with free software without jumping through hoops. -- Duesentrieb^(?!) 13:36, 16 April 2006 (UTC)

-- Creating "SWF" The file format used for Flash is called SWF (ShockWave Flash).The SWF file format, though developed and maintained by a single corporation, is an open file format.That means you can generate and use the file format without paying royalties.

Most SWF files and applications are created in the Macromedia Flash authoring tool, although the specification can be downloaded from Macromedia's website and used to create desktop and server programs that generate SWF files.

For PHP developers there is a very useful library available called MING, allowing server side generation of SWF's on-the-fly. -- First of all you're right about wikimedia of course, so i fully understand your concern not to include swf. However as far as wikipedia goes, and this is what i meant, the primary goal is to build and as good as possible and as free as possible, mutually, collaborative information pool. Licence wise there is no difficulty. This would be like saying that you do not use pdf's because the specification has been carried out by a (commercial) company. Best regards, Slicker 18:33, 16 April 2006 (UTC)

Looking at macromedias site, i'm a bit confused. From the FAQ:

Is a licensing fee required for access to the Macromedia Flash file format (SWF)? There are absolutely no access or deployment fees required to use the Macromedia Flash File Format Specification.

So it's free as in beer. OK. But:

Can I use the File Format Specification to create a Flash Video encoder or a Flash Video streaming service? No, the File Format Specification is provided for the specific purpose of enabling software applications to export to the Macromedia Flash File Format (SWF).

Uh, so i'm not allowed to create a player using their docs... how about without using their docs? how could they tell?

The license terms for using their SDK is similar: [3]; I don't really get their position on this... SWF does not appear to be a free format to me, they seem to try to restrict third party support to a minimum. -- Duesentrieb^(?!) 20:39, 16 April 2006 (UTC)

Nope you are right that wouldn't make much sense, BUT flash video is something else, which was introduced in version 6 and is based on the VP6 codec, which they themselves licenced. Also the specification of the SWF does OF course not specifiy the VP6 codec but the VP6 SDK does. Therefore you cannot build your own software along with video support by merely having all the SWF specs, SDKs etc...

SWF per se is free however, enough to warrant its use in wikipedia, IMHO. Lemme know what u think. Slicker 10:23, 17 April 2006 (UTC)

Addendum: this may be relevant to the discussion: http://www.oreillynet.com/pub/a/javascript/2002/05/24/swf_not_flash.html - go to page two and read the comments, too. -- Duesentrieb^(?!) 20:51, 16 April 2006 (UTC)

thanks, yep it is. Again it should be noted fla has nothing todo with flash, which one can easily see in a 20MB sized fla movie with an outcome of a 60kB swf file. Fla contains programm code, memory dumps etc, thus use of it would be revening (rev.eng).Slicker 10:28, 17 April 2006 (UTC)

PNG/GIF

Say if .PNG OK for animations. Unify views with Commons:First_steps/Quality_and_description's of PNG/GIF issues. --User:Jidanni 2006-04-26

as far as I know, no browser supports animated png - also, i'm not sure MediaWiki (or, more accurately, ImageMagick) is able to produce thumbnails of such animations. So, at the moment, I don't think animated PNG is really supported... is there even a real standard for that? As far as I see, APNG and MNG are two competing formats, and neither is really widely used or supported. -- Duesentrieb^(?!) 11:39, 8 May 2006 (UTC)

What's wrong with my SVGs?

I have been trying to do some mathematical diagrams as SVG, and I would like to as it is clearly better, but whenever I do this, some thumbnails don't show on the article page, on Wikibooks or Wikisource, which is the reason I upload them in the first place. They come up with a white and grey checquered background, and you can only actually see the SVG when you click on the link below the preview. For an example, see image:Slope_Field_1.svg. I'm using Adobe SVG viewer with Opera 8 (which also has some native SVG support). They are made in illustrator.

Another example is image:Radian_Angle.svg, which does not display in the article or on the image page, but does display in the Category (Angles) and when you click the link to the SVG on the image page. This came up with an error (a problem with a <g> tag?) on the SVG verifier. I went back to Illustrator and save the file again as a v.1.0 file, without retaining illustrator compatibility, and changed to UTF-16 engoding form UTF-8.

I uploaded this as image:Radian_Angle_Definition.svg. This is even worse - I just get a link in the article, rather than a thumbnail of notion - the image page shows a small blue symbol that looks like a bezier curve or some sort, and the Category view also shows this. The file linked from the image page is still proper though.

If you can tell me what it is I'm doing wrong, then I will be more than willing to use SVG over PNG. In the meantime, I try to make the PNGs large to give extra information. Also, what is the best font to use for labelling the diagrams without having to save as outlines? When this is resolved, these three images will also need deleting so I can replace them.

Thanks

Jjbeard 20:31, 21 May 2006 (UTC)

This is strange... well, the UTF.16 file simply will not work - the renderer (rsvg) apprently does not like utf-16, and mediawiki doesn't either, apperently. So it shows a generic icon for the file type (like the speaker symbol for sound), that's the "small blue symbol that looks like a bezier curve". So no big mystery there. But I don't know why the other files are not rendering. I'll try to get someone to find out - thanks for reporting this! -- Duesentrieb^(?!) 22:27, 21 May 2006 (UTC)

Ok, here is the reason: there's a memory limit for rendering to prevent the servers from being bogged down by rendering huge images. Now, you image is quite simple, so it shouldn't trigger that limit. But: adobe illustrator appearently puts lots of additional data into it's SVG files. A simply graphic like yours should have no more than 5KB - your file 179KB big! 99% of its content are junk - open it with a text editor. Scroll down abot two pages, until you see blocks of garbeled data starting. That data is not actually SVG, it's not used by the renderer, it just wasts memory, diskpace and bandwidth.

So, please tell illustrator to save "plain" SVG, or, if that is not possible, use something else, like Inkscape. Or strip the junk from the files by hand.

I have uploaded a new version of Image:Radian Angle.svg with all the junk stripped out. It works better, but rendering still fails sometimes - i'll keep looking for the cause. For some odd reason, these files seem to use a lot of memory. -- Duesentrieb^(?!) 22:53, 21 May 2006 (UTC)

Hm, sodipodi doesn't even render the file - you should probably really use somethign else... Or try again to save as utf-8, "without retaining capabilities". Maybe it works.

PS: if you re-upload for testing, remember to clear your browser's cache to see the result. -- Duesentrieb^(?!) 22:59, 21 May 2006 (UTC)

I have installed Inkscape and have been playing around. I seem to have solved the problem by saving the files again as "Inkscape SVG". All the file I have done this to seem to work just fine. The Radian Angle file is now at image:Radians_Angle_Definition.svg and is only 5KB. I have also done another SVG for another article which shows that the Inkscape method seems to handle larger files too, and that is image:Oscilloscope_Front_Panel.svg. This is a large file (250KB ish) but I have checked the source, and there is none of that useless code you found in the Illustrator files.

Thank you for your help and advice, and sorry for being such a PITA. At least now I can get on with contributing something...

Jjbeard 00:44, 22 May 2006 (UTC)

Thanks again for contributing to the commons, and for bringing this up! Rendering issues and broken svg is a pita, not people talking about it :) -- Duesentrieb^(?!) 01:12, 22 May 2006 (UTC)

On the COM:HD two users reported thumbnail problems with Adobe Illustrator SVGs. One was able to fix his by saving it in Inkscape. I fixed the other by using ?action=purge on the image page. So that makes me think it is bugzilla:2888. But the image I fixed was Image:Cavalier perspective 45.svg, 6kb. I opened it in a text editor and it looked fine, no obvious "junk". So was it this bug or maybe something else? How can we tell...? --pfctdayelise (translate?) 13:53, 1 June 2006 (UTC)

Image:Green is Good.xls

How did this manage to even be uploaded?? pfctdayelise (translate?) 04:39, 24 May 2006 (UTC)

Apperently, XLS was allowed for upload fora while. It's disabled now. I have found some more XLS files and have listed them on the village pump. -- Duesentrieb^(?!) 11:08, 24 May 2006 (UTC)

Relative units in SVG

In my example of microphone patterns above, I wanted the image to resize as if it were raster; absolute units, in other words.

One of the great advantages of SVG is relative units, though, like lines in graphs that are always 2px no matter how much you scale the image. Is there any way we can support relative units as well as absolute? It seems like the current software generates a big image with absolute units and then just scales the image in a raster way.

Will there ever be an option to put SVGs into the page instead of converting them into PNGs, for browsers that can handle it? — Omegatron 00:49, 3 June 2006 (UTC)

Isn't that what happens when you click through to the original file? pfctdayelise (translate?) 01:12, 19 June 2006 (UTC)

Embedding the SVG directly may be come an option in the future. Don't hold your breath, though. -- Duesentrieb^(?!) 10:09, 22 June 2006 (UTC)

GIFs

There is another use for gifs.. if you have a photo with text on it, it seems to be too large as a PNG, while a JPEG wrecks the area around the text. --Astrokey44 08:19, 22 June 2006 (UTC)

The PNG should not be larger than the GIF - at least not if you use the "right" settings (indexed colors instead of true color, for instance). -- Duesentrieb^(?!) 10:08, 22 June 2006 (UTC)

How do you get these indexed colors? It also seems to take a long time to download a PNG photo --Astrokey44 10:35, 22 June 2006 (UTC)

That depends on teh software you are using. -- Duesentrieb^(?!) 10:37, 22 June 2006 (UTC)

For instance, in GIMP, you do Image > Mode > Indexed... and specify a number of colors (by trial and error). "No dithering" tends to work better for line drawings such as most of the images you see with {{BadJPEG}}. --Damian Yerrick (☎) 03:08, 23 June 2006 (UTC)

Is this the same thing as on photoshop how you can snap to web colors? --Astrokey44 04:14, 23 June 2006 (UTC)

"Snap to web colors" just uses values of 00, 33, 66, 99, CC, and FF. I remember reading that indexed color is also called "indexed color" in Photoshop, although I've never used that program so I'm not sure. But in the interest of promoting the use of free software in the free Commons, I personally recommending learning how to use GIMP, which is also available for Windows and Mac. --Damian Yerrick (☎) 13:06, 23 June 2006 (UTC)

Open Office 2.0

Hi, can we anable the Open Office 2.0 format. Its an XML based ISO Standart and so very good for longtime archiving. --PatrickD 18:25, 24 June 2006 (UTC)

+1 (see above). Who's responsible for this settings? --Chrislb 12:08, 30 June 2006 (UTC)

Vote for Bugzilla:2089 (Whitelist the OASIS file format). --Raymond ^Disc. 19:53, 30 June 2006 (UTC)

Someone requested it on wikitech-l too. pfctdayelise (translate?) 03:01, 1 July 2006 (UTC)

Inkscape SVG render badly

Anyone who can help me on following problem?

Note the missing arrows. I'm uploading PNGs for every SVG I draw what is superflous as Mediawiki should be able to handle SVG properly. Any hints where to place subscripts? I place them absolut what looks bad once a different font is used, see left pic. --Chrislb 12:13, 30 June 2006 (UTC)

See bugzilla:5163, bugzilla:5325, and bugzilla:5694. All of this seems to be caused by bugs in the renderer. -- Duesentrieb^(?!) 14:11, 30 June 2006 (UTC)

Thanks, voted. If anybody still has some advice on subscripts in Inkscape please give me a hint. --Chrislb 22:43, 30 June 2006 (UTC)

Yes, I got the same problems on muy SVG-pictures.. I usually draw arrows with vectors and convert bad looking texts completely to vectors. That increases the file size extremely (for examle this file, it's about 200kB whereas it could be less than 10kB). But that's not my problem ;-)

(see some more text about this topic at my user page)

--Sven 22:59, 2 July 2006 (UTC)

I've already made a comment on Sven's page that one may need to make minimum font-size of texts not smaller then about 10px (you may view the code to see if it is OK). In most cases if it looks OK in Opera/Firefox then it will be OK on Wikimedia Commons. I'm not sure how to do that in Ikscape, but you can group all non-text elements and scale them by ten (<g transform="scale(10)">nontext stuff</g>) and then all text attributes should be multiplied by ten. --Nux (talk) 00:42, 4 October 2006 (UTC)

If your image editing software has the ability to convert everything to outlines then my advice is first to upload a version with everything in its original form, then if nessacery upload another version with it converted using the same name, that way the orginals and the converted versions will be kept together.

I found and fixed this image as I was trawling through "images with librsvg render bugs". I always use hand drawn triangles for arrows - its just a triangle and doesnt take long, and it saves a whole world of misery with the renderer. As for the suscripts, I use the built in TeX generator in Inkscape to produce really nice looking SVG mathematical objects. That tends to make large files, but it looks much, much better than maths in Arial. Also if you specify "Arial" and the font size explicity in the text dialog (go there and select it, not just assume - what is written in the font drop-down on the toolbar isn't always what you get), the renderer likes that better. If you don't do it, the renderer gets confused and substitutes odd fonts and sizes all over the place. Inductiveload 15:39, 7 October 2007 (UTC)

Ogg?

OK this makes no sense, why on earth does the site demand the use of .ogg for audio files? Its a pretty damn obscure file type that requires extra software to play, wouldn't it be better to use wav which everyone can access?--Josquius 17:22, 4 July 2006 (UTC)

Extra software? I guess a few people have to install an extra player for wav. So open your eyes, there are more systems out there than just the one u have. And btw wav has no compression, so it's unusable on the internet. --Chrislb 11:58, 5 July 2006 (UTC)

The alternative to ogg would be mp3 - which is patent encumbered, meaning that you can not legally make a free open source encoder for it. Wikimedia promotes open content in open formats. And while ogg is not as widely spread as mp3, it'S hardly obscure - there are plugins for all major players, and it's even supported by some portable players by now. Besides that, it gives better quality and better compression.

I really don't see a problem with ogg/vorbis for audio - ogg/theora for video is a much bigger problem, but for lack of (free, open, supported) alternatives, we are stuck with it for now. -- Duesentrieb^(?!) 12:13, 5 July 2006 (UTC)

I think there are recent development efforts going on on the Theora front. The developers received movie material from an open source movie "the elephants dream" to test their codecs. I would love it if they would receive more support and funding from a big firm to accelerate their effort. Longbow4u 12:55, 5 July 2006 (UTC)

There is a current "Summer of Code" project being done by someone about making an in-browser OGG player for MediaWiki. I really hope this project is completed because I think it will be a fantastic boost for our audio/video content (and the use of OGG formats all over the net) and people will stop complaining about how obsolete it is. :) pfctdayelise (translate?) 09:37, 6 July 2006 (UTC)

Its not just the listening, there are plug ins for that. When it comes to making your own files however ogg is not good. Most decent recorders only do wav or mp3.--Josquius 13:03, 12 July 2006 (UTC)

Then record first and convert later. If you have the disk scape, it's a good idea anyway to record to wav first, so you can experiment with different encoder settings. Encoders are avilable for all platform (though i'm not sure if there's a good clicky interface everywhere) -- Duesentrieb^(?!) 14:12, 12 July 2006 (UTC)

In fact, users of Microsoft Windows OS can download OggDropXPd and then drag and drop .wav or other supported PCM files into its window. However, there is currently no way to store the multitrack "transparent copy" that the GNU FDL requires. --Damian Yerrick (☎) 19:36, 25 October 2006 (UTC)

DNG

Hello, as can be read in the policy, the Wikimedia Commons promote image uploads of the highest quality. I would like to propose the use of DNG, a royalty-free raw image file format published by Adobe. A raw image format will offer the top quality (even allowing High dynamic range imaging), therefore is the choice of professionals.

There are free software tools (The GIMP, F-Spot, dcraw...) with DNG support (also for converting other raw images formats to DNG), so MediaWiki can easily add a conversion tool for viewing this file as a JPEG (as currently done with SVG files, whose are converted to PNG). What do you think? --surueña 17:26, 12 July 2006 (UTC)

It's probably worth considerin, once it truely becomes "simple". Mediawiki does not have a nice plugin architecture for adding new formats. It can do conversions that are supported by w:ImageMagick, and it has a bunch of special cases and hacks for SVG. If this code is redesigned, adding more formats that require on-demand conversions will become feasable. -- Duesentrieb^(?!) 17:47, 12 July 2006 (UTC)

Good! ImageMagick supports DNG too [4] (AFAIK, is the only raw file format supported). --surueña 20:20, 12 July 2006 (UTC)

File a request on bugzilla, then. Supoprt for w:DjVu is currently being worked on, btw, so it's not unlikely DNG would be implemented too. TIFF may also be nice, btw... if we get multi-page support for DjVu anyway... :) -- Duesentrieb^(?!) 20:33, 12 July 2006 (UTC)

The only issue I would like to discuss is the license of the DNG patent specification. I'm not a lawyer, but it seems Adobe lets anyone to freely use this format [5]. On the one hand it's like the PDF spec, although it is developed by Adobe there is also an ISO standard (PDF/X), but on the other hand is this license free enough for the Wikimedia Foundation? I don't know, has anyone experience with this? In otherwords, I think the point is whether DNG is an open format. --surueña 20:51, 12 July 2006 (UTC)

Error message

The error message if you want to upload .odg (OpenOffice 2.0 Draw) is

".odg" is not an allowed file format. See [[Commons:File types]] for more information.

Yes, it's with brackets, no link. -- Nichtich 23:49, 1 October 2006 (UTC)

Video containers

Why it is used only OGG, in fact there are also other free media containers, for example MKV? --Eraser 09:28, 5 November 2006 (UTC)

Any video can in theory be losslessly converted among Ogg, Matroska, and AVI. Choosing a container and sticking with it makes it easier to build reliable software. It's the same reason that we don't use TIFF even though the compression (DEFLATE) is much the same as PNG. Is there a specific feature that Ogg lacks and MKV has that would improve Commons' ability to be a free source of content useful to Wikimedia projects? --Damian Yerrick (☎) 02:31, 9 November 2006 (UTC)

Matroska more flexible conainer than OGG, for example in it more advanced support of subtitles, and it is important for the multilanguage encyclopedia. Matroska also is more scalable, in is easier to add new features, support of new free codecs, etc. I do not call to refuse from OGG, but let users will have a choice probably depending on an available software. --Eraser 16:29, 9 November 2006 (UTC)

I'm not very familiar with Matroska, so I'll leave the rest of the argument for others to handle. For now use Ogg Writ for subtitles. --Damian Yerrick (☎) 20:36, 11 November 2006 (UTC)

Matroska supports SSA/ASS subtitles which possess greater opportunities on placement and coloring of the text, and have many good editors, for example Aegisub, also allows to attach files - fonts, the pic for a preview, etc. For muxing Matroska is simple program MkvToolNix which works both in Windows and in nix OS. All programs are freeware. --Eraser 09:27, 12 November 2006 (UTC)

I would support Matroska as it really is a more flexible format (see w:Comparison of container formats, w:Ogg, w:OGM, w:Matroska). The "problem" with Matroska in our case would be that it's too flexible: The valid, unhacked Ogg container (not OGM) is only able to support Vorbis (audio) and Theora (video), both necessarily open source. Matroska supports unfree formats as well, including H.263 (Xvid, DivX, etc.), H.264 (x264, Ateme/Nero, etc.), VC1, WMV1-3, and such. Of course, it is also fit for Vorbis and Theora, and if we'd be willing to actually ensure by checking the file itself that it only contains Vorbis, Theora, and free subtitles (not quite sure about our subtitle options, though), then we should allow Matroska, as it is more flexible and a viable alternative to Ogg. —UED77 00:26, 2 January 2007 (UTC)

Need help with XTF files

I need help with XTF files as I cannot access it well and Commons does not accept it.--Jusjih 07:59, 22 November 2006 (UTC)

Please allow the Sourceforge Freeship 'fbm' file type.

Who must approve permission for the addition of the Freeship 'fbm' filetype for the Wikimedia Commons? The opensource Sourceforge program 'Freeship' , allows creation of 3D renderings of shapes, which can then be rotated 360 degrees to assist visualization. See example here. I am hopeful that people (especially myself) be allowed to put these three dimensional 'fbm' renderings into the Commons. BruceHallman 16:48, 27 November 2006 (UTC)

"." is not an allowed file format. See Commons:File types for more information.

--Timeshifter 22:10, 2 December 2006 (UTC). Copying images from wikipedia to wikimedia commons can be mind-boggling in difficulty. The instructions on how to do so are spread all over the place, and are very confusing. And when one finally fills out all the upload form info, and tries to upload the image to commons, one can get this error message:

"." is not an allowed file format. See Commons:File types for more information.

"Commons:File types" is not clickable in the error message. So if one is lucky and has learned about internal wikilinks and their brackets, one may get to this page, and figure out that the problem (usually) is that one has to add the image extension. Unlike in many programs where the image extension is added automatically. jpg, gif, png, svg, etc..

Can the upload software be changed to automatically add the extension used in the source for the image?

And can the error message be a whole paragraph with working links instead of the current cryptic message? --Timeshifter 22:10, 2 December 2006 (UTC)

It not only adds the extension, but fills the whole file name, but maybe there could be some javascript attached to check the form before uploading and warn about missing extension... Anyway there are two bugs for this one: 6261 and 3208. --Nux (talk··dyskusja) 02:29, 3 December 2006 (UTC)

Hi Timeshifter, sorry for your troubles. The plaintext instead of a link is not something we can control, unfortunately. Were you using CommonsHelper to transfer the files? cheers, pfctdayelise (说什么?) 07:18, 3 December 2006 (UTC)

I finally starting checking the watchlist for the commons. I thought my wikipedia watchlist had it all covered. Anyway thanks for replying earlier. I did not use CommonsHelper. I will check it out next time I upload images to the commons. --Timeshifter 06:30, 31 December 2006 (UTC)

video file size

Greetings, I wonder if it's a good idea to upload a larger video file (around 1 GB) into commons, which would be a lecture meant for wikiversity , is the project ready for it or should I link public video services like google video or internet archive ? --Quentar 13:49, 26 December 2006 (UTC)

Why is the video 1 GB in size? What is its frame rate, what is its pixel size, and how long is it? --Damian Yerrick (☎) 22:03, 27 December 2006 (UTC)

"JPEG without compression"

"If you experience problems, convert your PNG file to JPEG without compression and upload the JPEG file."

Which of three lossless JPEG codecs is this supposed to mean? --Damian Yerrick (☎) 17:43, 1 January 2007 (UTC)

I've reverted that edit. AFAIK it's a general thumbnail problem not a PNG problem. --Nux (talk··dyskusja) 23:54, 1 January 2007 (UTC)

Argument to Host Source Material

I’m creating a wikibook on roulette, and I’m creating a lot of images in Adobe Illustrator. I can just host the images here, and that’s all well and good, but it seems to me it would be a LOT more useful to people for me to be able to upload the source .ai file for all the pictures I created. There are about 60 layers and it would be a royal pain if someone tried to recreate it.

If the intention is for people to have free access to content and especially to allow derivative works, then it seems to me that mission is best accomplished by making not only the images available but the source as well.

Film8ker 01:18, 24 January 2007 (UTC)

We do that for the GIMP. I rather doubt we'll start doing it for any proprietary format like Adobe Illustrator though. --pfctdayelise (说什么?) 02:26, 24 January 2007 (UTC)

Isn't that a vector format? Why shouldn't it be easily exportable to SVG? I know that an earlier version of .ai file format was a subset of PostScript... AnonMoos 03:09, 24 January 2007 (UTC)

It seems that nobody here is able to fix the problem. At least, no such person ever comments on this talk page, and there is no obvious list of people to appeal to. There are numerous unopposed requests on this page which never get granted. Our comments are futile. Depressing, isn't it? AlbertCahalan 03:19, 16 February 2007 (UTC)

They simply cannot be granted. AFAIK no properitary formats can be used. And even if there are some unproperitary formats, then you should probably report to bugzilla rather then here. --Nux (talk··dyskusja) 08:34, 16 February 2007 (UTC)

Support for new file type come in two varieties:

1. simply granting upload. This requires reliable detection of the file type, the file format to be free and documented, and reasonably safe against malicious content. This may require some code changes.
2. support for image thumbnailing. This usually requires complex code changes, additional software to be installed on the servers, caching strategies, testing for resource efficiency, etc.

So, you see, allowing additional formats doesn't just mean flipping a switch. It needs a software developer to look at it, as well as approval from server admins. Both can be requested on bugzilla, but are generally only looked at seriously if there is popular demand for it on a project. To document such demand, it would probably be better to ask at COM:VP, since this page here isn't much watched by "normal users". -- Duesentrieb^(?!) 10:21, 16 February 2007 (UTC)

I also don't agree in using proprietary formats on the Commons. It's not good for the project that you have to buy a certain program, or use a certain Operating System to be able to edit and modify those files. --OsvaldoGago 12:00, 16 April 2007 (UTC)

But sometimes you do have to "use a certain Operating System" when programs that run on Linux have not been ported elsewhere. Or has e.g. Cinelerra been ported to Windows? --Damian Yerrick (☎) 12:13, 16 April 2007 (UTC)

I agree that proprietary formats should be uploadable for open source purposes. In the meantime, it would be best to upload them to an external site and link to them. — Omegatron 19:40, 16 April 2007 (UTC)

Commons doesn't even let people upload the transparent copy in a Free format, let alone a proprietary format. Shouldn't the developers tackle Free formats first, such as the subset of .doc that wv accepts? --Damian Yerrick (☎) 01:20, 18 April 2007 (UTC)

LaTeX files

I have the same issue like Film8ker. I just uploaded PDF files and I can't upload also the LaTeX file which is the source file for these. Let's allow source files, too. -- Mms 21:13, 27 January 2007 (UTC)

I think you can put latext files directly in wiki articles (probably the best place would be wikisource). Just use <pre></pre> tags around the code and it should display fine. --Nux (talk··dyskusja) 18:57, 16 February 2007 (UTC)

GIF: "lossless"?

The statement that "GIF [is a] 'lossless' [format]" is NOT entirely true--or certainly can be easily misinterpreted by those who don't know the details about it. The statement (to the uninitiated) might appear to endorse the idea that if an image is "Save[d] as" a GIF, there will be no data loss. Of course, those of us who already understand GIFs realize that this is simply not true: there will be no data loss AMONG UP TO 256 COLORS. Converting an image (esp. a photograph-type image) *to* GIF is (potentially) VERY LOSSY. (Once it gets INTO GIF format, of course, it isn't lossy; but let's be clear about the former point.)

For a first-time reader of this page, I think it would be better to clarify the issue.

Feedback? Discussion? (Does someone want to just jump in and fix it?)

Philiptdotcom 18:13, 2 March 2007 (UTC)

GIF makes no claim to encode >256 colors. For the data-types which it was intended to represent, such representation is always lossless. AnonMoos 20:36, 2 March 2007 (UTC)

Many newcomers are not aware that "GIF makes no claim to encode >256 colors". --Damian Yerrick (☎) 21:30, 18 March 2007 (UTC)

If their image-manipulation software doesn't clearly warn them that they're taking an irreversible step when they try to save 24+ bit RGB color data as a 8-bit GIF image, then the software is buggy -- it's not a problem with GIF itself. AnonMoos 02:55, 20 March 2007 (UTC)

For people who don't know jpeg from gif, number of colors doesn't mean much to them. Classification is needed for clarity reason and to reduce the chance of "misunderstanding" or "misrepresentation" to the public.

I rewrote the paragraph, I hope it's clearer now. -- Duesentrieb ⇌ 16:41, 18 March 2007 (UTC)

Yes, thanks, it's much clearer now. I wonder, however, about the assertion that GIFs should ONLY be used for animations. GIF seems to do a great job (lossless, within color limitations--and a great compression ratio under certain circumstances). No doubt SVG has similar (and even perhaps other) advantages (I don't have experience with this format), but seems like it should be okay to use GIFs for appropriate images (esp. since GIF is so common). The statement now is seemingly that, "no, if you have a non-animated GIF, you should change it to SVG before posting"; not really true, is it? Philiptdotcom 19:38, 18 March 2007 (UTC)

PNG does a better job with all but the very smallest still images. --Damian Yerrick (☎) 21:30, 18 March 2007 (UTC)

Unfortunately, Wikimedia software does a poor job of thumbnailing PNG images. AnonMoos 19:05, 19 March 2007 (UTC)

Open Document Format

Why are Open Document formats (e.g. those created with OpenOffice.org or NeoOffice 2.x) still not allowed on Commons? Its an open format and recently accepted as an ISO standard. I think the best would be to allow both OpenOffice 1.x and 2.x file types or at least keep the OO 1.x ones while encouraging their authers to replace them with equivalend ODF files.--SiriusB 14:36, 24 April 2007 (UTC)

I second that. --Biekko 14:54, 1 May 2007 (UTC)

Error creating thumbnail: Invalid thumbnail parameters

After uploading a 7150 × 4310 pixel png image, file size: 1.32 MB, I get the above error message. I get the same message when I try the gif version of the same file. I notice, from a google search of Wikipedia, that others have had this problem. Could it and a solution be listed on this page under ERRORS? --Bejnar 21:36, 11 May 2007 (UTC)

As a matter of policy (for about a year now), GIF and PNG images with dimensions greater than about 12 megapixels are not resized. The limit doesn't apply to JPEG images. AnonMoos 10:27, 12 May 2007 (UTC)

Why is that policy in place? —Remember the dot ^(talk) 20:15, 23 August 2007 (UTC)

Because it was taking up large amounts of processor time and disk space to do so. The message announcing the change is in one of the old mailing-list archives, but I don't have the URL handy right now... AnonMoos 02:12, 24 August 2007 (UTC)

P.S. It's http://lists.wikimedia.org/pipermail/wikitech-l/2005-October/019681.html -- AnonMoos 13:35, 17 April 2008 (UTC)

Gnumeric

Please enable support for Gnumeric files. Gnumeric is better at graphing than OpenOffice, and it has native SVG export functionality. It is also much faster and more lightweight. I want to be able to upload Gnumeric files which are the original data sources for SVG graphs on Commons. Andrew pmk 10:44, 16 June 2007 (UTC)

I'm not entirely sure what the purpose of this would be. The underlying data can presumably be exported in simple plain-text CSV form for maximum portability. You could cut-and-paste the CSV into the image description page, if you like... AnonMoos 00:49, 17 June 2007 (UTC)

I cannot see any reason for not allowing it.--SiriusB 11:22, 17 April 2008 (UTC)

Drop Support for GIMP's XFC on Commons

It makes no sense to provide content under this format, albeit it is an Open Media one. GIMP's own developers recommend not to "use XCF as a data interchange format since the format reflects the GIMP's internal data structures, and there may be minor format changes in future versions".--Saoshyant (talk, contribs) 19:46, 21 August 2007 (UTC)

What should we use instead? — Omegatron 08:11, 23 August 2007 (UTC)

Use? You mean image format? PNG does just fine. The only thing I see on XFC that may be useful to Commons is support for layers. Is there a demand for that?--Ivo (talk, contribs) 19:05, 28 August 2007 (UTC)

Yes. The GNU Free Documentation License and some other copyleft licenses require those who distribute a covered work under some conditions to make available a "transparent copy". One reading of the definition of "transparent copy" appears to require that layering be kept intact. Other than XCF, what file format preserves layers, which could be considered the "source code" of a bitmapped image? --Damian Yerrick (☎) 00:28, 29 August 2007 (UTC)

I see. Maybe the best solution would be to allow it only for GFDL material.--Ivo (talk, contribs) 17:51, 3 September 2007 (UTC)

VRML and X3D

Would it be possible to allow adding VRML and/or X3D files?

Both have public specification and numerous open source implementations, en:VRML does not mention any patents, en:X3D too (and it is ISO standard), so I assume there are no patents involved (though I can't guarantee it)

Sometimes adding 3D models or 3D worlds may be useful.

--Qiq cs 16:01, 17 September 2007 (UTC)

That raises the issue of whether the 3D files would be previewed or rendered in Wikimedia software, and how it would be done. File formats which can be given some concrete visual form by Wikimedia software itself (without the need for external programs to preview) are somewhat preferred... AnonMoos 17:23, 17 September 2007 (UTC)

SVG can be converted to PNG for sake of previews or for SVG-incapable browsers, stripping down the quality. So could be VRML/X3D (just only starting frame or some normalized position of the model as sort of preview would be shown for VRML-incapable browsers). Same situation is with video (browsers also can't handle them by themselves and need axternal plugin) and uploading video clips is allowed here. And sometimes a 3D model can be more explanatory than a lengthy video. --Qiq cs 18:42, 17 September 2007 (UTC)

If you can point to a Java-based (or possibly, Flash) open source plugin that renders these files, it would greatly increase the odds of getting them accepted here. pfctdayelise (说什么?) 12:59, 21 November 2007 (UTC)

I write my diploma about VRML, but unfortunally I can't see that it is a future trend[6]. The other problem I see is the necessary 3D grafic support(OpenGL). --Kolossos 21:25, 21 November 2007 (UTC)

I see great application for 3D formats in area of chemical structures. Should be real eye-candy. --EugeneZelenko 15:20, 29 November 2007 (UTC)

Open Document once more

About nine months have passed since the last request for allowing OpenOffice 2 (.od*) file types on Commons. Apparently nothing has happened since then. What I would like to know: Is there any good reason not to allow these (ISO standardized!) formats on Commons?--SiriusB 22:36, 18 January 2008 (UTC)

OpenDocument now classified as Malware???

I am rather confused to notice that not even OO2 file types (Open Document Format) are still not allowed but also OO1 file types have been removed from the whitelist. Note that ODFs are among the most powerful formats, since e.g. spreadsheets allow easy calculation and tabulation of complex formulas that otherwise would require the implementation of text formulas into a self-written program by the reader.

WTF is the reason for this? What in general is the reason for not allowing all (or at least all free) popular media formats? For now, I must notice, that Wikimedia commons has now lost much of its usefulness. BTW who is responsible for these decisions? What are the criteria? I have never found any public discussion about this (apart from here) nor any transparent decision process or any hint where to look for that.:-(--SiriusB 10:58, 17 April 2008 (UTC)

Raise the issue on Commons:Village pump, and if you get a generally favorable reception there, but it doesn't lead to any concrete action, then file a formal bug report, pointing out the support for the idea at Commons:Village pump... AnonMoos 14:07, 17 April 2008 (UTC)

Pristine original data

"there is currently no legitimate way to store pristine original data for conversion to future formats"

Ogg FLAC is lossless. Convert to that and there are no problems.

Note that this is now supposed to use the .oga extension, though. .ogg is only for Ogg Vorbis. — Omegatron (talk) 19:44, 20 April 2008 (UTC)

Images with less than 256 colors

There is no need to convert GIF graphics with less than 256 colors to PNG. It may be useful to convert some of them to SVG, but not to PNG.

Also, PNG is terrible for clickable image maps in most cases because of the previously-discussed PNG scaling problem with the MediaWiki software. See Template talk:BadGIF. An unscaled clickable PNG image map may work out fine. But a scaled clickable PNG image map can be much higher in kilobytes. As in 100 kilobytes versus 500 kilobytes. In that case it may actually be better to create a GIF version of the map for this particular use. Even if less colors are used. --Timeshifter 21:49, 12 May 2008 (UTC)

APNG

APNG is not on the same level as GIF, because most web-browsers don't display APNG files as animated, and presumably Wikimedia software does not handle the special features of APNG when resizing images... AnonMoos (talk) 10:53, 30 June 2008 (UTC)

Executable formats (Java, Adobe Flash)

I am curious that there's no mention either of permission or prohibition of "executable" formats, like w:Java or w:Adobe Flash. I guess that anything not listed in the permission list is forbidden, right? Albmont (talk) 13:57, 1 October 2008 (UTC)

Java currently has no real perceived need or usefulness for Wikipedia or other Wikimedia projects, while SWF is a proprietary format (until just a few months ago, a closed proprietary format). AnonMoos (talk) 14:21, 1 October 2008 (UTC)