Commons:Dateitypen

From Wikimedia Commons, the free media repository
(Redirected from Commons:Dateitypen)
Jump to navigation Jump to search
This page is a translated version of a page Commons:File types and the translation is 100% complete. Changes to the translation template, respectively the source language can be submitted through Commons:File types and have to be approved by a translation administrator.

Shortcut: COM:FT

Wikimedia Commons akzeptiert ausschließlich freie Inhalte. Zusätzlich sind diese auch allein in freien Dateiformaten erlaubt.

Patentbehaftete Dateiformate werden auf Wikimedia Commons nicht akzeptiert. Für eine Liste der erlaubten Formate siehe die Abschnitte unten. Beispiele für patentbehaftete Dateiformate sind AAC, WMA und die meisten AVI-Codecs. Unser Projektziel erfordert es, dass Inhalte frei an alle weitergegeben werden können. Patentbehaftete Formate erfüllen diese Maßgabe nicht.

Unfreie Formate und nicht unterstützte freie Formate müssen vor dem Hochladen in ein unterstütztes freies Format konvertiert werden. Zum Glück ist dies in der Regel nicht schwierig, kann aber zeitaufwändig sein (je nach Format und gewünschter Ausgabequalität).

Bilder

Die empfohlenen Dateitypen auf Wikimedia Commons sind SVG, PNG und JPG.

BMP-Dateien sind auf Commons nicht erlaubt. Diese können verlustfrei in PNG konvertiert werden, und die Dateigröße ist immer kleiner.

Größe und Skalierung

Siehe auch: Commons:Maximale Dateigröße

Beachte, dass eine neuere Software zur Änderung von PNG installiert wurde, seit der folgende Text geschrieben wurde.

Leider unterliegt die dynamische Skalierung der Bilder gewissen Einschränkungen. In der Regel werden bei PNG und JPG die Miniaturbilder in einer Farbtiefe von 24 Bit generiert. Bei GIFs besitzt die Miniatur 256 Farben, das ist der maximale Wert, den das GIF-Format ermöglicht. In der Praxis bedeutet das, dass die Skalierung von PNG-Bildern relativ große Dateien erzeugen kann, selbst wenn die Ursprungsdatei eine kompakte indizierte Farbpalette verwendet oder nur Graustufen enthält. Das bedeutet auch, dass man, wenn man eine verlustfreie PNG-Datei hochladen will, aber JPG-Miniaturen in Artikeln nutzen will, zusätzlich eine JPG-Datei in Originalgröße und höchster Qualität manuell hochladen muss.


Beachte, dass die Bilderskalierung fehlschlagen kann, wenn das Bild sehr groß ist und das Rendern zu viel Zeit oder Speicher beansprucht. (In diesem Fall wird kein Vorschaubild dargestellt oder das große, vollständige Bild wird an den Browser ausgeliefert, was zu einer Blockade führen kann.) Für GIF-Dateien existiert eine feste Größenbeschränkung von 1,000 Megapixeln.[Note 1] Große JPEG-Dateien sind gewöhnlich nur problematisch, wenn sie im progressiven Modus abgespeichert werden, nutze stattdessen den Basismodus (siehe Progressive JPEGs [englisch]).


Höchste Auflösung

Shortcut

Bitte hilf trotzdem, dass Inhalte von Commons möglichst breit genutzt werden können – inklusive der gedruckten Medien –, indem Fotografien in hoher Auflösung hochgeladen werden. In Fällen, in denen die höchste Auflösung Probleme erzeugt, wie sie oben aufgeführt sind, kann eine Version in geringerer Auflösung mit einem anderen Namen hochgeladen werden (mit Erwähnung des Bildes mit der höheren Auflösung in der Beschreibung) oder als neuere Version der Datei. Weitere Informationen findest du unter Commons:Why we need high resolution media. Am anderen Ende der Skala begrenzt Special:AbuseFilter/153 das Wiki-übergreifende Hochladen von kleineren (<50.000 Bytes oder <2.000.000 Pixel) jpg-Dateien durch neue Benutzer.

SVG

Siehe auch Hilfe:SVG und Wikipedia:WikiProjekt SVG.

SVG ist ein XML-basiertes Vektorgrafik-Format, das nach Belieben skaliert werden kann, ohne verschwommen oder „pixelig“ zu werden. Es ist einfach zu bearbeiten und erzeugt in der Regel relativ kleine Dateien (siehe File:Bitmap VS SVG.svg). SVG sollte bevorzugt zur Erzeugung von Diagrammen, Flaggen usw. benutzt werden, während PNG besser für eingescannte Bilder und Fotografien in Druckqualität geeignet ist. Siehe Hilfe:SVG.

SVG funktioniert gut bei der Erstellung von Diagrammen, Illustrationen, Karten und Grafiken aller Art, die Beschriftungen benötigen. SVG kann die Beschriftungen als Textzeichenketten abspeichern, Beispielsweise wurde die Karte File:Caucasus-ethnic en.svg unten in mehrere Sprachen übersetzt. Vergleiche die bessere Bildqualität der SVG-Karte in verschiedenen Größen mit der JPG-Karten. (Die unten gezeigten Bilder sind in Wirklichkeit im PNG-Format. SVG-Bilder werden in Wikipedia nicht an die Browser ausgeliefert, sondern MediaWiki konvertiert das SVG-Bild in ein PNG-Miniaturbild und liefert dieses aus.)

PNG

PNG ist ein verlustfreies Format (das Alphatransparenz unterstützt). Das bedeutet, dass die genaue Farbe des Pixels beim Speichern erhalten bleibt und ist für jede art von Zeichnungen/Diagrammen geeignet, die nicht im SVG-Format verfügbar sind (SVG ist bevorzugt zu Erzeugung von Diagrammen etc.). PNG ist gut für praktisch alles außer Fotografien. PNG ist besser für eingescannte Grafiken (beachte jedoch unten den Hinweis zum Schärfen), Bilder in geringer Farbtiefe, nicht jedoch für Fotografien in und andere Grafiken in Druckqualtität.

In Wikipedia (und alle anderen MediaWiki-Installationen, wie in phab:T192744 diskutiert) werden nur JPEG-Miniaturen nachgeschärft, nicht aber PNG-Miniaturen. Bei komplizierten Bilder, wie Fotografien, Stichen und Ähnlichem, ist das erzeugte Miniaturbild einer PNG-Datei in minderer Qualität. Das Hauptproblem mit JPEG als verlustbehaftetem Format ist jedoch, dass die Dateien nicht wiederholt bearbeitet werden können, selbst bei besten Qualitätseinstellungen. Deshalb empfiehlt es sich, auch wenn die Miniaturbilder relativ minderwertig aussehen, zusätzlich eine PNG-Datei hochzuladen und die PNG- und JPEG-Versionen mit einem Link zu verbinden unter Nutzung der Vorlage {{PNG with JPEG version}}. Eine Ausnahme liegt dann vor, wenn das Original bereits im JPEG-Format vorliegt; in diesem Fall gibt es keinen Grund, zusätzlich eine PNG-Kopie anzubieten. Wenn man aber die JPEG-Datei bearbeitet, ist es keine schlechte Idee, vor dem Schließen des Programms, mit dem man das Bild bearbeitet hatte, eine PNG-Kopie abzuspeichern; diese bietet anderen die Möglichkeit, weitere Bearbeitungen vorzunehmen, ohne dass die Qualität immer schlechter wird. Siehe für einfachere Bilder auch Wikipedia:How to reduce colors for saving a JPEG as PNG (englisch) – wenn das Bild relativ simpel ist, besitzen solche einfacheren Bilder häufig eine geringere Dateigröße als im JPEG-Format.

Exif-Daten

Es ist sehr wichtig, sich daran zu erinnern, dass es in PNG keine geeigneten Exif-Daten gibt.[Note 2] Wenn Du also ein Bild hochladen willst, das in einem RAW-Format aufgenommen wurde, dann speichere es im JPEG-Format aus der Rohbilddatei und lade, wenn Du es möchtest, auch eine PNG aus der Rohbilddatei hoch. Wenn Du aber das Foto unter Beibehaltung der Exif-Daten retuschieren willst, ist der professionelle Weg, die ursprüngliche Rohbilddatei oder eine PNG-Version zu bearbeiten, sie im JPEG-Format zu speichern und die Exif-Daten von der Rohbilddatei in das endgültige JPEG zu kopieren. Es gibt keinen alleinigen Standardweg, es richtig zu machen, andere Mitwirkende werden helfen, wenn dein Programm etwas erzeugt, das eindeutig falsch ist (UTF-8 außerhalb des iTXT-Chunks oder Ähnliches).

Siehe auch Commons:Preparing images for upload, PNG tips (englisch).
Prozentwerte der Dateitypen auf Commons, Stand September 2017

JPEG

JPEG (auch JPG) ist geeignet für Fotografien, vor allem wenn diese bereits im JPEG-Format vorliegen. JPEG nutzt eine verlustbehaftete Kompression, die Präzision zugunsten geringerer Dateigröße opfert.

Wenn man selbst entscheiden kann, in welchem Format eine Grafik, ein Scan oder Ähnliches abgespeichert werden soll, dann sollte PNG verwendet werden (oder man speichert in einem anderen verlustlosen Format wie TIFF und konvertiert anschließend zu PNG) und in diesem Foramt hochgeladen werden. Wenn das Original jedoch im JPEG-Format ist, hat es generell keinen Sinn, in PNG zu konvertieren: Von einem Format mit verlustbehafteter Kompression in ein verlustfreies Format zu konvertieren ergibt überhaupt keinen Vorteil, weil der Verlust bereits im Original erfolgte; stattdessen würde nur die Dateigröße ansteigen (jede Änderung an der Datei sollte jedoch sowohl als JPEG und als PNG abgespeichert werden). Eine Ausnahme davon sind JPEGs in sehr hoher Auflösung ohne sichtbare Kompressionsartefakte. Das Konvertieren in PNG wird vermeiden, dass die Miniaturbilder zusätzliche Artefakte enthalten.

Beachte, dass zur Zeit JPEG-Miniaturen eine zusätzliche Schärfung erhalten, während das für PNG-Miniaturen nicht der Fall ist. Daher kann es ein gute Idee sein, Kopien in beiden Formaten hochzuladen, wenn das PNG-Miniaturbild ein wenig unscharf aussieht. Benutze {{JPEG version of PNG}} in der JPEG-Kopie einer PNG-Datei, die selbst mit {{PNG with JPEG version}} markiert wurde.

PNG ist ein verlustfreies Echtfarben-Format. JPEG ist immer ein verlustbehaftetes Format selbst in den höchsten Qualitätseinstellungen. Verlustfreie Formate werden qualitativ nicht schlechter, wenn man sie wiederholt abspeichert, bei verlustbehafteten aber ist dies der Fall: wenn man jedoch eine verlustfreie Version der Datei besitzt, erlaubt diese, dass man sie ohne Qualitätsverlust für verschiedene Zwecke nutzen kann, wie etwa das Ausschneiden, eine Ebenenanpassung usw.

Siehe auch Help:JPEG und Hilfe:Scannen[Note 3]

GIF

Das Miniaturbild dieser GIF-Datei ist wegen der Handhabung der Transparenz problematisch.
Die PNG-Skalierung hat dieses Problem nicht.

PNG ist GIF für nichtanimierte Bilder (kleinere Dateigröße, mehr Farben, bessere Transparenz) fast immer überlegen. Wenn man eine Grafik (nicht eine Fotografie) erzeugt oder bearbeitet und entscheiden kann, in welchem Format man abspeichern kann, dann ist in Wikipedia/Wikimedia SVG die erste Wahl, danach PNG. Speichere niemals ein Bild mit mehr als 256 Farben im GIF-Format. GIF speichert immer mit 256 Farben oder weniger. Das Konvertieren von Bildern mi mehr Farben in das GIF-Format wird deren Qualität verschlechtern.

GIF-Dateien zu bearbeiten kann schwierig werden, denn GIF unterstützt nur eine 8-Bit-Farbpalette und die meisten Filter funktionieren nur mit der vollen Palette. Zusätzlich unterstützt PNG 8-Bit-Transparenz (Alphakanal), während GIF nur 1-Bit-Transparenz beherrscht. Auch gibt es gewisse Eigentümlichkeiten beim Skalieren von GIF-Dateien; insbesondere tritt dies beim Skalieren von Bildern mit Hintergrundtransparenz auf – der transparente Bereich „frisst“ sich in den nicht-transparenten Bereich hinein, was zu Problemen führen kann.

Wenn Du qualitätsvolle, frei lizenzierte GIF-Grafiken, -Diagramme, -Karten, -Illustrationen usw. findest und glaubst, dass sie nützlich für die Wikipedia oder eines ihrer Schwesterprojekte sein könnten, zögere nicht, sie so nach Commons hochzuladen, wie sie sind. Du oder andere können sie später in SVG konvertieren, wenn es nötig ist.

Siehe Commons:Chart and graph resources für Hilsmittel und Hilfe.

Animatiertes GIF

GIF ist ein verlustfreies Format mit 8 Bit Farbtiefe (maximal 256 Farben) und sollte auf Wikimedia Commons hauptsächlich für animierte Bilder verwendet werden. Für animierte Bilder nutzt GIF eine verlustfreie Kompression bei bis zu 256 Farben je Frame.

Animierte GIF haben manchmal Probleme, wenn aus ihnen ein Miniaturbild erzeugt wird. Wenn eine Animation in der Miniaturversion defekt oder verzerrt zu sein scheint, dann kann man versuchen, jeden Frame in derselben Größe abzuspeichern: Eine übliche Optimierungsmethode für animierte GIF ist es, Frames in unterschiedlicher Größe abzuspeichern, manchmal tituliert als „nur die Teile der Frames speichern, die sich geändert haben“. Die aktuelle Version von ImageMagick, die in Wikimdia zum Einsatz kommt, scheint das nicht zu unterstützen. Es gibt derzeit ein Größenlimit von 100 Megapixeln in der Mediawiki-Software; bitte beachte die Anmerkungen in Category:Animated GIF files affected by MediaWiki restrictions (englisch).

Wenn die Datei lang genug ist (mehr als 10 Sekunden), solltest du eines der unten aufgeführten Videoformate verwenden: Das Video kann pausiert und zurückgespult werden. FFmpeg kann verwendet werden, um ein GIF in ein Video zu konvertieren.

Animationen im Text sollten sehr sparsam eingesetzt werden; ein statisches Bild mit einem Link zur Animation wird bevorzugt, es sei denn die Animation besitzt eine sehr geringe Dateigröße. Denke an die oben erwähnten Probleme mit der Kompatibilität beim Drucken.

TIFF

Nur einige Varianten von TIFF können derzeit in skalierter Form (als Vorschaubild) innerhalb von MediaWiki angezeigt werden – TIFF wird von den meisten Internet-Browsern nicht unterstützt. TIFF ist als ein Archivierungsformat vorgesehen und sollte nie für Bilder verwendet werden, die für die Anzeige in Artikeln gedacht sind.

TIFF dient meist als ein verlustfreies Format, ähnlich PNG, aber mit viel weniger Kompression; allerdings ist sein Standard-Kompressionsalgorithmus sehr schnell (was ein Vorteil auf älteren Computern war). Der Großteil der Scanner-Software unterstützt TIFF, so dass es die bevorzugte Wahl zum Archivieren ist.

PNG wird meist von der Scanner-Software nicht unterstützt, PNG-Dateien können aber generell in einer viel geringeren Dateigröße abgespeichert werden als TIFF-Dateien. Beispielsweise wird eine 33 MB große TIFF-Datei auf 17 MB verkleinert, wenn sie als PNG abgespeichert wird.

Alles in allem ist PNG das bevorzugte Format; jedoch wird die Möglichkeit, TIFF-Dateien hochzuladen, als Gefälligkeit angeboten. Wenn beispielsweise man Dateien im Batchmodus eingescannt hat, um sie nach Commons hochzuladen, damit sie von anderen weiterbearbeitet werden können, wird man ein verlustfreies Format nutzen wollen (ein verlustbehaftetes Format verursacht bei jeder Speicherung eine Vermehrung der Artefakte). Die Scanner-Software unterstützt womöglich kein PNG, aber erlaubt TIFF. In solchen Fällen ist es akzeptabel, ein Bild als TIFF-Datei hochzuladen, weil das hilft, sehr viel einfacher Material in Commons bereitzustellen (in diesem speziellen Fall wäre es angebracht, die anderen Nutzer in Village Pump zu informieren, damit der Massenupload für eine größere Weiterverbreitung vorbereitet werden kann und eventuell einige Dinge kurz im Vorfeld zu diskutieren). Es existieren viele Bildeditoren (sowohl freie als auch kommerzielle), die in der Lage sind, eine Konversion von TIFF in ein anderes Format durchzuführen. Siehe auch en:Comparison of raster graphics editors #File support (englisch).

Die obigen Ausführungen sind für die meisten TIFF-Dateien, gültig; beachte jedoch, dass TIFF ein etwas eigenartiges Format ist – die Spezifikationen sind sehr weit gefasst und können in der Theorie ein breites Spektrum an Kompressionsalgorithmen und Dateieneinbettung unterstützen (wobei die meisten Programme, die TIFF-Dateien öffnen können, nur die weitgehend üblichen unterstützen). Das macht es schwierig, definitive Aussagen über TIFF zu treffen: Zum Beispiel können TIFFs JPEGs enthalten, die kein verlustfreies Format darstellen. Generell sollten nur TIFF in den Standardtypen nach Commons hochgeladen werden.

WebP

Das Bildformat WebP wird in Commons unterstützt. Es unterstützt sowohl verlustbehaftete Bildkomprimierung auf der Grundlage von VP8 als auch verlustfreie Bildkomprimierung auf der Grundlage eines neuen Algorithmus. Der verlustfreie Modus ist kompakter als PNG.

XCF

XCF kann sinnvoll sein, wenn man mit GIMP an einem Bild arbeitet. Anders als PNG und ähnliche Formate unterstützt XCF Text und mehrfache Ebenen. Es kann sinnvoll sein, eine XCF-Datei hochzuladen, damit andere Bearbeiter direkt unter Erhalt der Ebeneninformation weiterarbeiten können. Bitte beachte, dass von einer XCF-Datei ein Vorschaubild durch die MediaWiki-Software nur erzeugt werden kann, wenn das Dateiformat mit GIMP 2.6 oder 2.8 kompatibel ist und der Farbmodus RGB oder Graustufen ist. Mit anderen Worten: Bilder mit indizierten Farben werden vom MediaWiki-Thumbnailer nicht unterstützt; ebenso wenig wie Dateien, die mit GIMP 2.10 erstellt wurden (siehe T196054)

Audiodateien

Siehe auch: Commons:Freie Medienressourcen/Sound Die in Wikimedia Commons erlaubten Dateiformate sind: MP3, Ogg (mit den Codecs FLAC, Speex, Opus oder Vorbis), WebM (mit Vorbis-Codec), FLAC, WAVE oder MIDI.

Unfreie Formate und weniger bekannte freie Formate müssen vor dem Hochladen konvertiert werden – es existiert derzeit keine legitime Möglichkeit, die ursprünglichen Originaldaten für eine Konversion in zukünftige Formate oder für die Verwendung nach Ablauf der Patente zu speichern, auch wenn die Lizenz eines bestimmten Werkes die Verbreitung solcher ursprünglichen Originaldaten erfordert (wie es häufig der Fall ist für Werke, die unter der GNU-Lizenz für freie Dokumentation, GFDL oder einer anderen Copyleft-Lizenz stehen).

Commons akzeptiert keine Tracker-Formate, selbst solche von freien Trackern. Ebenso akzeptiert es keine SoundFonts, um sie mit MIDI-Dateien zu benutzen, selbst solche, die für freie MIDI-Player entwickelt wurden. Wenn es wichtig ist, dass eine Musikpassage mit spezifischen Instrumentationsdefinitionen gehört wird, was General MIDI nicht bietet, und die Lizenz erlaubt es, dann nutze die Tracker-Software, um die Passage in RIFF-WAVE zu rendern, und konvertiere dieses anschließend nach Ogg-Vorbis.

Stand Juni 2023 können die meisten Browser MP3, Ogg-Vorbis und Opus abspielen, aber kein MIDI, FLAC oder Speex. FLAC und Speex werden nach dem Hochladen für die Wiedergabe in Browsern automatisch in die Vorbis- und MP3-Transcodecs konvertiert.

MP3

MP3 ist ein weithin unterstütztes Audioformat und wird dringend empfohlen, wenn eine Ogg-Datei oder verlustfreie Version nicht gefunden werden kann. Commons akzeptiert derzeit nur MP3-Dateien von Benutzern mit Autopatrol oder höheren Rechten, da Bedenken hinsichtlich der Fähigkeit der Gemeinschaft zur Überwachung von Urheberrechtsverletzungen bestehen.

MIDI

MIDI-Dateien werden akzeptiert, aber nicht sehr gut unterstützt. Die Dateiendung muss .mid sein.

Ogg (Audio)

Opus ist der bevorzugte Audiocodec für den Ogg-Container. Bitte verwende den Dateityp opus oder oga, um Audiodateien im Ogg-Opus-Format hochzuladen.[Note 4]

Opus wird seit 2014 von MediaWiki (phab:T42193, phab:T53313) unterstützt. Das Format zeichnet sich durch hervorragende Qualität und geringe algorithmische Verzögerung aus, schaltet automatisch zwischen sprach- und musikoptimierten Modi um und kann beide kombinieren. FLAC ist für allgemeine Audiodateien geeignet und ist verlustfrei (die Qualität bleibt erhalten), aber die derzeitige Beschränkung der Dateigröße verhindert die Verwendung für alles außer kurzen Clips. In den meisten Fällen sollte Opus mit den von Xiph empfohlenen Einstellungen verwendet werden.[Note 5]

Vorhandene Audiodaten in anderen freien Codecs (wie Speex und Vorbis), die jedoch in einem Ogg-Container vorhanden sind, sollten nicht nach Opus oder FLAC konvertiert werden, um Generationsverlust zu vermeiden.

Beachte, dass mit FLAC ein natives Containerformat existiert (siehe unten). Wenn Ausgabedatei die Erweiterung .flac hat, wird wahrscheinlich das native Containerformat verwendet. Wenn man es in einen Ogg-Container einbetten will, kann man das mit ffmpeg und der folgenden Kommandozeile tun: ffmpeg -i InputFile.ext -acodec flac out.oga oder flac ./input.wav -8 --ogg -f ./output.oga.[Note 4] (Dies ist weder erforderlich noch empfehlenswert.)

Es ist auch sinnlos, Daten in einem unfreien Format in einen freien Container wie Ogg zu packen: Man erhält eine Datei, die einen Player erfordert, der, während er den freien Container unterstützt, trotzdem noch den unfreien Codec untersützen muss.

WebM (Audio)

Der WebM-Container kann Audiodaten enthalten (Vorbis oder Opus) sowohl mit, als auch ohne begleitende Videodaten.

FLAC

Der Free Lossless Audio Codec wird unterstützt sowohl mit, als auch ohne Einbettung in Ogg-Container. Die Erweiterung TimedMediaHandler wird automatisch transkodierte Varianten im Ogg-Format anbieten. Dateierweiterung ohne Einbettung: .flac. (Der entsprechende Phabricator-Task phab:T51505 wurde 2013 gelöst und 2014 geschlossen.)

WAVE

Wave-Container können unkomprimierte, verlustfreie Audiodaten (PCM) enthalten. Wenn möglich, bitte vor dem Hochladen in FLAC konvertieren. Dateierweiterung: .wav.

Videos

Videos müssen WebM-Dateien (mit Endung .webm), Ogg-Dateien mit Theora-Videocodec (mit Dateiendung .ogv[Note 4]) oder MPEG-1/MPEG-2-Dateien (.mpg und .mpeg) sein. Unfreie Formate müssen vor dem Hochladen konvertiert werden, siehe Commons:Video – Uploading a video (englisch) für Anweisungen. Siehe [[1]] für ein schnelles und leicht zu bedienendes Hilfsmittel.

Die Empfehlung von MDN Web Docs ist WebM, das VP9-Video mit Opus-Audio enthält. Can I use berichtet, dass etwa 92 % der Nutzer 2024 in der Lage sind, diese Kombination direkt zu verwenden, viel mehr als Ogg Theora (~8 %).[Note 6]

WebM (Video)

WebM unterstützt die VP8-, VP9- und AV1-Videocodecs und die Vorbis- und Opus-Audiocodecs. Das Containerformat WebM ist eine Untermenge des Matroska-Formats.

VP8 ist eine verlustbehaftetes Kompressionsformat, das eine bessere Qualität als das Theora-Format bietet. Natürlich gibt es keinen Grund, vorhandene Theora-Videos nach VP8 zu transkodieren, denn das wird den Verlust durch die vorherige Kompression in geringerer Qualität nicht ersetzen. WebM wird zwar von vielen Browsern unterstützt, aber solche Kompatibilitätsprobleme sollten durch automatische Transkodierung in der MediaWiki-Software behoben werden, nicht durch manuelles Neuhochladen.

VP9 ist ein Nachfolger von VP8 mit höherer Kompressionseffizienz.

AV1 ist ein Nachfolger von VP9 und bietet eine bessere Komprimierungseffizienz. Es soll sowohl in der Software, als auch in der Hardware eine viel breitere Unterstützung finden als frühere freie Videoformate. Im Jahr 2023 waren 78 % der Nutzer in der Lage, dieses Format abzuspielen; der Hauptblocker ist Safari, der AV1 nur auf Geräten mit einem Hardware-Decoder unterstützt.

Ogg Theora (Video)

Theora ist ein verlustbehafteter Videocodec, der 2004 veröffentlicht wurde. Er basiert auf VP3 aus einer Entwicklungslinie, die zu VP6/Flash und WebM-VP8/-VP9 führte. (Beachte, dass der Großteil der in Commons:Software erwähnten Programme in der Lage sein sollte, auch Ogg-Vorbis-Audio wiederzugeben.)

Ab 2023. Theora wird von den HTML5-Videoplayern moderner Browser schlecht unterstützt. Vermeide die Konvertierung in dieses Format.

MPEG-1 (Video)

MPEG-1 ist der 1993 veröffentlichte Video-CD-Standard, der die Standards MP2 und MP1 zur verlustbehafteten Komprimierung von Video und Audio umfasst. Er wurde entwickelt, um unbearbeitete digitale Video- und CD-Audiodaten in VHS-Qualität ohne übermäßigen Qualitätsverlust auf etwa 1,5 Mbit/s (26:1 bzw. 6:1-Komprimierungsverhältnis) zu komprimieren.

MPEG-2 (Video)

MPEG-2 ist der DVD-Standard, welcher MP2 einschließt, für „die generische Kodierung von bewegten Bildern und zugehörigen Audioinformationen“, erstmals 1996 veröffentlicht. Er beschreibt eine Kombination verlustbehafteter Videokompressions- und verlustbehafteter Audiodatenkompressionsverfahren, die die Speicherung und Übertragung von Filmen unter Verwendung der derzeit verfügbaren Speichermedien und Übertragungsbandbreite ermöglichen. Sowohl MPEG-2 als auch MPEG-1 sind Standards des digitalen Kabel-/Satellitenfernsehens und des digitalen Hörfunks (DAB).

Textformate

Eingescannte Textdokumente (DjVu, PDF)

Diese PDF-Datei enthält eine {{BadPDF}}-Markierung, weil die Darstellung unsauber aussieht (durch die JPG-Kompression), wenn die Datei als Artikelgrafik verwendet wird; dabei ist File:Amsterdam Museum logo.svg viel besser geeignet.

Obwohl auf Commons im Allgemeinen keine Dokumente gespeichert werden, gibt es stichhaltige Gründe, sie hier hochzuladen (etwa als archivierte Versionen für Abschriften auf Wikisource)

  • Siehe Help:DjVu, um Hilfe zu erhalten über PDF- und DjVU-Dateien.
  • Dokumente im PDF-Format sind erlaubt. Die Nutzung als Grafik wird nicht empfohlen, wie man am Beispiel rechts sehen kann, das eindeutig eine Grafik für ein Vektorformat ist. Zu zulässigen Gründen für das PDF- und DjVU-Format siehe Projektumfang, PDF- und DjVu-Formate.

Hinweis: Jede einzelne Seite einer PDF-Datei wird derzeit als JPEG-Vorschau gerendert, könnte aber auch als PNG gerendert werden. Das hängt allein von der Implementation des PDF-Renderers ab, der auf dem Server genutzt wird und ist keine Limitierung durch PDF im Vergleich zum DejaVu-Format. Die einzige Limitierung stellt die Existenz verschiedener proprietärer PDF-Erweiterungen dar, die manchmal einen spezifischen PDF-Betrachter verlangen. PDF-Dateien auf Commons sollten nicht von diesen Erweiterungen abhängen und nur die grundlegenden Spezifikationen nutzen, wie sie der Renderer für die Vorschaubilder von Commons verwendet. Das Problem mag allein dann auftreten, wenn eine PDF aus dem „Media:“-Namensraum heruntergeladen wird, statt als einzelnes Bild einer auswählbaren Seite der PDF gerendert zu werden (denn diese Erweiterung kann vielleicht aktives Skripting, ausfüllbare Formularfelder und aktive Links zu externen Seiten ermöglichen).

Für die Bildrenderung werden PDF-Dateien mit dem Basis-PDF-Profil gerendert (entsprechend der Standardspezifikationen); diese sind funktional äquivalent zu DejVu-Dateien, aber typischerweise werden Fotografien und Grafiken mit höherer Genauigkeit und akkurateren Farbprofilen gerendert als DejaVu-Dateien, die ein grundlegenderes Modell nutzen. PDFs bieten in einigen Fällen eine höhere Qualität, weil sie skalierbare Vektorgrafiken statt nur hochkomprimierten Pixelbildern in einer festen Auflösung einbetten können. Daher liegt der Unterschied vor allem in der Kompressionsstufe für Bilder: Bei eingescannten Texten sind DejaVu meist kleiner als PDF, aber dies macht jedoch keinen Unterschied, wenn diese Dateien nicht heruntergeladen, sondern nur als ein einziges Bitmap-Bild gerendert werden.

Für Dokumente, die farbige Grafiken und Fotos enthalten, bieten PDF häufig eine höhere Qualität. Die derzeit von Commons verwendeten Renderer für Miniaturansichten geben diese jedoch nicht deutlich wieder, da sie JPEG-Miniaturansichten anstelle der genaueren PNG-Miniaturansichten erzeugen: Dies könnte sich in Zukunft ändern, wenn bei phab:T38597 eine Einigung erzielt wird.

Angesichts zahlreicher Urheberrechtsverletzungen und des Hochladens von Dateien, die den Projektrahmen sprengen, erlauben wir neuen Nutzern nicht, PDF-Dateien hochzuladen.

Siehe auch Hilfe:Scannen für Hilfe zum Einscannen anderer Objekte, die keinen Text enthalten.

TimedText

TimedText ist ein spezieller Namensraum auf Commons, in dem Untertitel (englisch „Timed Text“; andere bekannte Bezeichnungen im Englischen: „subtitles, closed captioning, closed caption text“) gespeichert werden. Die Inhalte bestehen aus einfachem Text ohne jegliche Auszeichnung (englisch „Markup“).

Siehe Commons:Timed Text.

Dateien für Daten

Derzeit werden keine Datenbank-Dateitypen als Dateityp für das Hochladen auf Commons unterstützt. (Siehe unten die Liste der nicht unterstützten Dateitypen.)

Tabellarische Daten können jedoch im speziellen Data:-Namensraum gespeichert werden. Daten in diesem Namensraum können zum Beispiel enthalten:

  • Kartendaten, die es Nutzern erlauben, Daten im GeoJSON-Format zu speichern.
  • Tabellendaten, die es ermöglichen, CSV-artige Datentabellen zu speichern.

Dies unterstützt auch die Erstellung von dynamischem Text (über Lua-Module) und Graphen unter Verwendung von Daten im JSON-Format.

Datendateien in Commons müssen unter unter einer der Lizenzen CC0 1.0, CC BY-1.0, CC BY-2.0, CC BY-2.5, CC BY-3.0, CC BY-4.0, CC BY-4.0+, CC BY-SA-1.0, CC BY-SA-2.0, CC BY-SA-2.5, CC BY-SA-3.0, CC BY-SA-4.0, CC BY-SA-4.0+, ODbL-1.0, dl-de-zero-2.0 oder dl-de-by-2.0. stehen.

Das Experimentieren mit solchen Daten ist explizit erlaubt in Data:Sandbox/<Nutzername>/ und Unterseiten. Derzeit kann der Seiteninhalt nur im reinen JSON-Format editiert werden, es sei denn, jedes Feld hat den Typ 'number' oder 'string'. Um Data-Dateien zu kategorisieren, können Kategorien nur auf den zugehörigen Data-Diskussionsseiten hinzugefügt werden

Kartendaten

Für mehr Details siehe in mw:Help:Map Data (englisch).

Kartendaten erlauben es Nutzern, Daten im GeoJSON-Format abzulegen, ähnlich zu Bildern. In anderen Wikis können diese Daten genutzt werden, um etwas auf Karten zu zeichnen, zusammen mit anderen Änderungen an Karten, die unter Nutzung der Erweiterung Kartographer erfolgen.

Um neue Kartendaten zu erzeugen, lege im Namensraum Data: eine neue Seite mit der Endung .map an, beispielsweise Data:Sandbox/Example user/Example.map.

Tabellendaten

Für mehr Details siehe in mw:Help:Tabular Data (englisch).

Tabellendaten erlauben es Nutzern, CSV-artige Datentabellen abzulegen und sie in anderen Wikis zu nutzen, um automatische Tabellen, Listen und Grafendiagramme zu erzeugen.

Um eine neue Tablle zu erzeugen, lege im Namensraum Data: eine neue Seite mit der Endung .tab an, beispielsweise Data:Sandbox/Example user/Example.tab.

Konstruktions- und CAD-Formate

3D-Strukturen
STL für 3D-Dateien, das am häufigsten für den 3D-Druck verwendete Dateiformat. Andere 3D-Formate und andere CAD-Dateiformate werden nicht unterstützt. Siehe auch mw:Help:Extension:3D.

Andere Formate

Chemische und biologische Molekülstrukturen
Zur Zeit kein Format unterstützt. Siehe unten nicht unterstützte Dateitypen.
Kartenrouten und GPS-Daten
Siehe Kartendaten. Siehe auch unten #Unsupported free file types.

Unterstützung für neue Dateitypen beantragen

Ab 2021 gibt es kein Standardverfahren für die Beantragung von Unterstützung für neue Dateitypen. [2]

Das MediaWiki-Handbuch enthält eine Beschreibung zur Unterstützung für einen neuen Dateityp, in der einige Überlegungen zum Hinzufügen von Unterstützung auf Wikimedia-Websites erwähnt werden.

Als ersten Schritt solltest du diese Handbuchseite lesen und ein Ticket erstellen, in dem du um Unterstützung bittest und dabei auf dieses übergeordnete Tracking-Ticket verweist: Unterstützung von Multimediadateiformaten (Tracking). Du findest dort bereits Beispiele für offene und geschlossene Anfragen, die mit diesem Ticket verlinkt sind, und unten eine Zusammenfassung der Anfragen, die noch nicht unterstützt werden.

Nicht unterstützte Dateitypen

Nicht unterstützte freie Dateitypen

Mindestens einmal gewünscht, aber zur Zeit nicht unterstützt; Hilfe ist notwendig für eine Unterstützung. :-)

Jedes Format für 3D außer STL (die bereits unterstützt wird)
Jedes andere CAD-Konstruktionsmuster
Jedes Datenbankformat
Jedes Format für Chemische oder biologische Moleküle
Jedes Kartenrouten-/GPS-Format
Die wichtigsten offenen Dokumentenformate
Grafikformate
Audio-/Videoformate
  • ALAC (Apple) – phab:T34104
  • MKV-Containerformat – phab:T32653#347603 (WebM stellt eine Untermenge des Matroska-Formats dar und ist in Commons erlaubt, eine vollständige Unterstützung scheint aber nicht geplant zu sein.)
Diagrammformate
Formate für Multimedia und Animationen
  • SWF – könnte als frei betrachtet werden (seit 2009?), muss aber mit freien Hilfsmitteln bearbeit- und abspielbar sein – abgelehnt in phab:T28269
Wissenschaftliches Format
  • FITS – Flexible Image Transport System
Schriftformate

Unfreie Dateiformate

Mindestens einmal gewünscht, um eine automatische Konversion dieser Formate in ein freies Format während des Hochladens zu ermöglichen.

Die meisten der oben genannten Problempunkte werden in phab:T44725 unter „Multimedia file format support“ („Multimedia-Dateiformatunterstützung“) verfolgt.

Alternative Möglichkeiten zur Unterstützung

Du kannst Quellmaterial für Dateien, die auf Commons hochgeladen werden (wie Kamera-Rohdateien und größere FLAC-Audiodateien), auf Internet Archive hochladen und in Commons verlinken.[1]

Anmerkungen

  1. Megapixel (Anzahl der Frames × Breite × Höhe), Downsampling-Formel (für das Wikimedia-Limit unter Beibehaltung des Seitenverhältnisses der Datei): floor (√LimitMegapixel × Breite ÷ Höhe) ≥ Breiteneu, für Animationen (im weiteren Sinn, unter Nichtbeachtung des gespeicherten Seitenverhältnisses): floor (LimitMegapixel ÷ Frames ÷ Höhe) ≥ Breiteneu
  2. Einige PNG-Daten wie die Auflösung pHYs und der Erfassungszeitpunkt tIME und andere Textdaten (Kommentare) werden von MediaWiki in den Metadaten angezeigt, sind aber keine korrekten Exif-Daten.
  3. Für JPEG siehe auch A few scanning tips, Wayne Fulton, scantips.com, 2010 (englisch).
  4. a b c Unser Ogg-Gebrauch unterscheidet sich von, Upstream-Xiph-Gebrauch darin, dass wir uns nur um die Unterscheidung von Audio .oga von .ogv kümmern. Die Xiph.Org Foundation empfiehlt die Verwendung von .ogg als Erweiterung für Ogg Vorbis Audiodateien, .oga für Ogg FLAC Audio, .ogv für Ogg Theora Video und .opus für Ogg Opus Audio gemäß RFC 5334 und RFC 7845. Siehe auch MIME-Tyen und Dateierweiterungen - XiphWiki.
  5. Siehe empfohlene Einstellungen für Opus.
  6. Siehe MDN-Seite: Web Video Codec Guide. Siehe Can I use webm, av1 und ogv. Safari hinkt zwar hinterher, aber dafür ist ja die Transkodierung da.
  7. Bei JPEG2000 haben manche Entwickler Bedenken wegen U-Boot-Patenten (LoC digitalpreservation, englisch) und 2009 markierte Mozilla den Wunsch zur Unterstützung des Formats als WONTFIX (abgelehnt, keine Unterstützung).
  8. Die Dekodierung von JPEG-2000-Bildern in PDF-Dateien wird vollständig unterstützt, so dass sich die Hochlader von PDF-Dateien keine Sorgen machen müssen, dass das Format in diesem Anwendungsfall nicht unterstützt wird.

Siehe auch

Wikipedia-Links (meist zur englischen Wikipedia)
  1. Vormals gab es eine inoffizielle Begleitwebsite, die alle Dateiformate akzeptierte, namens Commons Archive; sie ist nicht mehr online. Es gibt eine Sicherungskopie von Dateien, die vorher dort existierten im Internet Archive.