Commons:ファイル形式

From Wikimedia Commons, the free media repository
(Redirected from Commons:ファイル形式)
Jump to navigation Jump to search
This page is a translated version of a page Commons:File types and the translation is 58% 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

ウィキメディア・コモンズでは「フリーなコンテンツ」のみ受け入れます。同様に、フリーなファイル形式しかアップロードを認めません。

ウィキメディアコモンズでは、特許で保護されたファイル形式は受け入れません。認められたファイル形式の一覧は、以下の節をご参照ください。特許で保護されたファイル形式の例はAACWMAおよびほとんどのAVIコーデックです。私たちにはコンテンツをすべての人に自由に再配布できるようにするという使命があります。特許で保護された形式は、この標準に適合しません。

フリーでないファイル形式およびサポート外のフリーファイル形式は、アップロードするサポートされるフリー形式に変換しなければなりません。幸い、これは通常は難しくありませんが、時間がかかる場合があります(ファイル形式と求める出力品質によります)。

画像

ウィキメディア・コモンズにおいて推奨されるファイル形式は、次のとおりです。SVGPNGJPEG

コモンズではBMP形式のファイルを受け付けません。PNG形式に可逆圧縮でき、常にファイルサイズは圧縮前より小さくなります。

サイズとスケーリング

参照:Commons:最大ファイルサイズ

注記: 以下の記述以降、PNG形式への新しい変換ソフトが導入されました。

画像スケーリングシステムは残念ながらまだ限られており、現在は元の画像と同じ形式で生成されるサムネイル (PNG、GIF、JPEG) は、常に24ビットカラー形式です(画像がGIFの場合を除く、この場合は256色の画像になる)。つまり元の画像にパレットが含まれる場合やグレースケール形式の場合でも、PNG画像をスケーリングするとファイルサイズはかなり大きくなります。そのため、編集およびアーカイブ用に画像を可逆変換PNG形式でアップロードし、記事中にはJPEGサムネイルで表示したい場合、手動で (フルスケールの) JPEG形式ファイルもアップロードしなければならないのです。


画像が非常に大きくレンダリングに時間やメモリがかかりすぎる場合、画像のスケーリングが失敗することがあります(この場合、スケールされた画像が表示されないか、フルサイズの画像をブラウザに送り、動作しなくなることがよくあります)。GIF 画像では1,000 メガピクセルのハードリミットが影響します[Note 1]。通常、重いJPEGファイルはプログレッシブモードで保存された場合のみ問題を起こします。ベースラインモードで代用します(Progressive JPEGsをご参照ください)。

解像度の上限

Shortcut

そうは言うものの、Commonsコンテンツを広く—印刷媒体における使用を含め—再利用できるように、高解像度でのアップロードにご協力ください。上記に説明したように最高解像度の版に問題がある場合は、別のファイル名でより軽い画像を登録するか (ファイルの説明欄に関連する高解像度の画像ファイル名を記入)、あるいは同じファイル名のまま上書きアップロードして版を更します。さらなる情報は、高画質画像の必要性をご参照ください。反対に、Special:AbuseFilter/153は新規利用者による、より小さい(5万バイト以下または200万ピクセル以下)jpgファイルのウィキ横断のアップロードを制限します。

SVG形式

Help:SVGならびにSVGリソース集 (英語版) をご参照ください。

SVGは、XMLベースのベクター画像形式で、ぼやけたり「ピクセル化」することなくスケーリングできます。編集が簡単で、通常、生成するファイルはかなり小さくなります(File:Bitmap VS SVG.svgを参照)。図や国旗などを作成する場合はSVGがお勧めで、PNG形式はスキャナで取得した画像や印刷画質の写真に適しています。詳細はHelp:SVGをご参照ください。

SVGは図表やグラフ、挿絵、地図、およびその他ラベルが必要なあらゆる画像に適しています。SVGはテキストを文字列として保存することができるため、SVG画像はそのテキスト文字列を編集することで他言語に翻訳することができます。例えば、以下のFile:Caucasus-ethnic en.svgという地図は数ヶ国語版に翻訳されています。様々なサイズでJPG形式と比較すると画質がより良いです。(以下に示す画像は実際にはPNG形式です。ウィキペディア上のSVG画像はブラウザに表示されません。代わりに、MediaWikiがSVG画像をPNG画像に変換してPNG画像として表示します。)

PNG形式

PNGロスレスな形式であり(アルファ透過に対応)、保存時にピクセルの色がそのまま引き継がれる点、どのような描画・作図にも使用できる点がSVG 形式と異なります(作図その他には SVG 形式が好まれる。)PNG 形式はデジタル カメラの画像を除外すると、ほとんどすべての用途に適しています。スキャナで取り込んだ画像には PNG の方が適しています(ただし注意点があり – 以下のシャープネスに関する注記をご参照)、さらに色深度の低い画像にも最適です。(これらはJPEG と比較すると、一般にすべてサイズが小さめでより高品質。)

On Wikipedia (and all other MediaWiki installations, as discussed in phab:T192744), PNG thumbnails are not sharpened, but JPEG thumbnails are. For more complicated images, such as photographs, engravings, and such, PNG displays an inferior thumbnail. However, the major problem with JPEG is that, as a lossy file format, it cannot be repeatedly edited, even at the best quality settings. As such, even where the PNG thumbnail is inferior, it’s recommended to upload a PNG as well, and link between the PNG and JPEG copies using {{PNG with JPEG version}}. An exception is where the original image is already in JPEG; in such cases, there’s no reason to provide a PNG copy. However, if you edit the JPEG, it’s not a bad idea to save a PNG copy before closing the program used to edit it; this provides a copy that someone else can edit without causing progressive degradation. As well, for simpler images, see Wikipedia:How to reduce colors for saving a JPEG as PNG – simple images usually have smaller filesize than JPEG when the image is relatively simple.

Exif データ

PNG形式ファイルの特徴として忘れてならないのは適切なexifデータがないことで[Note 2]、raw形式で撮影した画像をアップロードするには、いったん JPEG 形式に変換したファイルをどこかに保存してから読み込む必要があるし、希望する場合は、それとは別にraw形式からPNG形式に変換した別ファイルもアップロードしてください。ただしexifデータを保持したまま画像編集をする場合、プロが使う方法ではまずraw形式の元ファイルかPNG変換したファイルを加工してJPEG形式で保存してから、exifデータを元ファイルからそのJPEGファイルにコピペして保存、本ファイルとして使います。やり方はいくつもあるしどれが正しいとか標準的と言うことはできませんが、ご利用のツールの性能のせいで思いどおりの画像加工ができない場合は、ほかの利用者に協力を依頼してください (たとえばiTXTチャンク外のUTF-8または類似の状態)。

Commons:アップロードする画像の準備、PNGのヒントもご参照ください。
コモンズにある画像のファイル形式の割合 (単位=%、2017年9月時点)

JPEG形式

JPEG (also JPG) is appropriate for photographs, especially when the photographs are already JPEGs. JPEG uses “lossy compression”, sacrificing precision for smaller file size.

If you have a choice of file formats in which to save a graphic, scan, or other such thing, save it as PNG (or save it as another lossless format, such as TIFF, and convert to PNG), and upload it as such. However, if the original file is in JPEG, it generally makes no sense to convert it to PNG: converting a lossy compression into a “lossless” format doesn't buy you anything since the “loss” already occurred in the original, and doing so will only increase the file size (any edits, however, should probably be saved as PNG as well as JPEG). An exception is high resolution JPEGs that have no visible compression artifacts. Conversion to PNG will avoid the thumbnails having additional compression artifacts.

Note that currently, JPEG thumbnails receive extra sharpening, while PNG thumbnails don't. Hence, uploading in both formats may be a good idea if the PNG thumbnails look a bit blurry. Use {{JPEG version of PNG}} on the JPEG versions of a PNG flagged as {{PNG with JPEG version}}.

PNG is a lossless full-color format. JPEG is always a lossy format, even at the highest quality settings. Lossless formats do not degrade after being saved repeatedly, but lossy ones do; hence, having a lossless version of the file allows the file to be tweaked for various purposes—cropping, levels adjustment, and so on—without a loss in quality.

Help:JPEGHelp:Scanning/ja[Note 3]

GIF形式

このGIF形式のファイルはサムネイル化するときに透明度の処理に問題が発生
PNG形式のコンバートなら問題はない

PNG is almost always superior to GIF for still images (smaller size, more colors, better transparency). If you are creating or editing a graphic (not a photograph), and have a choice of file formats to save it in, the preferences for Wikipedia/Wikimedia use is SVG first, then PNG. Never save an image with more than 256 colors in the GIF format. GIF always saves images as 256 colors or less. Converting higher-color images to the GIF format will degrade those images.

Editing of GIF files can be unwieldy because GIF only supports an 8-bit palette and most filters only function on the full palette. And PNG supports 8-bit transparency (alpha channel) in contrast to GIF's 1-bit transparency. There are also certain idiosyncracies in GIF resizing; notably, when a GIF with background transparency is thumbnailed, the transparent area eats into the non-transparent area, which can create problems.

If you find some quality freely licensed GIF graphics, diagrams, charts, maps, illustrations, etc. that you think would be useful for Wikipedia or one of its sister projects, feel free to upload them to Commons as-is. You or others can convert them to SVG format later if need be.

See Commons:Chart and graph resources for tools and help.

アニメーションGIF形式

GIF is a lossless, 8-bit color format (maximum of 256 colors) and should be used mainly for animated images on Wikimedia Commons. For animated images GIF uses lossless compression of images up to 256 colors per frame. Animated GIF files sometimes have problems when thumbnailed. If you find your animation corrupted or distorted when scaled down, try re-saving it with every frame the same size: A common optimization method in animated gif crunchers is to write variable-sized frames, sometimes labeled as: “Save only the portions of frames that have changed”. Wikimedia’s current version of ImageMagick does not seem to support this. There is currently a 100 megapixel restriction in our software; please see the description in Category:Animated GIF files affected by MediaWiki restrictions for details.

Inline animations should be used sparingly; a static image with a link to the animation is preferred unless the animation has a very small file size. Keep in mind the problems with print compatibility mentioned above.

TIFF形式

Only some TIFF files can, at this time, be displayed in resized (thumbnailed) form within Wikipedia or on Commons, and TIFF files are not supported by most Internet browsers. They are an archival format, and should never be used for images intended to be displayed.

TIFF generally serves as a lossless format, similar to PNG, but with much less compression. However, its standard compression algorithm is very fast to apply (which was a benefit on older computers) and most scanner software supports TIFF, making it a popular choice for archives.

PNG is not supported by most scanner software, but files saved in PNG can generally be made much smaller than TIFF files. For instance, one 33 MB TIFF reduced to 17 MB when saved as a PNG.

Overall, PNG is a preferred format; however, the ability to upload TIFF files is offered as a courtesy. For instance, if you were batch scanning files in order to upload them to Commons for others to edit and prepare, you would want to use a lossless format (editing a non-lossless format causes an increase in artifacts every time it is saved). Your scanner software may not support saving directly to PNG, but allow TIFF. In such cases, uploading the image as a TIFF file is acceptable, as it helps you donate material to Commons much more easily (in that specific case, it would be appropriate to inform the regulars on the Village Pump noticeboard so that your batch upload can be prepared for more widespread use and possibly to discuss things beforehand briefly). There are many image editors (free and commercial) that can handle conversion from TIFF to other formats. See: en:Comparison of raster graphics editors #File support.

The statements above apply to the vast majority of TIFF files; however, note that TIFF is a somewhat odd format – the specifications are loose, and can, in theory, support a wide variety of compression schemes and file storage (though most programs that open TIFFs only recognise the most common). This makes it difficult to make definite statements about TIFFs: For instance, TIFFs can contain JPEGs, which are not a lossless format. Generally, only TIFFs of the standard types should be uploaded to Commons.

WebP

The image format WebP is supported on Commons. It supports both lossy image compression based on VP8 and lossless image compression based on a new algorithm. The lossless mode is more compact than PNG.

XCF形式

XCF can be useful if you are working on an image with GIMP. Unlike PNG and similar files, XCF files support text and multiple layers. It may be useful to upload the XCF file, so that other editors can continue working with it directly, while retaining the layering information. Please note that a thumbnail of a XCF can only be generated by the MediaWiki software if the file format is compatible with GIMP 2.6 or 2.8 and the color mode is RGB or grayscale. In other words, images with indexed colors are not supported by the MediaWiki thumbnailer; neither are files created with GIMP 2.10 (see T196054).

音声

参照:Commons:Free media resources/Sound

On Wikimedia Commons, the file types we accept are: MP3, Ogg (using FLAC, Speex, Opus or Vorbis codecs), WebM (using Vorbis), FLAC, WAVE or MIDI.

Non-free formats and lesser-known free formats must be converted before uploading—there is currently no legitimate way to store pristine original data for conversion to future formats or for use when patents expire, even if the license of a given work requires distributing such pristine original data (as is often the case for works distributed under the GNU Free Documentation License or other copyleft licenses).

The Commons does not accept tracker formats, even formats written by free trackers. Nor does it accept sound fonts for use with MIDI files, even sound fonts designed for use with free MIDI players. If it is important that a musical passage be heard with specific instrument definitions that General MIDI does not provide for, and the license allows it, use your tracker software to render the passage to RIFF WAVE, and then encode it to Ogg Vorbis.

As of June 2023, most browsers can play MP3, Ogg Vorbis, and Opus, but not MIDI, FLAC or Speex. FLAC and Speex are automatically converted to Vorbis and MP3 transcodes for playback on browsers after upload.

MP3形式

MP3 is a widely supported audio format and is highly recommended if an ogg or lossless version can't be found. Commons currently only accepts MP3 uploads by users with Autopatrol or higher rights, due to concerns about the capacity of the community to monitor for copyright violations.

MIDI形式

MIDI files are accepted, but not very well supported. The file extension has to be .mid.

Ogg 形式 (音声)

Opus は Ogg コンテナ用に推奨される音声コーデックです。Ogg Opus 形式でアップロードする場合、ファイル形式は opus または oga にします[Note 4]

Opus is supported by MediaWiki (phab:T42193, phab:T53313) since 2014. The format has excellent quality and low algorithmic delay.It automatically switches between speech and music-optimized modes and is able to combine the two. FLAC is for general audio and is lossless (quality is preserved), but current file size caps prevent its use for anything but short clips. In most cases, Opus should be used, using Xiph recommended settings.[Note 5]

Existing audio in other free codecs (such as Speex and Vorbis), but present in an Ogg container, should not be converted to Opus or FLAC to avoid generation loss.

Note that with FLAC, a native container format exists (see below). If your output file has the extension .flac, it is likely using the native container format. If you like to embed it into an ogg container, this can be done with ffmpeg using the command line ffmpeg -i InputFile.ext -acodec flac out.oga or flac ./input.wav -8 --ogg -f ./output.oga.[Note 4]

It is also useless to put data in a non-free format into a free container like Ogg: you get a file, which, while requiring that a player support the free container, still requires that it support the non-free codec.

WebM 形式 (音声)

The WebM container can hold audio (Vorbis or Opus), with or without accompanying video.

FLAC 形式

The Free Lossless Audio Codec is supported with or without encapsulation into ogg-containers. TimedMediaHandler will automatically offer transcoded variants in ogg format. File extension without encapsulation: .flac. (The related phab:T51505 was resolved in 2013 and closed in 2014.)

WAVE 形式

Wave containers usually contain uncompressed, lossless audio (PCM). If possible, please convert to FLAC before uploading. File extension: .wav.

動画

Videos must be Ogg files using the Theora video coding format (with a .ogv extension[Note 4]), WebM files (.webm extension), or MPEG-1/MPEG-2 files (.mpg and .mpeg extension). Non-free formats must be converted before uploading. See Commons:Video – Uploading a video for instructions. See Video2Commons for a fast and easy tool.

The recommendation of MDN Web Docs is WebM containg VP9 video with Opus audio. Can I use reports that some 80% of 2023 users are able to directly use this combination, much more than Ogg Theora (~30%).[Note 6]

WebM 形式 (動画)

WebM supports the VP8, VP9, and AV1 video coding formats, and the Vorbis and Opus audio coding formats. The container format WebM is a subset of Matroska.

VP8 is a lossy compression format which has better quality than Theora does. Of course, there is no need to transcode existing Theora videos to VP8, because it won't fix the damage by a prior more lossy compression. While WebM is more widely supported by browsers, such compatibility issues are to be fixed by automatic transcoding in MediaWiki software, not by manual re-upload.

VP9 is a successor to VP8, having better compression efficiency.

AV1 is a successor to VP9 and offers better compression efficiency. It's slated to have much wider industry support both in software and hardware than previous free video formats. As of 2023, 70% of users are able to play this format.

Ogg Theora 形式 (動画)

Theora is a lossy video coding format released in 2004. It is based on VP3 in the line leading to Flash VP6/VP7 and WebM VP8/VP9. (Note: Most software mentioned at Commons:ソフトウェア should also be able to play Ogg Vorbis audio.)

As of 2023. Theora is poorly supported by modern browsers' HTML5 video players. Avoid converting to this format.

MPEG-1 (video)

MPEG-1 is the VCD standard, which includes MP2 and MP1 standards, for lossy compression of video and audio released in 1993. It was designed to compress VHS-quality raw digital video and CD audio down to about 1.5 Mbit/s (26:1 and 6:1 compression ratios respectively) without excessive quality loss.

MPEG-2 (video)

MPEG-2 is the DVD standard, which includes MP2, for "the generic coding of moving pictures and associated audio information" first released in 1996. It describes a combination of lossy video compression and lossy audio data compression methods, which permit storage and transmission of movies using currently available storage media and transmission bandwidth. Both of MPEG-2 and MPEG-1 are standards of digital cable/satellite TV and digital audio broadcasting (DAB).

テキストの形式

スキャンしたテキスト文書 (DjVu、PDF)

このPDFファイルは記事中の挿絵として使うとまだらに見えるため(JPEG 圧縮が原因で)、{{BadPDF}}フラグが立った。こちらのロゴの方がはるかに適している。

Although Commons does not generally host documents, there are valid reasons to upload them here (such as archival versions for transcription use on Wikisource).

  • See Help:DjVu to get help about DjVu and PDF files.
  • Documents in PDF format are allowed. Usage as graphic is not recommended, as you can see on the right example, which is a clear vector graphic. For allowable reasons of PDF and DjVu format, see Project Scope, PDF and DjVu formats.

Note that any page from a PDF currently gets rendered as JPG by thumbnails, but this could as well be rendered as PNG. This only depends on the implementation of the PDF renderer used on the image thumbnail server and it is not a limitation of the PDF format vs. DejaVu. The only limitation is the existence of various proprietary extensions of the PDF format which could sometimes require a specific PDF viewer. PDF files in Commons should not depend on these extensions and should use only the core specifications, used by the thumbnail renderer of Commons. The issue may exist only when PDFs are downloaded in native format from the "Media:" namespace instead of being rendered as a single image from a selectable page number in the PDF (because these extensions may embed some active scripting, form handlers, and active links to external sites).

For single image rendering, PDF files rendered with the core PDF profile (from its standard specifications) are functionally equivalent to DejaVu files, but typically render photographs and graphics with higher fidelity and more accurate color profiles than DejaVu files which use a more basic model. PDFs also offer better quality in some cases as they can embed scalable vector graphics, instead of just highly compressed bitmaps at a fixed resolution. So the difference is basically on the compression level for bitmaps: for scanned text documents, DejaVu is often smaller than PDF, but this does not make a difference when these files are rendered as a single bitmap image instead of being downloaded.

For documents containing colorful graphics and photos, PDFs frequently offer better fidelity and accuracy. However, image thumbnail renderers currently used by Commons do not render them clearly because they generate JPEG thumbnails instead of more accurate PNG thumbnails: this could change in the future when an agreement is reached at phab:T38597.

Noting that due to many copyright infringements and out of scope files being uploaded, we do not allow new users to upload PDF files.

テキストではないアイテムのスキャニングについての助言はHelp:スキャニングもご参照ください。

TimedText 形式

TimedText is a custom Commons namespace to hold “Timed Text”, also termed subtitles, closed captioning and closed caption text. The contents are plain text with no markup whatsoever.

Commons:Timed Textを参照。

データファイル

データベース形式のファイルはいずれもコモンズにアップロードするファイル形式として受け入れていません。(以下のサポートされないファイル形式をご参照ください。)

However, tabular data can be stored in the dedicated Data: namespace. For example, data in this namespace can include:

  • Map data, allowing users to store GeoJSON data.
  • Tabular data, allowing users to create CSV-like tables of data.

This also supports the creation of dynamic text (via Lua modules) and graphs using data in JSON format.

Data files in Commons have to be set under one of these license: 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, or dl-de-by-2.0.

Feel free to experiment by creating pages with the Data:Sandbox/<username>/ prefix. For now, page content can only be edited in the raw JSON format unless, each field have the type 'number' or 'string'. To categorise Data files, categories can only be added to their corresponding Data talk pages.

地図データ

詳細はmw:Help:Map Dataをご参照ください。

Map data allows users to store GeoJSON data, similar to images. Other wikis may use this data to draw on top of the maps, together with other map customizations, using Kartographer.

To create a new map data, create a new page in the Data: namespace with the .map suffix, such as Data:Sandbox/Example user/Example.map.

表形式データ

詳細は表形式データ (mw:Help:Tabular Data) をご参照ください。

Tabular data allows users to create CSV-like tables of data, and use them from other wikis to create automatic tables, lists, and graphs.

To create a new table, create a new page in the Data: namespace with a .tab suffix, such as Data:Sandbox/Example user/Example.tab.

設計とCAD形式

3D 構造物
3D ファイルには、STL形式という3D-プリントで最も標準的な形式があります。その他の 3D ファイル形式およびCADファイル形式サポートされません3D拡張機能のヘルプもご参照ください。


その他のファイル形式

化学および生物学の分子構造図
サポート対象外。以下のサポートされないファイル形式をご参照ください。
道順の地図、GPS データ
地図データ参照。以下のサポートされないファイル形式もご参照ください。

新規のファイル形式にサポートを申請

2021時点で、新規のファイル形式に対するサポート申請に定形の手順はありません。MediaWiki.orgで協議

The MediaWiki manual includes a description of how to add support for a new file type, which mentions some considerations when adding support on Wikimedia websites.

As a first step, read that manual page + file a ticket requesting support linking to this umbrella tracking ticket: Multimedia file format support (tracking). You can find examples of past requests, open and closed, linked to it already; and a summary below of past requests that remain unsupported.

サポートされないファイル形式

サポートされないフリーファイル形式

最低1回は要請、現在はサポート外。サポートできる人募集。:-)

STL(サポート済み)を除くあらゆる 3D ファイル形式
Any other CAD design patterns
データファイルの形式
化学または生物学の分子のためのあらゆる形式:
経路図・GPS 形式:
オープン文書形式:
画像ファイル形式
音声・動画形式:
  • ALAC(Apple) – phab:T34104
  • MKV コンテナ形式 – phab:T32653#347603WebM は前項 Matroska のサブセットでありコモンズで採用、ただし Matroska 本体のサポートは未定の模様)
Diagram formats
マルチメディアおよびアニメーションの形式:
  • SWF – ライセンス無料の as of 2009 かどうか? 無料のツールで生成および再生できるべき – 却下、phab:T28269
Scientific format
  • FITS – Flexible Image Transport System
フォント形式:
  • OpenType もしくはオープンフォント形式

フリーでないファイル形式

アップロードにおけるこれらの形式のフリーな形式への自動変換によって、少なくとも1回要求されました。

上記の問題のほとんどはphab:T44725で「マルチメディアとファイル形式のサポート」として追跡されています。

代替サイトでサポートを受ける

カメラのRawファイルやより大きなFLAC音声のような、コモンズにアップロードされるファイルの元となる素材は、あらゆるファイル形式を受け付けるコモンズの非公式な補助ウェブサイトCommons Archiveにアップロードすることができます。すべてのコモンズ利用者はCommons ArchiveにOAuthでログインできることに留意してください。

注釈

  1. メガピクセル (フレーム数 ×  × 高さ)、ダウンサンプリング(英語版)の数式(ウィキメディアの制限のため、SAR (英語版)を維持): floor (√メガピクセル上限値 ×  ÷ 高さ) ≥ new、アニメーションの場合 (さらにロスSAR): floor (メガピクセル上限値 ÷ フレーム数 ÷ 高さ) ≥ new
  2. MediaWiki では場合によってPNGファイルの「メタデータ」として解像度pHYsやタイムスタンプtIMEあるいは文字データ (コメント) を表示してありますが、これらデータは実は正規の Exif データではありません。
  3. JPEG形式についてはヒント集 A few scanning tips (2010年、Wayne Fulton執筆、scantips.com)もご参照ください。
  4. a b c Ogg 規約は音声の.oga と動画の .ogv の区別のみを考慮するという点で、アップストリームの Xiph 規約とは異なり RFC 5334 および RFC 7845 に準拠します。Xiph.Org 財団の推奨により拡張子は Ogg Vorbis 音声ファイルの .ogg、Ogg FLAC 音声の .oga、Ogg Theora 動画の .ogv、Ogg Opus 音声の .opus を採用します。関連情報としてMIME種別およびファイル拡張子は MIME Types and File Extensions - XiphWiki をご参照ください。
  5. See Opus Recommended Settings.
  6. See MDN page: Web video codec guide. See Can I use webm and ogv. You will find Safari lagging behind, but that is what transcoding is for.
  7. JPEG2000の場合、開発者によっては特許権回避策を懸念し (LoC digitalpreservation)、2009年にはMozilla財団がWONTFIXと発表。
  8. PDFでJPEG 2000画像のデコードが完全にサポートされたので、PDFファイルのアップロード者はこの場合サポートされない形式の心配をする必要はありません

関連項目

ウィキペディアのヘルプ