RFC2083 日本語訳
2083 PNG (Portable Network Graphics) Specification Version 1.0. T.Boutell. March 1997. (Format: TXT=242528 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group T. Boutell, et. al. Request for Comments: 2083 Boutell.Com, Inc. Category: Informational March 1997
et作業部会T.Boutell、アルをネットワークでつないでください。 コメントのために以下を要求してください。 2083年のBoutell.Com Inc.カテゴリ: 情報の1997年3月
PNG (Portable Network Graphics) Specification
Version 1.0
PNG(携帯用のネットワークグラフィックス)仕様バージョン1.0
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
IESG Note:
IESGは以下に注意します。
The IESG takes no position on the validity of any Intellectual Property Rights statements contained in this document.
IESGは本書では含まれたどんなIntellectual Property Rights声明の正当性の立場も全く取りません。
Abstract
要約
This document describes PNG (Portable Network Graphics), an extensible file format for the lossless, portable, well-compressed storage of raster images. PNG provides a patent-free replacement for GIF and can also replace many common uses of TIFF. Indexed-color, grayscale, and truecolor images are supported, plus an optional alpha channel. Sample depths range from 1 to 16 bits.
このドキュメントはPNG(携帯用のNetwork Graphics)、losslessにおいて、広げることができるファイル形式、ラスター・イメージの携帯用の、そして、よく圧縮された格納について説明します。 PNGはGIFへの無特許の交換品を提供して、また、TIFFの多くの一般的な用途を置き換えることができます。 索引をつけられた色、グレースケール、およびtruecolorイメージは支持されて、プラスは任意のアルファチャンネルです。 深層を抽出してください。1〜16ビットの範囲。
PNG is designed to work well in online viewing applications, such as the World Wide Web, so it is fully streamable with a progressive display option. PNG is robust, providing both full file integrity checking and simple detection of common transmission errors. Also, PNG can store gamma and chromaticity data for improved color matching on heterogeneous platforms.
PNGはオンライン見るアプリケーションでうまくいくように設計されています、それが進歩的な表示オプションで完全に「流れ-可能」でWWWなどのように。 完全なファイル保全の照合と一般的な伝送エラーの簡便な検出の両方を提供して、PNGは強健です。 また、PNGは異種のプラットホームで合っている改良された色のためにガンマと色度データを格納できます。
This specification defines the Internet Media Type image/png.
この仕様はインターネットメディアTypeイメージ/pngを定義します。
Table of Contents
目次
1. Introduction .................................................. 4
2. Data Representation ........................................... 5
2.1. Integers and byte order .................................. 5
2.2. Color values ............................................. 6
2.3. Image layout ............................................. 6
2.4. Alpha channel ............................................ 7
2.5. Filtering ................................................ 8
2.6. Interlaced data order .................................... 8
2.7. Gamma correction ......................................... 10
1. 序論… 4 2. データ表現… 5 2.1. 整数とバイトオーダー… 5 2.2. 値を着色してください… 6 2.3. イメージレイアウト… 6 2.4. アルファーチャンネル… 7 2.5. フィルターにかけます。 8 2.6. 交錯しているデータは注文されます… 8 2.7. ガンマ修正… 10
Boutell, et. al. Informational [Page 1] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[1ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
2.8. Text strings ............................................. 10
3. File Structure ................................................ 11
3.1. PNG file signature ....................................... 11
3.2. Chunk layout ............................................. 11
3.3. Chunk naming conventions ................................. 12
3.4. CRC algorithm ............................................ 15
4. Chunk Specifications .......................................... 15
4.1. Critical chunks .......................................... 15
4.1.1. IHDR Image header .................................. 15
4.1.2. PLTE Palette ....................................... 17
4.1.3. IDAT Image data .................................... 18
4.1.4. IEND Image trailer ................................. 19
4.2. Ancillary chunks ......................................... 19
4.2.1. bKGD Background color .............................. 19
4.2.2. cHRM Primary chromaticities and white point ........ 20
4.2.3. gAMA Image gamma ................................... 21
4.2.4. hIST Image histogram ............................... 21
4.2.5. pHYs Physical pixel dimensions ..................... 22
4.2.6. sBIT Significant bits .............................. 22
4.2.7. tEXt Textual data .................................. 24
4.2.8. tIME Image last-modification time .................. 25
4.2.9. tRNS Transparency .................................. 26
4.2.10. zTXt Compressed textual data ...................... 27
4.3. Summary of standard chunks ............................... 28
4.4. Additional chunk types ................................... 29
5. Deflate/Inflate Compression ................................... 29
6. Filter Algorithms ............................................. 31
6.1. Filter types ............................................. 31
6.2. Filter type 0: None ...................................... 32
6.3. Filter type 1: Sub ....................................... 33
6.4. Filter type 2: Up ........................................ 33
6.5. Filter type 3: Average ................................... 34
6.6. Filter type 4: Paeth...................................... 35
7. Chunk Ordering Rules .......................................... 36
7.1. Behavior of PNG editors .................................. 37
7.2. Ordering of ancillary chunks ............................. 38
7.3. Ordering of critical chunks .............................. 38
8. Miscellaneous Topics .......................................... 39
8.1. File name extension ...................................... 39
8.2. Internet media type ...................................... 39
8.3. Macintosh file layout .................................... 39
8.4. Multiple-image extension ................................. 39
8.5. Security considerations .................................. 40
9. Recommendations for Encoders .................................. 41
9.1. Sample depth scaling ..................................... 41
9.2. Encoder gamma handling ................................... 42
9.3. Encoder color handling ................................... 45
9.4. Alpha channel creation ................................... 47
2.8. テキストストリング… 10 3. 構造をファイルしてください… 11 3.1. PNGは署名をファイルします… 11 3.2. 塊レイアウト… 11 3.3. 塊命名規則… 12 3.4. CRCアルゴリズム… 15 4. 塊仕様… 15 4.1. 批判的な塊… 15 4.1.1. IHDR Imageヘッダー… 15 4.1.2. PLTEパレット… 17 4.1.3. IDAT Imageデータ… 18 4.1.4. IEND Imageトレーラ… 19 4.2. 付属の塊… 19 4.2.1bKGD Backgroundは着色します… 19 4.2.2cHRM Primary色度と白は指します… 20 4.2.3gAMA Imageガンマ… 21 4.2.4hIST Imageヒストグラム… 21 4.2.5pHYs Physical画素の重要性… 22 4.2.6sBIT Significantビット… 22 4.2.7tEXt Textualデータ… 24 4.2.8tIME Image最後の変更時間… 25 4.2.9tRNS透明… 26 4.2.10zTXt Compressedの原文のデータ… 27 4.3. 標準の塊の概要… 28 4.4. 追加塊タイプ… 29 5. 圧縮を空気を抜くか、またはふくらませてください… 29 6. アルゴリズムをフィルターにかけてください… 31 6.1. タイプはフィルターにかけます… 31 6.2. タイプ0をフィルターにかけてください: なにも… 32 6.3. タイプ1をフィルターにかけてください: 代理をしてください… 33 6.4. タイプ2をフィルターにかけてください: 上がる… 33 6.5. タイプ3をフィルターにかけてください: 平均… 34 6.6. タイプ4をフィルターにかけてください: Paeth… 35 7. 塊注文は統治されます… 36 7.1. PNGエディタの振舞い… 37 7.2. 付属の塊を注文します… 38 7.3. 批判的な塊を注文します… 38 8. 種々雑多な話題… 39 8.1. 名前拡大をファイルしてください… 39 8.2. インターネットメディアはタイプされます… 39 8.3. マッキントッシュファイルレイアウト… 39 8.4. 複数のイメージ拡張子… 39 8.5. セキュリティ問題… 40 9. エンコーダのための推薦… 41 9.1. 深さスケーリングを抽出してください… 41 9.2. エンコーダガンマ取り扱い… 42 9.3. エンコーダ色の取り扱い… 45 9.4. アルファチャンネル創造… 47
Boutell, et. al. Informational [Page 2] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[2ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
9.5. Suggested palettes ....................................... 48
9.6. Filter selection ......................................... 49
9.7. Text chunk processing .................................... 49
9.8. Use of private chunks .................................... 50
9.9. Private type and method codes ............................ 51
10. Recommendations for Decoders ................................. 51
10.1. Error checking .......................................... 52
10.2. Pixel dimensions ........................................ 52
10.3. Truecolor image handling ................................ 52
10.4. Sample depth rescaling .................................. 53
10.5. Decoder gamma handling .................................. 54
10.6. Decoder color handling .................................. 56
10.7. Background color ........................................ 57
10.8. Alpha channel processing ................................ 58
10.9. Progressive display ..................................... 62
10.10. Suggested-palette and histogram usage .................. 63
10.11. Text chunk processing .................................. 64
11. Glossary ..................................................... 65
12. Appendix: Rationale .......................................... 69
12.1. Why a new file format? .................................. 69
12.2. Why these features? ..................................... 70
12.3. Why not these features? ................................. 70
12.4. Why not use format X? ................................... 72
12.5. Byte order .............................................. 73
12.6. Interlacing ............................................. 73
12.7. Why gamma? .............................................. 73
12.8. Non-premultiplied alpha ................................. 75
12.9. Filtering ............................................... 75
12.10. Text strings ........................................... 76
12.11. PNG file signature ..................................... 77
12.12. Chunk layout ........................................... 77
12.13. Chunk naming conventions ............................... 78
12.14. Palette histograms ..................................... 80
13. Appendix: Gamma Tutorial ..................................... 81
14. Appendix: Color Tutorial ..................................... 89
15. Appendix: Sample CRC Code .................................... 94
16. Appendix: Online Resources ................................... 96
17. Appendix: Revision History ................................... 96
18. References ................................................... 97
19. Credits ......................................................100
9.5. パレットを示します… 48 9.6. 選択をフィルターにかけてください… 49 9.7. テキスト塊処理… 49 9.8. 個人的な塊の使用… 50 9.9. 個人的なタイプと方法コード… 51 10. デコーダのための推薦… 51 10.1. 誤りの照合… 52 10.2. 画素の重要性… 52 10.3. Truecolorイメージ取り扱い… 52 10.4. 深さ再スケーリングを抽出してください… 53 10.5. デコーダガンマ取り扱い… 54 10.6. デコーダ色の取り扱い… 56 10.7. バックグラウンド色… 57 10.8. アルファチャンネル処理… 58 10.9. 進歩的な表示… 62 10.10. 提案されたパレットとヒストグラム用法… 63 10.11. テキスト塊処理… 64 11. 用語集… 65 12. 付録: 原理… 69 12.1. なぜ新しいファイル形式? .................................. 69 12.2. なぜこれらの特徴? ..................................... 70 12.3. なぜこれらの特徴でない? ................................. 70 12.4. なぜ形式Xを使用しませんか? ................................... 72 12.5. バイトオーダー… 73 12.6. 交錯します… 73 12.7. なぜガンマ? .............................................. 73 12.8. 非前掛け算をさせられたアルファ… 75 12.9. フィルターにかけます。 75 12.10. テキストストリング… 76 12.11. PNGは署名をファイルします… 77 12.12. 塊レイアウト… 77 12.13. 塊命名規則… 78 12.14. パレットヒストグラム… 80 13. 付録: ガンマチュートリアル… 81 14. 付録: チュートリアルを着色してください… 89 15. 付録: CRCコードを抽出してください… 94 16. 付録: オンライン情報源… 96 17. 付録: 改正歴史… 96 18. 参照… 97 19. 掛けます。100
Boutell, et. al. Informational [Page 3] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[3ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
1. Introduction
1. 序論
The PNG format provides a portable, legally unencumbered, well- compressed, well-specified standard for lossless bitmapped image files.
PNG形式はlosslessビットマップ画像ファイルの携帯用の、そして、法的に邪魔されなくて、よく圧縮されて、よく指定された規格を提供します。
Although the initial motivation for developing PNG was to replace GIF, the design provides some useful new features not available in GIF, with minimal cost to developers.
展開しているPNGに関する初期の動機がGIFを取り替えることでしたが、デザインはGIFで利用可能でないいくつかの役に立つ新機能を提供します、開発者への最小量の費用で。
GIF features retained in PNG include:
PNGで保有されたGIFの特徴は:
* Indexed-color images of up to 256 colors.
* Streamability: files can be read and written serially, thus
allowing the file format to be used as a communications
protocol for on-the-fly generation and display of images.
* Progressive display: a suitably prepared image file can be
displayed as it is received over a communications link,
yielding a low-resolution image very quickly followed by
gradual improvement of detail.
* Transparency: portions of the image can be marked as
transparent, creating the effect of a non-rectangular image.
* Ancillary information: textual comments and other data can be
stored within the image file.
* Complete hardware and platform independence.
* Effective, 100% lossless compression.
* 最大256の索引をつけられたカラーイメージは着色します。 * Streamability: 順次ファイルを読み書きできます、その結果、ファイル形式がイメージの飛行中の世代と表示に通信規約として使用されるのを許容します。 * 進歩的な表示: コミュニケーションリンクの上にそれを受け取るとき、適当に準備されたイメージ・ファイルは表示できます、詳細のゆるやかな改良が非常にすぐにあとに続いた低い解像度イメージをもたらして。 * 透明: 非長方形のイメージの効果を引き起こして、透明であるとしてイメージの部分を示されることができます。 * 補助的情報: イメージ・ファイルの中に原文のコメントと他のデータを格納できます。 * ハードウェアとプラットホーム独立を完成してください。 * 100%の有効な可逆圧縮。
Important new features of PNG, not available in GIF, include:
PNGの重要なGIFで利用可能でない新機能は:
* Truecolor images of up to 48 bits per pixel.
* Grayscale images of up to 16 bits per pixel.
* Full alpha channel (general transparency masks).
* Image gamma information, which supports automatic display of
images with correct brightness/contrast regardless of the
machines used to originate and display the image.
* Reliable, straightforward detection of file corruption.
* Faster initial presentation in progressive display mode.
* 1画素あたり最大48ビットのTruecolorイメージ。 * 1画素あたり最大16ビットのグレースケールイメージ。 * 完全なアルファチャンネル(一般的な透明マスク)。 * イメージガンマ情報。(その情報はイメージを溯源して、表示するのに使用されるマシンにかかわらず正しい明るさ/コントラストでイメージの自動表示を支持します)。 * ファイル不正の信頼できて、簡単な検出。 * より速く進歩的な表示モードにおけるプレゼンテーションに頭文字をつけてください。
PNG is designed to be:
PNGは、である:なるように設計されています。
* Simple and portable: developers should be able to implement PNG
easily.
* Legally unencumbered: to the best knowledge of the PNG authors,
no algorithms under legal challenge are used. (Some
considerable effort has been spent to verify this.)
* Well compressed: both indexed-color and truecolor images are
compressed as effectively as in any other widely used lossless
format, and in most cases more effectively.
* 簡単で携帯用: 開発者は容易にPNGを実行できるべきです。 * 法的に邪魔されません: PNG作者に関する最も良い知識には、法的な挑戦でのどんなアルゴリズムも使用されていません。 (これについて確かめるために何らかのかなりの努力を費やしてあります。) * よく圧縮されています: 索引をつけられた色とtruecolorイメージの両方が同じくらい事実上、多くの場合いかなる他の広く使用されたlossless形式とも効果的に圧縮されます。
Boutell, et. al. Informational [Page 4] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[4ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
* Interchangeable: any standard-conforming PNG decoder must read
all conforming PNG files.
* Flexible: the format allows for future extensions and private
add-ons, without compromising interchangeability of basic PNG.
* Robust: the design supports full file integrity checking as
well as simple, quick detection of common transmission errors.
* 交換可能: どんな規格を従わせるPNGデコーダもPNGファイルをすべて従うのに読み込まなければなりません。 * フレキシブル: 基本的なPNGの互換性で妥協しないで、形式は今後の拡大と個人的な付加物を考慮します。 * 強健: デザインは一般的な伝送エラーの簡単で、迅速な検出と同様にチェックする完全なファイル保全を支持します。
The main part of this specification gives the definition of the file format and recommendations for encoder and decoder behavior. An appendix gives the rationale for many design decisions. Although the rationale is not part of the formal specification, reading it can help implementors understand the design. Cross-references in the main text point to relevant parts of the rationale. Additional appendixes, also not part of the formal specification, provide tutorials on gamma and color theory as well as other supporting material.
この仕様の主部はエンコーダとデコーダの振舞いのためのファイル形式と推薦の定義を与えます。 付録は多くのデザイン決定のために原理を与えます。 原理は形式仕様の一部ではありませんが、それを読むのは、作成者がデザインを理解しているのを助けることができます。 主なテキストにおける相互参照は原理の関連部分を示します。 追加付属物、形式仕様のいずれの一部も、材料を支えながら、他としてまた、ガンマと色の理論でチュートリアルを提供しません。
In this specification, the word "must" indicates a mandatory requirement, while "should" indicates recommended behavior.
この仕様では、“must"という単語は義務的な要件を示しますが、“should"はお勧めの振舞いを示します。
See Rationale: Why a new file format? (Section 12.1), Why these features? (Section 12.2), Why not these features? (Section 12.3), Why not use format X? (Section 12.4).
原理を見てください: なぜ新しいファイル形式? (セクション12.1), なぜこれらの特徴? (セクション12.2), なぜこれらの特徴でない? (セクション12.3), なぜ形式Xを使用しませんか? (セクション12.4。)
Pronunciation
発音
PNG is pronounced "ping".
PNGは「ピング」であると断言されます。
2. Data Representation
2. データ表現
This chapter discusses basic data representations used in PNG files, as well as the expected representation of the image data.
本章はPNGファイルで使用される基礎データ表現、およびイメージデータの予想された表現について議論します。
2.1. Integers and byte order
2.1. 整数とバイトオーダー
All integers that require more than one byte must be in network
byte order: the most significant byte comes first, then the less
significant bytes in descending order of significance (MSB LSB for
two-byte integers, B3 B2 B1 B0 for four-byte integers). The
highest bit (value 128) of a byte is numbered bit 7; the lowest
bit (value 1) is numbered bit 0. Values are unsigned unless
otherwise noted. Values explicitly noted as signed are represented
in two's complement notation.
ネットワークバイトオーダーには1バイト以上を必要とするすべての整数があるに違いありません: 最も重要なバイトは一番になって、その時は意味(2バイトの整数のためのMSB LSB、4バイトの整数のためのB3 B2 B1 B0)の降順でそれほど重要でないバイトです。 1バイトの最も高いビット(値128)は番号付のビット7です。 最も低いビット(値1)は番号付のビット0です。 別の方法で注意されない場合、値は無記名です。 サインされるように明らかに注意された値は2の補数記法で表されます。
See Rationale: Byte order (Section 12.5).
原理を見てください: バイトオーダー(セクション12.5)。
Boutell, et. al. Informational [Page 5] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[5ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
2.2. Color values
2.2. 色の値
Colors can be represented by either grayscale or RGB (red, green,
blue) sample data. Grayscale data represents luminance; RGB data
represents calibrated color information (if the cHRM chunk is
present) or uncalibrated device-dependent color (if cHRM is
absent). All color values range from zero (representing black) to
most intense at the maximum value for the sample depth. Note that
the maximum value at a given sample depth is (2^sampledepth)-1,
not 2^sampledepth.
グレースケールかRGB(赤くて、緑色の青)標本データのどちらかは色を表すことができます。 グレースケールデータは輝度を表します。 RGBデータは較正された色彩の情報(cHRM塊が存在しているなら)か非較正された装置依存する色を表します(cHRMが欠けるなら)。 すべての色の値がゼロ(黒を表す)〜大部分まで最大値でサンプルの深さに激しい状態で及びます。 与えられたサンプルの深さにおける最大値が2^sampledepthではなく、(2^sampledepth)-1であることに注意してください。
Sample values are not necessarily linear; the gAMA chunk specifies
the gamma characteristic of the source device, and viewers are
strongly encouraged to compensate properly. See Gamma correction
(Section 2.7).
標本値は必ず直線的であるというわけではありません。 gAMA塊はソース装置のガンマの特性を指定します、そして、ビューアーが適切に代償するよう強く奨励されます。 Gamma修正(セクション2.7)を見てください。
Source data with a precision not directly supported in PNG (for
example, 5 bit/sample truecolor) must be scaled up to the next
higher supported bit depth. This scaling is reversible with no
loss of data, and it reduces the number of cases that decoders
have to cope with. See Recommendations for Encoders: Sample depth
scaling (Section 9.1) and Recommendations for Decoders: Sample
depth rescaling (Section 10.4).
精度がPNG(例えば、5個のビット/サンプルのtruecolor)で直接支持されていないソースデータまで次の、より高い支持された噛み付いている深さに拡大しなければなりません。 このスケーリングはデータの喪失のないリバーシブルです、そして、それはデコーダが切り抜けなければならない件数を減少させます。 エンコーダのための推薦を見てください: Decodersのために(セクション9.1)とRecommendationsをスケーリングする深さを抽出してください: 深さ再スケーリング(セクション10.4)を抽出してください。
2.3. Image layout
2.3. イメージレイアウト
Conceptually, a PNG image is a rectangular pixel array, with
pixels appearing left-to-right within each scanline, and scanlines
appearing top-to-bottom. (For progressive display purposes, the
data may actually be transmitted in a different order; see
Interlaced data order, Section 2.6.) The size of each pixel is
determined by the bit depth, which is the number of bits per
sample in the image data.
概念的に、PNGイメージは排臨が各走査線の中に右に残した画素、および先端から下部に現れる走査線がある長方形の画素アレイです。 (進歩的な表示目的には、データは実際に異なったオーダーで送られるかもしれません; Interlacedデータ注文、セクション2.6を見てください。) 噛み付いている深さに従って、それぞれの画素のサイズは決定しています。(それは、イメージデータのサンプルあたりのビットの数です)。
Three types of pixel are supported:
画素の3つのタイプが支持されます:
* An indexed-color pixel is represented by a single sample
that is an index into a supplied palette. The image bit
depth determines the maximum number of palette entries, but
not the color precision within the palette.
* A grayscale pixel is represented by a single sample that is
a grayscale level, where zero is black and the largest value
for the bit depth is white.
* A truecolor pixel is represented by three samples: red (zero
= black, max = red) appears first, then green (zero = black,
max = green), then blue (zero = black, max = blue). The bit
depth specifies the size of each sample, not the total pixel
size.
* 索引をつけられたカラー画素は供給されたパレットへのインデックスであるただ一つのサンプルによって表されます。 イメージの噛み付いている深さはパレットの中に色の精度ではなく、パレットエントリーの最大数を測定します。 * グレースケール画素はグレースケールレベルであるただ一つのサンプルによって表されます、ゼロが黒く、噛み付いている深さへの最も大きい値が白いところで。 * truecolor画素は3個のサンプルによって表されます: 赤は次に、1番目、緑色(ゼロは黒と等しいです、最大=緑色)、当時の青に現れます(ゼロが黒と等しいです、最大=赤)(ゼロは黒と等しいです、最大=青)。 噛み付いている深さは総画素サイズではなく、それぞれのサンプルのサイズを指定します。
Boutell, et. al. Informational [Page 6] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[6ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
Optionally, grayscale and truecolor pixels can also include an
alpha sample, as described in the next section.
また、任意に、グレースケールとtruecolor画素は次のセクションで説明されるようにアルファのサンプルを含むことができます。
Pixels are always packed into scanlines with no wasted bits
between pixels. Pixels smaller than a byte never cross byte
boundaries; they are packed into bytes with the leftmost pixel in
the high-order bits of a byte, the rightmost in the low-order
bits. Permitted bit depths and pixel types are restricted so that
in all cases the packing is simple and efficient.
画素は画素の間の無駄なビットなしで走査線にいつも詰め込まれます。 1バイトよりわずかな画素はバイト境界に決して交差していません。 一番左画素が1バイト(下位のビットの一番右)の高位のビットにある状態で、それらはバイトに詰め込まれます。 受入れられた噛み付いている深層と画素タイプが制限されるので、すべての場合では、パッキングは、簡単であって、効率的です。
PNG permits multi-sample pixels only with 8- and 16-bit samples,
so multiple samples of a single pixel are never packed into one
byte. 16-bit samples are stored in network byte order (MSB
first).
PNGは単に8と16ビットのサンプルでマルチのサンプル画素を可能にします、非常に複数ので、1画素のサンプルは1バイトに決して詰め込まれません。 16ビットのサンプルはネットワークバイトオーダー(MSB1番目)に格納されます。
Scanlines always begin on byte boundaries. When pixels have fewer
than 8 bits and the scanline width is not evenly divisible by the
number of pixels per byte, the low-order bits in the last byte of
each scanline are wasted. The contents of these wasted bits are
unspecified.
走査線はバイト境界でいつも始まります。 いつ、画素には8ビット未満と走査線幅があるかは、均等にそうではありません。1バイトあたりのピクセル数で分割可能です、それぞれの走査線の最後のバイトにおける下位のビットは無駄です。 これらの無駄なビットの内容は不特定です。
An additional "filter type" byte is added to the beginning of
every scanline (see Filtering, Section 2.5). The filter type byte
is not considered part of the image data, but it is included in
the datastream sent to the compression step.
追加「フィルタタイプ」バイトはあらゆる走査線の始まりに加えられます(Filtering、セクション2.5を見てください)。 フィルタタイプバイトはイメージデータの一部であると考えられませんが、それは圧縮ステップに送られたdatastreamに含まれています。
2.4. Alpha channel
2.4. アルファーチャンネル
An alpha channel, representing transparency information on a per-
pixel basis, can be included in grayscale and truecolor PNG
images.
aの透明情報を表すアルファチャンネル、-、画素基礎含まれているコネがグレースケールとtruecolor PNGイメージであったかもしれないなら。
An alpha value of zero represents full transparency, and a value
of (2^bitdepth)-1 represents a fully opaque pixel. Intermediate
values indicate partially transparent pixels that can be combined
with a background image to yield a composite image. (Thus, alpha
is really the degree of opacity of the pixel. But most people
refer to alpha as providing transparency information, not opacity
information, and we continue that custom here.)
ゼロの文字値は完全な透明を表します、そして、(2^bitdepth)-1の値は完全に不明瞭な画素を表します。 中間的値は合成画像をもたらすために背景画像に結合できる部分的に見え透いた画素を示します。 (したがって、アルファは本当に画素の不透明の度合いです。 しかし、ほとんどの人々が不透明度の情報ではなく、透明情報を提供するとアルファを呼びます、そして、私たちはここでその習慣を続けています。)
Alpha channels can be included with images that have either 8 or
16 bits per sample, but not with images that have fewer than 8
bits per sample. Alpha samples are represented with the same bit
depth used for the image samples. The alpha sample for each pixel
is stored immediately following the grayscale or RGB samples of
the pixel.
8ビットか1サンプルあたり16ビットを持っていますが、8ビット未満を持っているイメージでサンプル単位で持っているというわけではないイメージでアルファーチャンネルを含むことができます。 アルファのサンプルは深さがイメージのサンプルに使用した同じビットで表されます。 すぐに画素のグレースケールかRGBのサンプルに従って、各画素アルファのサンプルは格納されます。
Boutell, et. al. Informational [Page 7] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[7ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
The color values stored for a pixel are not affected by the alpha
value assigned to the pixel. This rule is sometimes called
"unassociated" or "non-premultiplied" alpha. (Another common
technique is to store sample values premultiplied by the alpha
fraction; in effect, such an image is already composited against a
black background. PNG does not use premultiplied alpha.)
画素のために格納された色の値は画素に割り当てられた文字値で影響を受けません。 この規則は時々"非連想"の、または、「非前掛け算をさせられた」アルファと呼ばれます。 (別の一般的なテクニックはアルファ分画によって前掛け算をさせられる標本値を格納することです。 事実上、そのようなイメージは黒いバックグラウンドに対して既に合成されます。 PNGは前掛け算をさせられたアルファを使用しません。)
Transparency control is also possible without the storage cost of
a full alpha channel. In an indexed-color image, an alpha value
can be defined for each palette entry. In grayscale and truecolor
images, a single pixel value can be identified as being
"transparent". These techniques are controlled by the tRNS
ancillary chunk type.
また、透明コントロールも完全なアルファチャンネルの倉庫保管料なしで可能です。 索引をつけられたカラーイメージでは、それぞれのパレットエントリーと文字値を定義できます。 グレースケールとtruecolorイメージで、「透明」であるとしてただ一つのピクセル値を特定できます。 これらのテクニックはtRNSの付属の塊タイプによって制御されます。
If no alpha channel nor tRNS chunk is present, all pixels in the
image are to be treated as fully opaque.
または、アルファチャンネルでない、tRNS塊が存在している、イメージによるすべての画素は同じくらい完全に不透明な状態で扱われることです。
Viewers can support transparency control partially, or not at all.
ビューアーは透明コントロールを部分的、または全く支持できません。
See Rationale: Non-premultiplied alpha (Section 12.8),
Recommendations for Encoders: Alpha channel creation (Section
9.4), and Recommendations for Decoders: Alpha channel processing
(Section 10.8).
原理を見てください: 非前掛け算をさせられたアルファ(セクション12.8)、EncodersのためのRecommendations: アルファチャンネル創造(セクション9.4)、およびDecodersのためのRecommendations: アルファチャンネル処理(セクション10.8)。
2.5. Filtering
2.5. フィルタリング
PNG allows the image data to be filtered before it is compressed.
Filtering can improve the compressibility of the data. The filter
step itself does not reduce the size of the data. All PNG filters
are strictly lossless.
それが圧縮される前にPNGは、イメージデータがフィルターにかけられるのを許容します。 フィルタリングはデータの圧縮性を改良できます。 フィルタステップ自体はデータのサイズを減少させません。 すべてのPNGフィルタが厳密にlosslessです。
PNG defines several different filter algorithms, including "None"
which indicates no filtering. The filter algorithm is specified
for each scanline by a filter type byte that precedes the filtered
scanline in the precompression datastream. An intelligent encoder
can switch filters from one scanline to the next. The method for
choosing which filter to employ is up to the encoder.
PNGはフィルターにかけないことを示す「なにも」を含むいくつかの異なったフィルタアルゴリズムを定義します。 フィルタアルゴリズムは各走査線にprecompression datastreamでフィルターにかけることの走査線に先行するフィルタタイプバイト指定されます。 知的なエンコーダは1つの走査線から次にフィルタを切り換えることができます。 どのフィルタを使ったらよいかを選ぶための方法はエンコーダ次第です。
See Filter Algorithms (Chapter 6) and Rationale: Filtering
(Section 12.9).
フィルタアルゴリズム(第6章)と原理を見てください: (セクション12.9)をフィルターにかけます。
2.6. Interlaced data order
2.6. 交錯しているデータオーダー
A PNG image can be stored in interlaced order to allow progressive
display. The purpose of this feature is to allow images to "fade
in" when they are being displayed on-the-fly. Interlacing
slightly expands the file size on average, but it gives the user a
meaningful display much more rapidly. Note that decoders are
進歩的な表示を許す交錯している命令にPNGイメージを格納できます。 この特徴の目的は急いでそれらを表示しているとき、イメージが「次第にはっきりされること」を許容することです。 わずかに交錯するのはファイルサイズを平均的に広げますが、それははるかに急速に重要な表示をユーザに与えます。 デコーダがそうであることに注意してください。
Boutell, et. al. Informational [Page 8] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[8ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
required to be able to read interlaced images, whether or not they
actually perform progressive display.
それらが実際に進歩的な表示を実行するか否かに関係なく、交錯しているイメージを読むことができるのが必要です。
With interlace method 0, pixels are stored sequentially from left
to right, and scanlines sequentially from top to bottom (no
interlacing).
インターレース方法0で、画素は上から下まで(交錯しない)権利、および左から走査線まで連続して連続して格納されます。
Interlace method 1, known as Adam7 after its author, Adam M.
Costello, consists of seven distinct passes over the image. Each
pass transmits a subset of the pixels in the image. The pass in
which each pixel is transmitted is defined by replicating the
following 8-by-8 pattern over the entire image, starting at the
upper left corner:
作者、アダム・M.コステロの後にAdam7として知られているインターレース方法1はイメージの上で7個の異なったパスから成ります。 各パスはイメージで画素の部分集合を伝えます。 各画素が伝えられるパスは全体のイメージの上に以下の8×8パターンを模写することによって、定義されます、左上隅で始まって:
1 6 4 6 2 6 4 6
7 7 7 7 7 7 7 7
5 6 5 6 5 6 5 6
7 7 7 7 7 7 7 7
3 6 4 6 3 6 4 6
7 7 7 7 7 7 7 7
5 6 5 6 5 6 5 6
7 7 7 7 7 7 7 7
1 6 4 6 2 6 4 6 7 7 7 7 7 7 7 7 5 6 5 6 5 6 5 6 7 7 7 7 7 7 7 7 3 6 4 6 3 6 4 6 7 7 7 7 7 7 7 7 5 6 5 6 5 6 5 6 7 7 7 7 7 7 7 7
Within each pass, the selected pixels are transmitted left to
right within a scanline, and selected scanlines sequentially from
top to bottom. For example, pass 2 contains pixels 4, 12, 20,
etc. of scanlines 0, 8, 16, etc. (numbering from 0,0 at the upper
left corner). The last pass contains the entirety of scanlines 1,
3, 5, etc.
各パスの中では、選択された画素は走査線、および選択された走査線の中の右への連続して上から下まで伝えられた左です。 例えば、パス2は画素4、12、20などの走査線0、8、16などを含んでいます。 (0、左上隅の0から、付番します。) 最後のパスは走査線1、3、5などの全体を含んでいます。
The data within each pass is laid out as though it were a complete
image of the appropriate dimensions. For example, if the complete
image is 16 by 16 pixels, then pass 3 will contain two scanlines,
each containing four pixels. When pixels have fewer than 8 bits,
each such scanline is padded as needed to fill an integral number
of bytes (see Image layout, Section 2.3). Filtering is done on
this reduced image in the usual way, and a filter type byte is
transmitted before each of its scanlines (see Filter Algorithms,
Chapter 6). Notice that the transmission order is defined so that
all the scanlines transmitted in a pass will have the same number
of pixels; this is necessary for proper application of some of the
filters.
各パスの中のデータはまるでそれが適切な寸法の完全なイメージであるかのように広げられます。 例えば、パス3は完全なイメージが16画素の16であるなら2つの走査線を含むでしょう、それぞれ4画素を含んでいて。 画素に8ビット未満があると、そのような各走査線は、整数のバイトをいっぱいにするために必要に応じて水増しされます(Imageレイアウトを見てください、セクション2.3)。 この減少しているイメージで不断のとおりフィルタリングをします、そして、それぞれの走査線の前にフィルタタイプバイトを伝えます(Filter Algorithmsを見てください、第6章)。 パスで伝えられたすべての走査線が同じピクセル数を持つようにトランスミッション命令が定義されるのに注意してください。 これがいくつかのフィルタの正当な適用に必要です。
Caution: If the image contains fewer than five columns or fewer
than five rows, some passes will be entirely empty. Encoders and
decoders must handle this case correctly. In particular, filter
type bytes are only associated with nonempty scanlines; no filter
type bytes are present in an empty pass.
警告: イメージが5つ未満のコラムか5つ未満の列を含んでいると、いくつかのパスが完全に空になるでしょう。 エンコーダとデコーダは正しく本件を扱わなければなりません。 フィルタタイプバイトはnonempty走査線に特に、関連しているだけです。 どんなフィルタタイプバイトも空のパスに存在していません。
Boutell, et. al. Informational [Page 9] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[9ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
See Rationale: Interlacing (Section 12.6) and Recommendations for
Decoders: Progressive display (Section 10.9).
原理を見てください: デコーダのための交錯(セクション12.6)と推薦: 進歩的な表示(セクション10.9)。
2.7. Gamma correction
2.7. ガンマ補正
PNG images can specify, via the gAMA chunk, the gamma
characteristic of the image with respect to the original scene.
Display programs are strongly encouraged to use this information,
plus information about the display device they are using and room
lighting, to present the image to the viewer in a way that
reproduces what the image's original author saw as closely as
possible. See Gamma Tutorial (Chapter 13) if you aren't already
familiar with gamma issues.
PNGイメージは元の場面に関してgAMA塊でイメージのガンマの特性を指定できます。 表示プログラムがそれらが使用しているディスプレイ装置とイメージの原作者ができるだけ密接に見たものを再生させる方法でビューアーにイメージを提示するために火が付く余地の周りでこの情報、および情報を使用するよう強く奨励されます。 既にガンマ問題になじみ深くないなら、Gamma Tutorial(第13章)を見てください。
Gamma correction is not applied to the alpha channel, if any.
Alpha samples always represent a linear fraction of full opacity.
ガンマ修正はもしあればアルファチャンネルに適用されません。 アルファのサンプルはいつも完全な不透明について直線的な断片を表します。
For high-precision applications, the exact chromaticity of the RGB
data in a PNG image can be specified via the cHRM chunk, allowing
more accurate color matching than gamma correction alone will
provide. See Color Tutorial (Chapter 14) if you aren't already
familiar with color representation issues.
高精度アプリケーションとして、cHRM塊でPNGイメージによるRGBデータの正確な色度を指定できます、と単独でガンマ修正より正確な色のマッチングを許すのは前提とするでしょう。 既に色の表現問題になじみ深くないなら、Color Tutorial(第14章)を見てください。
See Rationale: Why gamma? (Section 12.7), Recommendations for
Encoders: Encoder gamma handling (Section 9.2), and
Recommendations for Decoders: Decoder gamma handling (Section
10.5).
原理を見てください: なぜガンマ? (セクション12.7), エンコーダのための推薦: エンコーダガンマ取り扱い(セクション9.2)、およびDecodersのためのRecommendations: デコーダガンマ取り扱い(セクション10.5)。
2.8. Text strings
2.8. テキスト文字列
A PNG file can store text associated with the image, such as an
image description or copyright notice. Keywords are used to
indicate what each text string represents.
PNGファイルはイメージ記述か版権情報などのイメージに関連しているテキストを格納できます。 キーワードは、各テキスト文字列が表すことを示すのに使用されます。
ISO 8859-1 (Latin-1) is the character set recommended for use in
text strings [ISO-8859]. This character set is a superset of 7-
bit ASCII.
ISO8859-1(ラテン-1)はテキスト文字列[ISO-8859]における使用のために推薦された文字の組です。 この文字の組は7の噛み付いているASCIIのスーパーセットです。
Character codes not defined in Latin-1 should not be used, because
they have no platform-independent meaning. If a non-Latin-1 code
does appear in a PNG text string, its interpretation will vary
across platforms and decoders. Some systems might not even be
able to display all the characters in Latin-1, but most modern
systems can.
それらにはどんなプラットホームから独立している意味もないので、ラテン語-1で定義されなかったキャラクターコードを使用するべきではありません。 非ラテンの1つのコードがPNGテキスト文字列に現れると、解釈はプラットホームとデコーダの向こう側に異なるでしょう。 いくつかのシステムがラテン語-1ですべてのキャラクタを見せることさえできるかもしれないというわけではありませんが、ほとんどの現代のシステムは見せることができます。
Provision is also made for the storage of compressed text.
また、設備は圧縮されたテキストの格納に作られています。
See Rationale: Text strings (Section 12.10).
原理を見てください: テキストは(セクション12.10)を結びます。
Boutell, et. al. Informational [Page 10] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[10ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
3. File Structure
3. ファイル構造
A PNG file consists of a PNG signature followed by a series of chunks. This chapter defines the signature and the basic properties of chunks. Individual chunk types are discussed in the next chapter.
PNGファイルは一連の塊があとに続いたPNG署名から成ります。 本章は塊の署名と基礎特性を定義します。 独特の塊タイプは次の章で論じられます。
3.1. PNG file signature
3.1. PNGファイル署名
The first eight bytes of a PNG file always contain the following
(decimal) values:
PNGファイルの最初の8バイトはいつも以下の(10進)の値を含んでいます:
137 80 78 71 13 10 26 10
137 80 78 71 13 10 26 10
This signature indicates that the remainder of the file contains a
single PNG image, consisting of a series of chunks beginning with
an IHDR chunk and ending with an IEND chunk.
この署名は、ファイルの残りがただ一つのPNGイメージを含むのを示します、IHDR塊で始まって、IEND塊で終わる一連の塊から成って。
See Rationale: PNG file signature (Section 12.11).
原理を見てください: PNGは署名(セクション12.11)をファイルします。
3.2. Chunk layout
3.2. 塊レイアウト
Each chunk consists of four parts:
各塊は4つの部品から成ります:
Length
A 4-byte unsigned integer giving the number of bytes in the
chunk's data field. The length counts only the data field, not
itself, the chunk type code, or the CRC. Zero is a valid
length. Although encoders and decoders should treat the length
as unsigned, its value must not exceed (2^31)-1 bytes.
塊のデータのバイト数がさばく長さのA4バイトの符号のない整数付与。 長さはそれ自体、塊タイプコード、またはCRCではなく、データ・フィールドだけを数えます。 ゼロは有効な長さです。 エンコーダとデコーダは無記名として長さを扱うはずですが、値は-1バイトを超えてはいけません(2^31)。
Chunk Type
A 4-byte chunk type code. For convenience in description and
in examining PNG files, type codes are restricted to consist of
uppercase and lowercase ASCII letters (A-Z and a-z, or 65-90
and 97-122 decimal). However, encoders and decoders must treat
the codes as fixed binary values, not character strings. For
example, it would not be correct to represent the type code
IDAT by the EBCDIC equivalents of those letters. Additional
naming conventions for chunk types are discussed in the next
section.
塊のTypeのA4バイトの塊タイプコード。 記述とPNGファイルを調べることにおける便利において、タイプコードは、大文字していて小文字のASCII手紙(1Zの、そして、1zの、または、65-90と97-122 10進の)から成るように制限されます。 しかしながら、エンコーダとデコーダは文字列ではなく、固定2進の値としてコードを扱わなければなりません。 例えば、それらの手紙のEBCDIC同等物でタイプコードIDATを表すのは正しくないでしょう。 次のセクションで塊タイプのための追加命名規則について議論します。
Chunk Data
The data bytes appropriate to the chunk type, if any. This
field can be of zero length.
塊に適切なデータ・バイトがもしあればタイプする塊Data この分野はゼロ・レングスのものであることができます。
Boutell, et. al. Informational [Page 11] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[11ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
CRC
A 4-byte CRC (Cyclic Redundancy Check) calculated on the
preceding bytes in the chunk, including the chunk type code and
chunk data fields, but not including the length field. The CRC
is always present, even for chunks containing no data. See CRC
algorithm (Section 3.4).
CRCのA4バイトのCRC(周期的なRedundancy Check)は塊における前のバイトを当てにしました、塊タイプコードと塊データ・フィールドを含んでいますが、長さの分野は含んでいなくて。 CRCはデータを全く含まない塊のためにさえいつも存在しています。 CRCアルゴリズム(セクション3.4)を見てください。
The chunk data length can be any number of bytes up to the
maximum; therefore, implementors cannot assume that chunks are
aligned on any boundaries larger than bytes.
最大まで塊データの長さはどんなバイト数であるかもしれませんも。 したがって、作成者は、塊がバイトより大きいどんな境界でも並べられると仮定できません。
Chunks can appear in any order, subject to the restrictions placed
on each chunk type. (One notable restriction is that IHDR must
appear first and IEND must appear last; thus the IEND chunk serves
as an end-of-file marker.) Multiple chunks of the same type can
appear, but only if specifically permitted for that type.
塊は順不同にそれぞれの塊タイプに関して課される制限を条件として現れることができます。 (IENDは最後に現れなければなりません; 1つの注目に値する制限はIHDRが最初に現れなければならないということであり、その結果、IEND塊はファイルの終りマーカーとして機能します。) そのタイプのために明確に受入れられる場合にだけ、同じタイプの複数の塊が現れることができます。
See Rationale: Chunk layout (Section 12.12).
原理を見てください: 塊レイアウト(セクション12.12)。
3.3. Chunk naming conventions
3.3. 塊命名規則
Chunk type codes are assigned so that a decoder can determine some
properties of a chunk even when it does not recognize the type
code. These rules are intended to allow safe, flexible extension
of the PNG format, by allowing a decoder to decide what to do when
it encounters an unknown chunk. The naming rules are not normally
of interest when the decoder does recognize the chunk's type.
塊タイプコードは、タイプコードを認識さえしないとき、デコーダが塊のいくつかの特性を決定できるように、割り当てられます。 これらの規則がPNG形式の安全で、フレキシブルな拡大を許すことを意図します、未知の塊に遭遇するときデコーダが、何をしたらよいかを決めるのを許容することによって。 デコーダが塊のタイプを見分けるとき、通常、命名規則は興味がありません。
Four bits of the type code, namely bit 5 (value 32) of each byte,
are used to convey chunk properties. This choice means that a
human can read off the assigned properties according to whether
each letter of the type code is uppercase (bit 5 is 0) or
lowercase (bit 5 is 1). However, decoders should test the
properties of an unknown chunk by numerically testing the
specified bits; testing whether a character is uppercase or
lowercase is inefficient, and even incorrect if a locale-specific
case definition is used.
タイプコードの4ビット(すなわち、それぞれのバイトのビット5(値32))は、塊の特性を伝えるのに使用されます。 この選択は、人間がタイプコードのそれぞれの手紙が大文字しているかどうかに従って(ビット5は0です)割り当てられた特性を読みだすか、または小文字で印刷できることを意味します(ビット5は1です)。 しかしながら、デコーダは数の上で指定されたビットをテストすることによって、未知の塊の特性をテストするはずです。 現場特有のケース定義が使用されているなら、キャラクタが大文字するか、または小文字であることにかかわらずテストするのは不正確な状態で効率が悪くさえあります。
It is worth noting that the property bits are an inherent part of
the chunk name, and hence are fixed for any chunk type. Thus,
TEXT and Text would be unrelated chunk type codes, not the same
chunk with different properties. Decoders must recognize type
codes by a simple four-byte literal comparison; it is incorrect to
perform case conversion on type codes.
特性のビットが塊名の固有の部分であり、したがって、どんな塊タイプのためにも固定されていることに注意する価値があります。 したがって、TEXTとTextは異なった特性がある同じ塊ではなく、関係ない塊タイプコードでしょう。 デコーダは簡単な4バイトの文字通りの比較でタイプコードを認識しなければなりません。 タイプコードにケース変換を実行するのは不正確です。
Boutell, et. al. Informational [Page 12] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[12ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
The semantics of the property bits are:
特性のビットの意味論は以下の通りです。
Ancillary bit: bit 5 of first byte
0 (uppercase) = critical, 1 (lowercase) = ancillary.
付属のビット: 最初に、バイト0(大文字します)のビット5は1つ(小文字で印刷する)の批判的な=付属と等しいです。
Chunks that are not strictly necessary in order to meaningfully
display the contents of the file are known as "ancillary"
chunks. A decoder encountering an unknown chunk in which the
ancillary bit is 1 can safely ignore the chunk and proceed to
display the image. The time chunk (tIME) is an example of an
ancillary chunk.
意味深長にファイルのコンテンツを表示するのに厳密に必要でない塊は「付属」の塊として知られています。 付属のビットが1である未知の塊に遭遇するデコーダは、安全に塊を無視して、イメージを表示しかけることができます。 時間塊(tIME)は付属の塊に関する例です。
Chunks that are necessary for successful display of the file's
contents are called "critical" chunks. A decoder encountering
an unknown chunk in which the ancillary bit is 0 must indicate
to the user that the image contains information it cannot
safely interpret. The image header chunk (IHDR) is an example
of a critical chunk.
ファイルのコンテンツのうまくいっている表示に必要な塊は「批判的な」塊と呼ばれます。 付属のビットが0である未知の塊に遭遇するデコーダは、イメージがそれが安全に解釈できない情報を含むのをユーザに示さなければなりません。 イメージヘッダー塊(IHDR)は批判的な塊に関する例です。
Private bit: bit 5 of second byte
0 (uppercase) = public, 1 (lowercase) = private.
個人的なビット: 公共の1(小文字で印刷する)2番目のバイト0(大文字する)の5==に噛み付いて、個人的にしました。
A public chunk is one that is part of the PNG specification or
is registered in the list of PNG special-purpose public chunk
types. Applications can also define private (unregistered)
chunks for their own purposes. The names of private chunks
must have a lowercase second letter, while public chunks will
always be assigned names with uppercase second letters. Note
that decoders do not need to test the private-chunk property
bit, since it has no functional significance; it is simply an
administrative convenience to ensure that public and private
chunk names will not conflict. See Additional chunk types
(Section 4.4) and Recommendations for Encoders: Use of private
chunks (Section 9.8).
公共の塊は、PNG仕様の一部であるものであるかPNGの専用公共の塊タイプのリストに登録されます。 また、アプリケーションはそれら自身の目的のために個人的な(登録されていない)塊を定義できます。 個人的な塊の名前には、2番目の小文字の手紙がなければなりません、2番目の大文字している手紙の名前はいつも公共の塊に割り当てられるでしょうが。 それには機能的意義が全くないので、デコーダが個人的な塊特性のビットをテストする必要はないことに注意してください。 公共の、そして、個人的な塊名が闘争しないのを保証するのは、単に管理便利です。 Encodersに関してAdditional塊タイプ(セクション4.4)とRecommendationsを見てください: 個人的な塊(セクション9.8)の使用。
Reserved bit: bit 5 of third byte
Must be 0 (uppercase) in files conforming to this version of
PNG.
予約されたビット: 0がPNGのこのバージョンに一致しているファイルで(大文字する)であったなら、5 3番目のバイトMustに噛み付きました。
The significance of the case of the third letter of the chunk
name is reserved for possible future expansion. At the present
time all chunk names must have uppercase third letters.
(Decoders should not complain about a lowercase third letter,
however, as some future version of the PNG specification could
define a meaning for this bit. It is sufficient to treat a
chunk with a lowercase third letter in the same way as any
other unknown chunk type.)
塊名の3番目の手紙に関するケースの意味は可能な今後の拡大のために予約されます。 現在では、すべての塊名が第3大文字している手紙を持たなければなりません。 (しかしながら、PNG仕様の何らかの将来のバージョンがこのビットのために意味を定義するかもしれないようにデコーダに3番目の小文字の手紙の周りで不平を言うはずがありません。 いかなる他の未知の塊タイプとも同様に、3番目の小文字の手紙で塊を扱うのは十分です。)
Boutell, et. al. Informational [Page 13] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[13ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
Safe-to-copy bit: bit 5 of fourth byte
0 (uppercase) = unsafe to copy, 1 (lowercase) = safe to copy.
コピーする金庫に噛み付きました: 4番目のバイト0(大文字する)のビット5は、コピーするために1個(小文字で印刷する)のコピーする危険な=金庫と等しいです。
This property bit is not of interest to pure decoders, but it
is needed by PNG editors (programs that modify PNG files).
This bit defines the proper handling of unrecognized chunks in
a file that is being modified.
この特性のビットは純粋なデコーダに興味がありませんが、それはPNGエディタ(PNGファイルを変更するプログラム)によって必要とされます。 このビットは変更されているファイルにおける認識されていない塊の適切な取り扱いを定義します。
If a chunk's safe-to-copy bit is 1, the chunk may be copied to
a modified PNG file whether or not the software recognizes the
chunk type, and regardless of the extent of the file
modifications.
塊のコピーするために安全なビットが1であるなら、ソフトウェアが塊タイプを見分けて、ファイル変更の範囲にかかわらずコピーされるか否かに関係なく、塊は変更されたPNGファイルにコピーされるかもしれません。
If a chunk's safe-to-copy bit is 0, it indicates that the chunk
depends on the image data. If the program has made any changes
to critical chunks, including addition, modification, deletion,
or reordering of critical chunks, then unrecognized unsafe
chunks must not be copied to the output PNG file. (Of course,
if the program does recognize the chunk, it can choose to
output an appropriately modified version.)
塊のコピーするために安全なビットが0であるなら、それは、塊がイメージデータによるのを示します。 プログラムが何か批判的な塊に関する添加、変更、削除、または再命令を含む批判的な塊への変更を行ったなら、出力PNGファイルに認識されていない危険な塊をコピーしてはいけません。 (もちろん、プログラムが塊を認識するなら、それは適切に変更されたバージョンを出力するのを選ぶことができます。)
A PNG editor is always allowed to copy all unrecognized chunks
if it has only added, deleted, modified, or reordered ancillary
chunks. This implies that it is not permissible for ancillary
chunks to depend on other ancillary chunks.
付属の塊を加えるか、削除するか、変更するか、または再命令するだけであったなら、PNGエディタはいつもすべての認識されていない塊をコピーできます。 これは、付属の塊が他の付属の塊によるのが、許されていないのを含意します。
PNG editors that do not recognize a critical chunk must report
an error and refuse to process that PNG file at all. The
safe/unsafe mechanism is intended for use with ancillary
chunks. The safe-to-copy bit will always be 0 for critical
chunks.
批判的な塊を認めないPNGエディタは、誤りを報告して、全くそのPNGファイルを処理するのを拒否しなければなりません。 安全であるか危険なメカニズムは付属の塊がある使用のために意図します。 コピーするために安全なビットは批判的な塊のためにいつも0になるでしょう。
Rules for PNG editors are discussed further in Chunk Ordering
Rules (Chapter 7).
Chunk Ordering Rules(第7章)で、より詳しくPNGエディタへの規則について議論します。
For example, the hypothetical chunk type name "bLOb" has the
property bits:
例えば、「一滴」という仮定している塊型名には、特性のビットがあります:
bLOb <-- 32 bit chunk type code represented in text form
||||
|||+- Safe-to-copy bit is 1 (lower case letter; bit 5 is 1)
||+-- Reserved bit is 0 (upper case letter; bit 5 is 0)
|+--- Private bit is 0 (upper case letter; bit 5 is 0)
+---- Ancillary bit is 1 (lower case letter; bit 5 is 1)
bLOb<--テキストフォームで表された32ビットの塊タイプコード|||| |||+コピーするために安全なビットは1(ケース手紙を下ろしてください; ビット5は1である)です。||+--予約されたビットは0(大文字アルファベット; 5に噛み付くのは、0である)です。|+--- 個人的なビットは0(大文字アルファベット; 5に噛み付くのは、0である)+です。---- 付属のビットは1です。(ケース手紙を下ろしてください; ビット5は1です)
Therefore, this name represents an ancillary, public, safe-to-copy
chunk.
したがって、この名前は付属の、そして、公共の、そして、コピーするために安全な塊を表します。
Boutell, et. al. Informational [Page 14] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[14ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
See Rationale: Chunk naming conventions (Section 12.13).
原理を見てください: 塊命名規則(セクション12.13)。
3.4. CRC algorithm
3.4. CRCアルゴリズム
Chunk CRCs are calculated using standard CRC methods with pre and
post conditioning, as defined by ISO 3309 [ISO-3309] or ITU-T V.42
[ITU-V42]. The CRC polynomial employed is
そして、塊CRCsが標準のCRC方法を使用することで計算される、前、調節を掲示してください、ISO3309[ISO-3309]かITU-T V.42[ITU-V42]によって定義されるように。 使われたCRC多項式はそうです。
x^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^7+x^5+x^4+x^2+x+1
x^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^7+x^5+x^4+x^2+x+1
The 32-bit CRC register is initialized to all 1's, and then the
data from each byte is processed from the least significant bit
(1) to the most significant bit (128). After all the data bytes
are processed, the CRC register is inverted (its ones complement
is taken). This value is transmitted (stored in the file) MSB
first. For the purpose of separating into bytes and ordering, the
least significant bit of the 32-bit CRC is defined to be the
coefficient of the x^31 term.
32ビットのCRCレジスタはすべての1に初期化されます、そして、次に、各バイトからのデータは最下位ビット(1)から最も重要なビット(128)まで処理されます。 すべてのデータ・バイトが処理された後に、CRCレジスタが逆さである、(もの、補数を取る、) 最初に、この値は伝えられた(ファイルでは、格納される)MSBです。 バイトを分ける目的と注文、32ビットの最下位ビットにおいて、CRCは、x^31用語の係数になるように定義されます。
Practical calculation of the CRC always employs a precalculated
table to greatly accelerate the computation. See Sample CRC Code
(Chapter 15).
CRCの実用的な計算は、計算を大いに加速するのにいつも前計算されたテーブルを使います。 サンプルCRCコード(第15章)を見てください。
4. Chunk Specifications
4. 塊仕様
This chapter defines the standard types of PNG chunks.
本章はPNG塊の標準体型を定義します。
4.1. Critical chunks
4.1. 批判的な塊
All implementations must understand and successfully render the
standard critical chunks. A valid PNG image must contain an IHDR
chunk, one or more IDAT chunks, and an IEND chunk.
すべての実現が、分かって、首尾よく標準の批判的な塊をレンダリングしなければなりません。 有効なPNGイメージはIHDR塊、1つ以上のIDAT塊、およびIEND塊を含まなければなりません。
4.1.1. IHDR Image header
4.1.1. IHDR Imageヘッダー
The IHDR chunk must appear FIRST. It contains:
IHDR塊はFIRSTに現れなければなりません。それは以下を含んでいます。
Width: 4 bytes
Height: 4 bytes
Bit depth: 1 byte
Color type: 1 byte
Compression method: 1 byte
Filter method: 1 byte
Interlace method: 1 byte
幅: 4バイトのHeight: 4バイトのBitの深さ: 1バイトのColorはタイプします: 1バイトのCompression方法: 1バイトのFilter方法: 1バイトのInterlace方法: 1バイト
Boutell, et. al. Informational [Page 15] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[15ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
Width and height give the image dimensions in pixels. They are
4-byte integers. Zero is an invalid value. The maximum for each
is (2^31)-1 in order to accommodate languages that have
difficulty with unsigned 4-byte values.
幅と高さは画素のイメージの重要性を与えます。 それらは4バイトの整数です。 ゼロは無効の値です。 それぞれのための最大は、無記名の4バイトの値における苦労をする言語に対応する(2^31)-1です。
Bit depth is a single-byte integer giving the number of bits
per sample or per palette index (not per pixel). Valid values
are 1, 2, 4, 8, and 16, although not all values are allowed for
all color types.
噛み付いている深さはサンプルかパレットインデックス(1画素でないのあたりの)あたりのビットの数を与える単一のバイト整数です。 有効値は、1と、2と、4と、8と、すべての値がすべてのカラータイプのために許容されるというわけではありませんが、16です。
Color type is a single-byte integer that describes the
interpretation of the image data. Color type codes represent
sums of the following values: 1 (palette used), 2 (color used),
and 4 (alpha channel used). Valid values are 0, 2, 3, 4, and 6.
カラータイプはイメージデータの解釈について説明する単一のバイト整数です。 色のタイプコードは以下の値の合計を表します: 1 (使用されるパレット)、2(使用される色)と4(使用されるアルファチャンネル)。 有効値は、0と、2と、3と、4と、6です。
Bit depth restrictions for each color type are imposed to
simplify implementations and to prohibit combinations that do
not compress well. Decoders must support all legal
combinations of bit depth and color type. The allowed
combinations are:
それぞれのカラータイプのための噛み付いている深さ制限は、実現を簡素化して、井戸を圧縮しない組み合わせを禁止するために課されます。 デコーダは噛み付いている深さとカラータイプのすべての法的な組み合わせをサポートしなければなりません。 許容組み合わせは以下の通りです。
Color Allowed Interpretation
Type Bit Depths
解釈タイプビット深層が許容された色
0 1,2,4,8,16 Each pixel is a grayscale sample.
0 1、2、4、8、16Each画素がグレースケールのサンプルです。
2 8,16 Each pixel is an R,G,B triple.
2 8、16Each画素がRである、G、Bは3倍になります。
3 1,2,4,8 Each pixel is a palette index;
a PLTE chunk must appear.
3 1、2、4、8Each画素がパレットインデックスです。 PLTE塊は現れなければなりません。
4 8,16 Each pixel is a grayscale sample,
followed by an alpha sample.
4 8、16Each画素が、アルファのサンプルは、グレースケールのサンプルであって、支えます。
6 8,16 Each pixel is an R,G,B triple,
followed by an alpha sample.
G(B三重)は、アルファのサンプルで6 8、16Each画素がRであるのに続きました。
The sample depth is the same as the bit depth except in the
case of color type 3, in which the sample depth is always 8
bits.
カラータイプ3に関するケースを除いて、サンプルの深さは噛み付いている深さと同じです。(いつもサンプルの深さはタイプで8ビットです)。
Compression method is a single-byte integer that indicates the
method used to compress the image data. At present, only
compression method 0 (deflate/inflate compression with a 32K
sliding window) is defined. All standard PNG images must be
compressed with this scheme. The compression method field is
provided for possible future expansion or proprietary variants.
Decoders must check this byte and report an error if it holds
圧縮方法は方法が以前はよくイメージデータを圧縮していたのを示す単一のバイト整数です。 現在のところ、圧縮方法0だけ(32Kの引窓で圧縮を空気を抜くか、またはふくらませます)が定義されます。 この計画ですべての標準のPNGイメージを圧縮しなければなりません。 可能な今後の拡大か独占異形に圧縮方法野原を提供します。 持ちこたえるなら、デコーダは、このバイトをチェックして、誤りを報告しなければなりません。
Boutell, et. al. Informational [Page 16] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[16ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
an unrecognized code. See Deflate/Inflate Compression (Chapter
5) for details.
認識されていないコード。 Deflate/が詳細のために、Compression(第5章)をふくらませるのを見てください。
Filter method is a single-byte integer that indicates the
preprocessing method applied to the image data before
compression. At present, only filter method 0 (adaptive
filtering with five basic filter types) is defined. As with
the compression method field, decoders must check this byte and
report an error if it holds an unrecognized code. See Filter
Algorithms (Chapter 6) for details.
ドリップ式は前処理方法が圧縮の前にイメージデータに適用されたのを示す単一のバイト整数です。 現在のところ、ドリップ式0だけ(5つの基本的なフィルタタイプがある適応型のフィルタリング)が定義されます。 圧縮方法分野なら、認識されていないコードを保持するなら、デコーダは、このバイトをチェックして、誤りを報告しなければなりません。 詳細に関してFilter Algorithms(第6章)を見てください。
Interlace method is a single-byte integer that indicates the
transmission order of the image data. Two values are currently
defined: 0 (no interlace) or 1 (Adam7 interlace). See
Interlaced data order (Section 2.6) for details.
インターレース方法はイメージデータのトランスミッション命令を示す単一のバイト整数です。 2つの値が現在、定義されます: 0 (インターレースがありません) または、1(Adam7インターレース)。 詳細のInterlacedデータ注文(セクション2.6)を見てください。
4.1.2. PLTE Palette
4.1.2. PLTEパレット
The PLTE chunk contains from 1 to 256 palette entries, each a
three-byte series of the form:
PLTE塊は1〜256パレットからエントリーを含んでいて、それぞれがフォームの3バイトのシリーズです:
Red: 1 byte (0 = black, 255 = red)
Green: 1 byte (0 = black, 255 = green)
Blue: 1 byte (0 = black, 255 = blue)
赤: 1バイト(0は黒と等しく、255は赤と等しい)のグリーン: 1バイト(0=黒、255=緑色)の青: 1バイト(0=黒、255=青)
The number of entries is determined from the chunk length. A
chunk length not divisible by 3 is an error.
エントリーの数は塊の長さから決定しています。 3で分割可能でない塊の長さは誤りです。
This chunk must appear for color type 3, and can appear for
color types 2 and 6; it must not appear for color types 0 and
4. If this chunk does appear, it must precede the first IDAT
chunk. There must not be more than one PLTE chunk.
この塊は、カラータイプ3の弁護に出廷しなければならなくて、カラータイプ2と6の弁護に出廷することができます。 それはカラータイプ0と4の弁護に出廷してはいけません。 この塊が現れるなら、それは最初のIDAT塊に先行しなければなりません。 1つ以上のPLTE塊があるはずがありません。
For color type 3 (indexed color), the PLTE chunk is required.
The first entry in PLTE is referenced by pixel value 0, the
second by pixel value 1, etc. The number of palette entries
must not exceed the range that can be represented in the image
bit depth (for example, 2^4 = 16 for a bit depth of 4). It is
permissible to have fewer entries than the bit depth would
allow. In that case, any out-of-range pixel value found in the
image data is an error.
カラータイプ3(色に索引をつけます)において、PLTE塊が必要です。 PLTEの初記入はピクセル値0、ピクセル値1による2番目などによって参照をつけられます。 パレットエントリーの数はイメージの噛み付いている深さ(例えば、4のしばらくの深さへの2^4 = 16)に表すことができる範囲を超えてはいけません。 深さが許容するビットより少ないエントリーを持っているのは許されています。 その場合と、範囲の少しも外では、イメージデータで見つけられたピクセル値は誤りです。
For color types 2 and 6 (truecolor and truecolor with alpha),
the PLTE chunk is optional. If present, it provides a
suggested set of from 1 to 256 colors to which the truecolor
image can be quantized if the viewer cannot display truecolor
directly. If PLTE is not present, such a viewer will need to
select colors on its own, but it is often preferable for this
カラータイプ2と6(アルファがあるtruecolorとtruecolor)において、PLTE塊は任意です。 存在しているなら、それはビューアーが直接truecolorを表示できないならtruecolorイメージを量子化することができる1〜256の色の提案されたセットを提供します。 PLTEが存在していない、そのようなビューアーが、それ自身のところで色を選択する必要がありますが、これに、それがしばしば望ましいなら
Boutell, et. al. Informational [Page 17] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[17ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
to be done once by the encoder. (See Recommendations for
Encoders: Suggested palettes, Section 9.5.)
一度エンコーダでするために。 (Encodersに関してRecommendationsを見てください: 提案されたパレット、セクション9.5)
Note that the palette uses 8 bits (1 byte) per sample
regardless of the image bit depth specification. In
particular, the palette is 8 bits deep even when it is a
suggested quantization of a 16-bit truecolor image.
パレットがイメージの噛み付いている深さ仕様にかかわらず1サンプルあたり8ビット(1バイト)を使用することに注意してください。 それが16ビットのtruecolorイメージの提案された量子化でさえあるときに、特に、パレットは深さ8ビットです。
There is no requirement that the palette entries all be used by
the image, nor that they all be different.
パレットエントリーがイメージによってすべて使用されて、それらが皆、異なっているという要件が全くありません。
4.1.3. IDAT Image data
4.1.3. IDAT Imageデータ
The IDAT chunk contains the actual image data. To create this
data:
IDAT塊は実画像データを含んでいます。 このデータを作成するために:
* Begin with image scanlines represented as described in
Image layout (Section 2.3); the layout and total size of
this raw data are determined by the fields of IHDR.
* Filter the image data according to the filtering method
specified by the IHDR chunk. (Note that with filter
method 0, the only one currently defined, this implies
prepending a filter type byte to each scanline.)
* Compress the filtered data using the compression method
specified by the IHDR chunk.
* イメージ走査線が表されている状態で、Imageレイアウト(セクション2.3)で説明されるように始まってください。 この生データのレイアウトと総サイズはIHDRの分野のそばで決定しています。*IHDR塊によって指定されたフィルタリング方法に従って、イメージデータをフィルターにかけてください。 (ドリップ式0、現在定義されている唯一無二でそれに注意してください、とこれはフィルタタイプバイトを各走査線にprependingしながら、含意します。) * IHDR塊によって指定された圧縮方法を使用して、フィルターにかけることのデータを圧縮してください。
The IDAT chunk contains the output datastream of the
compression algorithm.
IDAT塊は圧縮アルゴリズムの出力datastreamを含んでいます。
To read the image data, reverse this process.
イメージデータを読むには、この過程を逆にしてください。
There can be multiple IDAT chunks; if so, they must appear
consecutively with no other intervening chunks. The compressed
datastream is then the concatenation of the contents of all the
IDAT chunks. The encoder can divide the compressed datastream
into IDAT chunks however it wishes. (Multiple IDAT chunks are
allowed so that encoders can work in a fixed amount of memory;
typically the chunk size will correspond to the encoder's
buffer size.) It is important to emphasize that IDAT chunk
boundaries have no semantic significance and can occur at any
point in the compressed datastream. A PNG file in which each
IDAT chunk contains only one data byte is legal, though
remarkably wasteful of space. (For that matter, zero-length
IDAT chunks are legal, though even more wasteful.)
複数のIDAT塊があることができます。 そうだとすれば、彼らは他の介入している塊なしで連続して現れなければなりません。 そして、圧縮されたdatastreamはすべてのIDAT塊のコンテンツの連結です。 どのように願っても、エンコーダは圧縮されたdatastreamをIDAT塊に分割できます。 (複数のIDAT塊がエンコーダが固定メモリー容量で動作できるように、許容されています; 通常、塊サイズはエンコーダのバッファサイズに対応するでしょう。) IDAT塊境界がどんな意味意味も持たないで、圧縮されたdatastreamの任意な点に起こることができると強調するのは重要です。 それぞれのIDAT塊が1データ・バイトだけを含むPNGファイルは、法的であって、もっとも、スペースで著しく無駄です。 (さらに言えば、ゼロ・レングスIDAT塊は、法的であって、もっとも、さらに無駄です。)
See Filter Algorithms (Chapter 6) and Deflate/Inflate
Compression (Chapter 5) for details.
Filter Algorithms(第6章)とDeflate/が詳細のために、Compression(第5章)をふくらませるのを見てください。
Boutell, et. al. Informational [Page 18] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[18ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
4.1.4. IEND Image trailer
4.1.4. IEND Imageトレーラ
The IEND chunk must appear LAST. It marks the end of the PNG
datastream. The chunk's data field is empty.
IEND塊はLASTに現れなければなりません。それはPNG datastreamの端を示します。 塊のデータ・フィールドは人影がありません。
4.2. Ancillary chunks
4.2. 付属の塊
All ancillary chunks are optional, in the sense that encoders need
not write them and decoders can ignore them. However, encoders
are encouraged to write the standard ancillary chunks when the
information is available, and decoders are encouraged to interpret
these chunks when appropriate and feasible.
すべての付属の塊がエンコーダがそれらを書く必要はなくて、デコーダがそれらを無視できるという意味で任意です。 しかしながら、情報が利用可能であるときに、エンコーダが標準の付属の塊を書くよう奨励されて、適切であって、可能であるときに、デコーダがこれらの塊を解釈するよう奨励されます。
The standard ancillary chunks are listed in alphabetical order.
This is not necessarily the order in which they would appear in a
file.
標準の付属の塊はアルファベット順に記載されています。 これは必ず彼らがファイルに現れるオーダーであるというわけではありません。
4.2.1. bKGD Background color
4.2.1. bKGD Background色
The bKGD chunk specifies a default background color to present
the image against. Note that viewers are not bound to honor
this chunk; a viewer can choose to use a different background.
bKGD塊はイメージを提示するデフォルト背景色を指定します。 ビューアーが必ずこの塊を光栄に思わないことに注意してください。 ビューアーは、異なったバックグラウンドを使用するのを選ぶことができます。
For color type 3 (indexed color), the bKGD chunk contains:
カラータイプ3(色に索引をつけます)のために、bKGD塊は以下を含んでいます。
Palette index: 1 byte
パレットインデックス: 1バイト
The value is the palette index of the color to be used as
background.
値はバックグラウンドとして使用されるべき色のパレットインデックスです。
For color types 0 and 4 (grayscale, with or without alpha),
bKGD contains:
カラータイプ0と4(アルファのあるなしにかかわらずグレースケール)のために、bKGDは以下を含んでいます。
Gray: 2 bytes, range 0 .. (2^bitdepth)-1
グレー: 2バイト、範囲0。 (2^bitdepth)-1
(For consistency, 2 bytes are used regardless of the image bit
depth.) The value is the gray level to be used as background.
(一貫性のために、2バイトはイメージの噛み付いている深さにかかわらず使用されます。) 値はバックグラウンドとして使用されるべきグレーレベルです。
For color types 2 and 6 (truecolor, with or without alpha),
bKGD contains:
カラータイプ2と6(アルファのあるなしにかかわらずtruecolor)のために、bKGDは以下を含んでいます。
Red: 2 bytes, range 0 .. (2^bitdepth)-1
Green: 2 bytes, range 0 .. (2^bitdepth)-1
Blue: 2 bytes, range 0 .. (2^bitdepth)-1
赤: 2バイト、範囲0。 (2^bitdepth)-1つの緑色: 2バイト、範囲0。 (2^bitdepth)-1つの青: 2バイト、範囲0。 (2^bitdepth)-1
(For consistency, 2 bytes per sample are used regardless of the
image bit depth.) This is the RGB color to be used as
background.
(一貫性のために、1サンプルあたり2バイトはイメージの噛み付いている深さにかかわらず使用されます。) これはバックグラウンドとして使用されるべきRGB色です。
Boutell, et. al. Informational [Page 19] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[19ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
When present, the bKGD chunk must precede the first IDAT chunk,
and must follow the PLTE chunk, if any.
存在しているとき、bKGD塊は、最初のIDAT塊に先行しなければならなくて、もしあればPLTE塊に続かなければなりません。
See Recommendations for Decoders: Background color (Section
10.7).
デコーダのための推薦を見てください: 背景色(セクション10.7)。
4.2.2. cHRM Primary chromaticities and white point
4.2.2. cHRM Primary色度と白いポイント
Applications that need device-independent specification of
colors in a PNG file can use the cHRM chunk to specify the 1931
CIE x,y chromaticities of the red, green, and blue primaries
used in the image, and the referenced white point. See Color
Tutorial (Chapter 14) for more information.
PNGファイルの色の装置から独立している仕様を必要とするアプリケーションは、1931CIE x(イメージ、および参照をつけられた白いポイントで中古の赤くて、緑色の、そして、青い予備選挙のy色度)を指定するのにcHRM塊を使用できます。 詳しい情報に関してColor Tutorial(第14章)を見てください。
The cHRM chunk contains:
cHRM塊は以下を含んでいます。
White Point x: 4 bytes
White Point y: 4 bytes
Red x: 4 bytes
Red y: 4 bytes
Green x: 4 bytes
Green y: 4 bytes
Blue x: 4 bytes
Blue y: 4 bytes
白いPoint x: 4バイトのホワイトPoint y: 4バイトのRed x: 4バイトのRed y: 4バイトのグリーンx: 4バイトのグリーンy: 4バイトのBlue x: 4バイトのBlue y: 4バイト
Each value is encoded as a 4-byte unsigned integer,
representing the x or y value times 100000. For example, a
value of 0.3127 would be stored as the integer 31270.
4バイトの符号のない整数、xを表すか、またはyが回100000を評価するとき、各値はコード化されます。 例えば、0.3127の値は整数31270として格納されるでしょう。
cHRM is allowed in all PNG files, although it is of little
value for grayscale images.
それにはグレースケールイメージのための価値がほとんどありませんが、cHRMはすべてのPNGファイルに許容されています。
If the encoder does not know the chromaticity values, it should
not write a cHRM chunk; the absence of a cHRM chunk indicates
that the image's primary colors are device-dependent.
エンコーダが色度値を知らないなら、cHRM塊を書くべきではありません。 cHRM塊の欠如は、イメージの原色に装置依存しているのを示します。
If the cHRM chunk appears, it must precede the first IDAT
chunk, and it must also precede the PLTE chunk if present.
cHRM塊が現れるなら、最初のIDAT塊に先行しなければなりません、そして、また、存在しているなら、PLTE塊に先行しなければなりません。
See Recommendations for Encoders: Encoder color handling
(Section 9.3), and Recommendations for Decoders: Decoder color
handling (Section 10.6).
エンコーダのための推薦を見てください: エンコーダカラーの取り扱い(セクション9.3)、およびDecodersのためのRecommendations: デコーダ色の取り扱い(セクション10.6)。
Boutell, et. al. Informational [Page 20] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[20ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
4.2.3. gAMA Image gamma
4.2.3. gAMA Imageガンマ
The gAMA chunk specifies the gamma of the camera (or simulated
camera) that produced the image, and thus the gamma of the
image with respect to the original scene. More precisely, the
gAMA chunk encodes the file_gamma value, as defined in Gamma
Tutorial (Chapter 13).
gAMA塊は、元の場面に関してイメージを作り出したカメラ(または、カメラをシミュレートする)のガンマを指定して、その結果、イメージのガンマを指定します。 より正確に、gAMA塊はGamma Tutorial(第13章)で定義されるようにファイル_ガンマ値をコード化します。
The gAMA chunk contains:
gAMA塊は以下を含んでいます。
Image gamma: 4 bytes
イメージガンマ: 4バイト
The value is encoded as a 4-byte unsigned integer, representing
gamma times 100000. For example, a gamma of 0.45 would be
stored as the integer 45000.
ガンマ回100000を表して、値は4バイトの符号のない整数としてコード化されます。 例えば、0.45のガンマは整数45000として格納されるでしょう。
If the encoder does not know the image's gamma value, it should
not write a gAMA chunk; the absence of a gAMA chunk indicates
that the gamma is unknown.
エンコーダがイメージのガンマ値を知らないなら、gAMA塊を書くべきではありません。 gAMA塊の欠如は、ガンマが未知であることを示します。
If the gAMA chunk appears, it must precede the first IDAT
chunk, and it must also precede the PLTE chunk if present.
gAMA塊が現れるなら、最初のIDAT塊に先行しなければなりません、そして、また、存在しているなら、PLTE塊に先行しなければなりません。
See Gamma correction (Section 2.7), Recommendations for
Encoders: Encoder gamma handling (Section 9.2), and
Recommendations for Decoders: Decoder gamma handling (Section
10.5).
Encodersに関してGamma修正(セクション2.7)、Recommendationsを見てください: エンコーダガンマ取り扱い(セクション9.2)、およびDecodersのためのRecommendations: デコーダガンマ取り扱い(セクション10.5)。
4.2.4. hIST Image histogram
4.2.4. hIST Imageヒストグラム
The hIST chunk gives the approximate usage frequency of each
color in the color palette. A histogram chunk can appear only
when a palette chunk appears. If a viewer is unable to provide
all the colors listed in the palette, the histogram may help it
decide how to choose a subset of the colors for display.
hIST塊はカラーパレットのそれぞれの色の大体の用法頻度を与えます。 パレット塊が現れるときだけ、ヒストグラム塊は現れることができます。 ビューアーがパレットに記載されたすべての色を提供できないなら、ヒストグラムは、それが表示のために色の部分集合を選ぶ方法を決めるのを助けるかもしれません。
The hIST chunk contains a series of 2-byte (16 bit) unsigned
integers. There must be exactly one entry for each entry in
the PLTE chunk. Each entry is proportional to the fraction of
pixels in the image that have that palette index; the exact
scale factor is chosen by the encoder.
hIST塊は一連の2バイト(16ビット)の符号のない整数を含んでいます。 PLTE塊には各エントリーあたり1つのエントリーがまさにあるに違いありません。 それぞれのエントリーはそのパレットインデックスを持っているイメージによる画素の何分の一に比例しています。 正確な位取り因数はエンコーダによって選ばれています。
Histogram entries are approximate, with the exception that a
zero entry specifies that the corresponding palette entry is
not used at all in the image. It is required that a histogram
entry be nonzero if there are any pixels of that color.
ヒストグラムエントリーが大体である、例外で、そのaゼロエントリーは対応するパレットエントリーがイメージで全く使用されないと指定します。 何かその色の画素があればヒストグラムエントリーが非零であることが必要です。
Boutell, et. al. Informational [Page 21] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[21ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
When the palette is a suggested quantization of a truecolor
image, the histogram is necessarily approximate, since a
decoder may map pixels to palette entries differently than the
encoder did. In this situation, zero entries should not
appear.
パレットがtruecolorイメージの提案された量子化であるときに、ヒストグラムが必ず大体である、デコーダがそうするかもしれないので、エンコーダと異なったパレットエントリーへの地図画素はそうしました。 この状況で、エントリーは全く現れないべきではありません。
The hIST chunk, if it appears, must follow the PLTE chunk, and
must precede the first IDAT chunk.
hIST塊は、現れるならPLTE塊に続かなければならなくて、最初のIDAT塊に先行しなければなりません。
See Rationale: Palette histograms (Section 12.14), and
Recommendations for Decoders: Suggested-palette and histogram
usage (Section 10.10).
原理を見てください: パレットヒストグラム(セクション12.14)、およびDecodersのためのRecommendations: 提案されたパレットとヒストグラム用法(セクション10.10)。
4.2.5. pHYs Physical pixel dimensions
4.2.5. pHYs Physical画素の重要性
The pHYs chunk specifies the intended pixel size or aspect
ratio for display of the image. It contains:
pHYs塊は意図している画素サイズかアスペクトレシオをイメージの表示に指定します。 それは以下を含んでいます。
Pixels per unit, X axis: 4 bytes (unsigned integer)
Pixels per unit, Y axis: 4 bytes (unsigned integer)
Unit specifier: 1 byte
1ユニットあたりの画素、X軸: 1ユニットあたりの4バイトの(符号のない整数)画素、Y軸: 4バイトの(符号のない整数)ユニット特許説明書の作成書: 1バイト
The following values are legal for the unit specifier:
ユニット特許説明書の作成書に、以下の値は法的です:
0: unit is unknown
1: unit is the meter
0: ユニットは未知の1です: ユニットはメーターです。
When the unit specifier is 0, the pHYs chunk defines pixel
aspect ratio only; the actual size of the pixels remains
unspecified.
ユニット特許説明書の作成書が0歳であるときに、pHYs塊はピクセルアスペクトだけを定義します。 画素の実サイズは不特定のままで残っています。
Conversion note: one inch is equal to exactly 0.0254 meters.
変換注意: 1インチはちょうど0.0254メーターと等しいです。
If this ancillary chunk is not present, pixels are assumed to
be square, and the physical size of each pixel is unknown.
この付属の塊が存在していないなら、画素が正方形であると思われて、それぞれの画素の体格は未知です。
If present, this chunk must precede the first IDAT chunk.
存在しているなら、この塊は最初のIDAT塊に先行しなければなりません。
See Recommendations for Decoders: Pixel dimensions (Section
10.2).
デコーダのための推薦を見てください: 画素の重要性(セクション10.2)。
4.2.6. sBIT Significant bits
4.2.6. sBIT Significantビット
To simplify decoders, PNG specifies that only certain sample
depths can be used, and further specifies that sample values
should be scaled to the full range of possible values at the
sample depth. However, the sBIT chunk is provided in order to
store the original number of significant bits. This allows
PNGは、デコーダを簡素化するために、深層がそうすることができるあるサンプルだけが使用されると指定して、標本値がサンプルの深さにおける、最大限の範囲の可能な値に合わせて調整されるべきであるとさらに指定します。 しかしながら、重要なビットの元の数を格納するためにsBIT塊を提供します。 これは許容します。
Boutell, et. al. Informational [Page 22] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[22ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
decoders to recover the original data losslessly even if the
data had a sample depth not directly supported by PNG. We
recommend that an encoder emit an sBIT chunk if it has
converted the data from a lower sample depth.
データにPNGによって直接支持されなかったサンプルの深さがあったとしても、オリジナルのデータを回復するデコーダはlosslesslyされます。 私たちは、下側のサンプルの深さからのデータを変換したならエンコーダがsBIT塊を放つことを勧めます。
For color type 0 (grayscale), the sBIT chunk contains a single
byte, indicating the number of bits that were significant in
the source data.
カラータイプ0(グレースケール)のために、sBIT塊は1バイトを含んでいます、ソースデータで重要であったビットの数を示して。
For color type 2 (truecolor), the sBIT chunk contains three
bytes, indicating the number of bits that were significant in
the source data for the red, green, and blue channels,
respectively.
カラータイプ2(truecolor)のために、sBIT塊は3バイトを含んでいます、赤くて、緑色の、そして、青いチャンネルには、ソースデータでそれぞれ重要であったビットの数を示して。
For color type 3 (indexed color), the sBIT chunk contains three
bytes, indicating the number of bits that were significant in
the source data for the red, green, and blue components of the
palette entries, respectively.
カラータイプ3(色に索引をつけます)のために、sBIT塊は3バイトを含んでいます、パレットエントリーの赤くて、緑色の、そして、青い成分のためのソースデータでそれぞれ重要であったビットの数を示して。
For color type 4 (grayscale with alpha channel), the sBIT chunk
contains two bytes, indicating the number of bits that were
significant in the source grayscale data and the source alpha
data, respectively.
カラータイプ4(アルファチャンネルがあるグレースケール)のために、sBIT塊は2バイトを含んでいます、ソースグレースケールデータとソースアルファ・データでそれぞれ重要であったビットの数を示して。
For color type 6 (truecolor with alpha channel), the sBIT chunk
contains four bytes, indicating the number of bits that were
significant in the source data for the red, green, blue and
alpha channels, respectively.
カラータイプ6(アルファチャンネルがあるtruecolor)のために、sBIT塊は4バイトを含んでいます、赤くて、緑色の青とアルファチャンネルには、ソースデータでそれぞれ重要であったビットの数を示して。
Each depth specified in sBIT must be greater than zero and less
than or equal to the sample depth (which is 8 for indexed-color
images, and the bit depth given in IHDR for other color types).
sBITで指定されたそれぞれの深さはゼロとサンプルの、より深さ(索引をつけられたカラーイメージ、および他のカラータイプのためにIHDRで与えられた噛み付いている深さへの8である)より大きいに違いありません。
A decoder need not pay attention to sBIT: the stored image is a
valid PNG file of the sample depth indicated by IHDR. However,
if the decoder wishes to recover the original data at its
original precision, this can be done by right-shifting the
stored samples (the stored palette entries, for an indexed-
color image). The encoder must scale the data in such a way
that the high-order bits match the original data.
デコーダはsBITに注意を向ける必要はありません: 格納されたイメージはIHDRによって示されたサンプルの深さの有効なPNGファイルです。しかしながら、デコーダが元の精度でオリジナルのデータを回復したいなら、格納されたサンプル(索引をつけられたカラーイメージのための格納されたパレットエントリー)を権利で移動させることによって、これができます。 エンコーダは高位のビットがオリジナルのデータに合っているような方法でデータをスケーリングしなければなりません。
If the sBIT chunk appears, it must precede the first IDAT
chunk, and it must also precede the PLTE chunk if present.
sBIT塊が現れるなら、最初のIDAT塊に先行しなければなりません、そして、また、存在しているなら、PLTE塊に先行しなければなりません。
See Recommendations for Encoders: Sample depth scaling (Section
9.1) and Recommendations for Decoders: Sample depth rescaling
(Section 10.4).
エンコーダのための推薦を見てください: Decodersのために(セクション9.1)とRecommendationsをスケーリングする深さを抽出してください: 深さ再スケーリング(セクション10.4)を抽出してください。
Boutell, et. al. Informational [Page 23] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[23ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
4.2.7. tEXt Textual data
4.2.7. tEXt Textualデータ
Textual information that the encoder wishes to record with the
image can be stored in tEXt chunks. Each tEXt chunk contains a
keyword and a text string, in the format:
tEXt塊にエンコーダがイメージで記録したがっているという文字情報を格納できます。 それぞれのtEXt塊は形式にキーワードとテキスト文字列を含んでいます:
Keyword: 1-79 bytes (character string)
Null separator: 1 byte
Text: n bytes (character string)
キーワード: 1-79バイトの(文字列)ヌル分離符: 1バイトのテキスト: nバイト(文字列)
The keyword and text string are separated by a zero byte (null
character). Neither the keyword nor the text string can
contain a null character. Note that the text string is not
null-terminated (the length of the chunk is sufficient
information to locate the ending). The keyword must be at
least one character and less than 80 characters long. The text
string can be of any length from zero bytes up to the maximum
permissible chunk size less the length of the keyword and
separator.
キーワードとテキスト文字列はaゼロバイト(ヌル文字)によって分離されます。 キーワードもテキスト文字列もヌル文字を含むことができません。 テキスト文字列がヌルによって終えられないことに注意してください(塊の長さは結末の場所を見つけることができるくらいの情報です)。 長い間、キーワードは、少なくとも1つのキャラクタと80未満のキャラクタであるに違いありません。 テキスト文字列はバイトがないのから最大の許されている塊サイズまでのどんな長さの、よりもの以下であることができます。キーワードと分離符の長さ。
Any number of tEXt chunks can appear, and more than one with
the same keyword is permissible.
いろいろなtEXt塊が現れることができます、そして、同じキーワードがある1つ以上は許されています。
The keyword indicates the type of information represented by
the text string. The following keywords are predefined and
should be used where appropriate:
キーワードはテキスト文字列によって代理をされた情報の種類を示します。 以下のキーワードは、事前に定義されて、適切であるところで使用されるべきです:
Title Short (one line) title or caption for image
Author Name of image's creator
Description Description of image (possibly long)
Copyright Copyright notice
Creation Time Time of original image creation
Software Software used to create the image
Disclaimer Legal disclaimer
Warning Warning of nature of content
Source Device used to create the image
Comment Miscellaneous comment; conversion from
GIF comment
イメージのオリジナルのイメージ創造Software Softwareのイメージ(ことによると長い)Copyright Copyright通知Creation Time Timeの創造者記述記述のイメージAuthor NameのためのタイトルShort(1つの線)タイトルか見出しが以前はよくイメージComment Miscellaneousコメントを作成するのに使用される内容Source Deviceの自然のイメージDisclaimer Legal注意書きWarning Warningを作成していました。 GIFコメントからの変換
For the Creation Time keyword, the date format defined in
section 5.2.14 of RFC 1123 is suggested, but not required
[RFC-1123]. Decoders should allow for free-format text
associated with this or any other keyword.
Creation Timeキーワードに関しては、.14セクション5.2RFC1123で定義された日付の書式は、示されますが、必要ではありません[RFC-1123]。 デコーダはこれかいかなる他のキーワードにも関連しているフリー・フォーマットテキストを考慮するはずです。
Other keywords may be invented for other purposes. Keywords of
general interest can be registered with the maintainers of the
PNG specification. However, it is also permitted to use
private unregistered keywords. (Private keywords should be
他のキーワードは他の目的のために発明されるかもしれません。 PNG仕様の維持装置に一般的に関心のキーワードを登録できます。 しかしながら、また、個人的な登録されていないキーワードを使用することが許可されています。 (個人的なキーワードはそうであるべきです。
Boutell, et. al. Informational [Page 24] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[24ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
reasonably self-explanatory, in order to minimize the chance
that the same keyword will be used for incompatible purposes by
different people.)
合理的に自明です、機会を最小にして、そんなに同じキーワードは両立しない目的に異なった人々によって使用されるでしょう。)
Both keyword and text are interpreted according to the ISO
8859-1 (Latin-1) character set [ISO-8859]. The text string can
contain any Latin-1 character. Newlines in the text string
should be represented by a single linefeed character (decimal
10); use of other control characters in the text is
discouraged.
ISO8859-1(ラテン-1)文字の組[ISO-8859]によると、キーワードとテキストの両方が解釈されます。 テキスト文字列はどんなラテン語-1キャラクタも含むことができます。 テキスト文字列のニューラインは単独のラインフィードキャラクタ(10進10)によって表されるべきです。 テキストにおける他の制御文字の使用はお勧めできないです。
Keywords must contain only printable Latin-1 characters and
spaces; that is, only character codes 32-126 and 161-255
decimal are allowed. To reduce the chances for human
misreading of a keyword, leading and trailing spaces are
forbidden, as are consecutive spaces. Note also that the non-
breaking space (code 160) is not permitted in keywords, since
it is visually indistinguishable from an ordinary space.
キーワードは印刷可能なラテン語-1キャラクタと空間だけを含まなければなりません。 161-255 すなわち、キャラクタだけが32-126をコード化します、そして、小数は許容されています。 キーワードの人間の誤読のために可能性を小さくするために、主で引きずっている空間は連続した空間のように禁じられます。 また、非壊れているスペース(コード160)がキーワードで受入れられないことに注意してください、それが目視により普通のスペースから区別がつかないので。
Keywords must be spelled exactly as registered, so that
decoders can use simple literal comparisons when looking for
particular keywords. In particular, keywords are considered
case-sensitive.
特定のキーワードを探すとき、デコーダが簡単な文字通りの比較を使用できるように、ちょうど登録されるとしてキーワードをつづらなければなりません。 特に、キーワードは大文字と小文字を区別していると考えられます。
See Recommendations for Encoders: Text chunk processing
(Section 9.7) and Recommendations for Decoders: Text chunk
processing (Section 10.11).
エンコーダのための推薦を見てください: Decodersのためのテキスト塊処理(セクション9.7)とRecommendations: テキスト塊処理(セクション10.11)。
4.2.8. tIME Image last-modification time
4.2.8.tIME Image最後の変更時間
The tIME chunk gives the time of the last image modification
(not the time of initial image creation). It contains:
tIME塊は最後のイメージ変更(初期のイメージ創造の時間でない)の時間を与えます。 それは以下を含んでいます。
Year: 2 bytes (complete; for example, 1995, not 95)
Month: 1 byte (1-12)
Day: 1 byte (1-31)
Hour: 1 byte (0-23)
Minute: 1 byte (0-59)
Second: 1 byte (0-60) (yes, 60, for leap seconds; not 61,
a common error)
年: 2バイト、(完全である、; 例えば、95)カ月ではなく、1995: 1バイト(1-12)日: 1バイト(1-31)時間: 1バイト(0-23)分: 1バイト(0-59)秒: 1バイト(0-60)(はい、飛躍秒の間の60; 61でない、一般的な誤り)
Universal Time (UTC, also called GMT) should be specified
rather than local time.
現地時間であるというよりむしろ世界標準時(また、グリニッジ標準時に呼ばれたUTC)は指定されているべきです。
Boutell, et. al. Informational [Page 25] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[25ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
The tIME chunk is intended for use as an automatically-applied
time stamp that is updated whenever the image data is changed.
It is recommended that tIME not be changed by PNG editors that
do not change the image data. See also the Creation Time tEXt
keyword, which can be used for a user-supplied time.
tIME塊は使用のためにイメージデータを変えるときはいつも、アップデートされる自動的に適用されたタイムスタンプとして意図します。 tIMEがイメージデータを変えないPNGエディタによって変えられないのは、お勧めです。 また、Creation Time tEXtキーワードを見てください。(ユーザによって供給された時間、それを使用できます)。
4.2.9. tRNS Transparency
4.2.9. tRNS透明
The tRNS chunk specifies that the image uses simple
transparency: either alpha values associated with palette
entries (for indexed-color images) or a single transparent
color (for grayscale and truecolor images). Although simple
transparency is not as elegant as the full alpha channel, it
requires less storage space and is sufficient for many common
cases.
tRNS塊は、イメージが簡単な透明を使用すると指定します: 関連しているわかりやすいパレットエントリー(索引をつけられたカラーイメージのための)かシングルで文字値は着色します(グレースケールとtruecolorイメージのために)。 簡単な透明は完全なアルファチャンネルほど上品ではありませんが、それは、より少ない集積スペースを必要として、多くのよくある例に十分です。
For color type 3 (indexed color), the tRNS chunk contains a
series of one-byte alpha values, corresponding to entries in
the PLTE chunk:
カラータイプ3(色に索引をつけます)のために、tRNS塊は一連の1バイトの文字値を含んでいます、PLTE塊におけるエントリーに対応しています:
Alpha for palette index 0: 1 byte
Alpha for palette index 1: 1 byte
... etc ...
パレットインデックス0のためのアルファー: パレットインデックス1のための1バイトのアルファー: 1バイトの…など…
Each entry indicates that pixels of the corresponding palette
index must be treated as having the specified alpha value.
Alpha values have the same interpretation as in an 8-bit full
alpha channel: 0 is fully transparent, 255 is fully opaque,
regardless of image bit depth. The tRNS chunk must not contain
more alpha values than there are palette entries, but tRNS can
contain fewer values than there are palette entries. In this
case, the alpha value for all remaining palette entries is
assumed to be 255. In the common case in which only palette
index 0 need be made transparent, only a one-byte tRNS chunk is
needed.
各エントリーは、対応するパレットインデックスの画素を指定された文字値を持っているとして扱わなければならないのを示します。 文字値には、同じ解釈が8ビットの完全なアルファチャンネルであります: 0が完全に透明である、255はイメージの噛み付いている深さにかかわらず完全に不透明です。 tRNS塊はパレットエントリーがあるより多くの文字値を含んではいけませんが、tRNSはパレットエントリーがあるより少ない値を含むことができます。 この場合、すべての残っているパレットエントリーへの文字値は255であると思われます。 パレットインデックス0だけが透明にされなければならないよくある例では、1バイトのtRNS塊だけが必要です。
For color type 0 (grayscale), the tRNS chunk contains a single
gray level value, stored in the format:
カラータイプ0(グレースケール)のために、tRNS塊は形式で格納されたただ一つのグレーレベル値を含んでいます:
Gray: 2 bytes, range 0 .. (2^bitdepth)-1
グレー: 2バイト、範囲0。 (2^bitdepth)-1
(For consistency, 2 bytes are used regardless of the image bit
depth.) Pixels of the specified gray level are to be treated as
transparent (equivalent to alpha value 0); all other pixels are
to be treated as fully opaque (alpha value (2^bitdepth)-1).
(一貫性のために、2バイトはイメージの噛み付いている深さにかかわらず使用されます。) 指定されたグレーレベルの画素は透明(文字値0に同等な)として扱われることです。 他の画素が扱われることになっているすべてが(文字値(2^bitdepth)-1)について完全に不透明にします。
Boutell, et. al. Informational [Page 26] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[26ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
For color type 2 (truecolor), the tRNS chunk contains a single
RGB color value, stored in the format:
カラータイプ2(truecolor)のために、tRNS塊は形式で格納されたただ一つのRGB色の価値を含んでいます:
Red: 2 bytes, range 0 .. (2^bitdepth)-1
Green: 2 bytes, range 0 .. (2^bitdepth)-1
Blue: 2 bytes, range 0 .. (2^bitdepth)-1
赤: 2バイト、範囲0。 (2^bitdepth)-1つの緑色: 2バイト、範囲0。 (2^bitdepth)-1つの青: 2バイト、範囲0。 (2^bitdepth)-1
(For consistency, 2 bytes per sample are used regardless of the
image bit depth.) Pixels of the specified color value are to be
treated as transparent (equivalent to alpha value 0); all other
pixels are to be treated as fully opaque (alpha value
(2^bitdepth)-1).
(一貫性のために、1サンプルあたり2バイトはイメージの噛み付いている深さにかかわらず使用されます。) 指定された色の価値の画素は透明(文字値0に同等な)として扱われることです。 他の画素が扱われることになっているすべてが(文字値(2^bitdepth)-1)について完全に不透明にします。
tRNS is prohibited for color types 4 and 6, since a full alpha
channel is already present in those cases.
完全なアルファチャンネルがそれらの場合で既に出席しているので、tRNSはカラータイプ4と6のために禁止されています。
Note: when dealing with 16-bit grayscale or truecolor data, it
is important to compare both bytes of the sample values to
determine whether a pixel is transparent. Although decoders
may drop the low-order byte of the samples for display, this
must not occur until after the data has been tested for
transparency. For example, if the grayscale level 0x0001 is
specified to be transparent, it would be incorrect to compare
only the high-order byte and decide that 0x0002 is also
transparent.
以下に注意してください。 16ビットのグレースケールかtruecolorデータに対処するとき、画素が見え透いているかどうか決定するために標本値の両方のバイトを比較するのは重要です。 デコーダは表示のためのサンプルの下位バイトを落とすかもしれませんが、データが透明がないかどうかテストされた後までこれは起こってはいけません。 例えば、グレースケールレベル0x0001が透明になるように指定されるなら、高位バイトだけを比較して、また、0×0002も透明であると決めるのは不正確でしょう。
When present, the tRNS chunk must precede the first IDAT chunk,
and must follow the PLTE chunk, if any.
存在しているとき、tRNS塊は、最初のIDAT塊に先行しなければならなくて、もしあればPLTE塊に続かなければなりません。
4.2.10. zTXt Compressed textual data
4.2.10. zTXt Compressedの原文のデータ
The zTXt chunk contains textual data, just as tEXt does;
however, zTXt takes advantage of compression. zTXt and tEXt
chunks are semantically equivalent, but zTXt is recommended for
storing large blocks of text.
zTXt塊はちょうどtEXtが含んでいるように原文のデータを含んでいます。 しかしながら、zTXtは圧縮を利用します。zTXtとtEXt塊は意味的に同等ですが、zTXtは、大量株のテキストを格納するために推薦されます。
A zTXt chunk contains:
zTXt塊は以下を含んでいます。
Keyword: 1-79 bytes (character string)
Null separator: 1 byte
Compression method: 1 byte
Compressed text: n bytes
キーワード: 1-79バイトの(文字列)ヌル分離符: 1バイトのCompression方法: 1バイトのCompressedテキスト: nバイト
The keyword and null separator are exactly the same as in the
tEXt chunk. Note that the keyword is not compressed. The
compression method byte identifies the compression method used
in this zTXt chunk. The only value presently defined for it is
0 (deflate/inflate compression). The compression method byte is
キーワードとヌル分離符はまさにtEXt塊と同じです。 キーワードが圧縮されないことに注意してください。 圧縮方法バイトはこのzTXt塊に使用される圧縮方法を特定します。 現在それのために定義されている唯一の値が0(圧縮を空気を抜くか、またはふくらませる)です。 圧縮方法バイトはそうです。
Boutell, et. al. Informational [Page 27] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[27ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
followed by a compressed datastream that makes up the remainder
of the chunk. For compression method 0, this datastream
adheres to the zlib datastream format (see Deflate/Inflate
Compression, Chapter 5). Decompression of this datastream
yields Latin-1 text that is identical to the text that would be
stored in an equivalent tEXt chunk.
塊の残りを補う圧縮されたdatastreamによって続かれています。 圧縮方法0のために、このdatastreamはzlib datastream形式(Deflate/がCompression、第5章をふくらませるのを見る)を固く守ります。 このdatastreamの減圧は同等なtEXt塊に格納されるテキストと同じラテン語-1テキストをもたらします。
Any number of zTXt and tEXt chunks can appear in the same file.
See the preceding definition of the tEXt chunk for the
predefined keywords and the recommended format of the text.
いろいろなzTXtとtEXt塊は同じファイルに現れることができます。 事前に定義されたキーワードとテキストのお勧めの形式に関してtEXt塊の前の定義を見てください。
See Recommendations for Encoders: Text chunk processing
(Section 9.7), and Recommendations for Decoders: Text chunk
processing (Section 10.11).
エンコーダのための推薦を見てください: テキストの塊処理(セクション9.7)、およびDecodersのためのRecommendations: テキスト塊処理(セクション10.11)。
4.3. Summary of standard chunks
4.3. 標準の塊の概要
This table summarizes some properties of the standard chunk types.
このテーブルは標準の塊タイプのいくつかの特性をまとめます。
Critical chunks (must appear in this order, except PLTE
is optional):
批判的な塊(必須はこの順で現れます、そして、PLTEは任意です):
Name Multiple Ordering constraints
OK?
規制OKとMultiple Orderingを命名しますか?
IHDR No Must be first
PLTE No Before IDAT
IDAT Yes Multiple IDATs must be consecutive
IEND No Must be last
IHDRノーMust、はい、最初のPLTEノーBefore IDAT IDATがMultiple IDATsであったなら、連続したIENDがMustであったはずがないなら最後になってください。
Ancillary chunks (need not appear in this order):
付属の塊(この順で現れる必要はありません):
Name Multiple Ordering constraints
OK?
規制OKとMultiple Orderingを命名しますか?
cHRM No Before PLTE and IDAT
gAMA No Before PLTE and IDAT
sBIT No Before PLTE and IDAT
bKGD No After PLTE; before IDAT
hIST No After PLTE; before IDAT
tRNS No After PLTE; before IDAT
pHYs No Before IDAT
tIME No None
tEXt Yes None
zTXt Yes None
PLTEの前のcHRMノー、PLTEの前のIDAT gAMAノー、PLTEの前のIDAT sBITノー、およびPLTEの後のIDAT bKGDノー。 PLTEの後のIDAT hISTノーの前に。 PLTEの後のIDAT tRNSノーの前に。 以前IDAT pHYsノーの前にIDATが、いいえようになにもに調節する、テキストはい、なにも、zTXtはい、なし
Boutell, et. al. Informational [Page 28] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[28ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
Standard keywords for tEXt and zTXt chunks:
tEXtのための標準のキーワードとzTXt塊:
Title Short (one line) title or caption for image
Author Name of image's creator
Description Description of image (possibly long)
Copyright Copyright notice
Creation Time Time of original image creation
Software Software used to create the image
Disclaimer Legal disclaimer
Warning Warning of nature of content
Source Device used to create the image
Comment Miscellaneous comment; conversion from
GIF comment
イメージのオリジナルのイメージ創造Software Softwareのイメージ(ことによると長い)Copyright Copyright通知Creation Time Timeの創造者記述記述のイメージAuthor NameのためのタイトルShort(1つの線)タイトルか見出しが以前はよくイメージComment Miscellaneousコメントを作成するのに使用される内容Source Deviceの自然のイメージDisclaimer Legal注意書きWarning Warningを作成していました。 GIFコメントからの変換
4.4. Additional chunk types
4.4. 追加塊タイプ
Additional public PNG chunk types are defined in the document "PNG
Special-Purpose Public Chunks" [PNG-EXTENSIONS]. Chunks described
there are expected to be less widely supported than those defined
in this specification. However, application authors are
encouraged to use those chunk types whenever appropriate for their
applications. Additional chunk types can be proposed for
inclusion in that list by contacting the PNG specification
maintainers at png-info@uunet.uu.net or at png-group@w3.org.
「PNGの専用公共の塊」[PNG-EXTENSIONS]というドキュメントでは、定義されます追加公共のPNG塊が、タイプする。 この仕様に基づき定義されたものよりそこで説明された塊によって広く支持されていないと予想されます。 しかしながら、彼らのアプリケーションに適切であるときはいつも、アプリケーション作者がそれらの塊タイプを使用するよう奨励されます。 そのリストにおける包含のために png-info@uunet.uu.net において、または、pngグループ@w3.orgにおいてPNG仕様維持装置に連絡することによって、追加塊タイプを提案できます。
New public chunks will only be registered if they are of use to
others and do not violate the design philosophy of PNG. Chunk
registration is not automatic, although it is the intent of the
authors that it be straightforward when a new chunk of potentially
wide application is needed. Note that the creation of new
critical chunk types is discouraged unless absolutely necessary.
他のものの役に立って、PNGの設計理念に違反しない場合にだけ、新しい公共の塊は登録されるでしょう。 塊登録が自動でない、それは作者の意図ですが、潜在的に広いアプリケーションの新しい塊であるときに、それが簡単であることが必要です。 絶対に必要でない場合新しい重要な塊タイプの創造がお勧めできないことに注意してください。
Applications can also use private chunk types to carry data that
is not of interest to other applications. See Recommendations for
Encoders: Use of private chunks (Section 9.8).
また、アプリケーションは、他のアプリケーションに興味がないデータを運ぶのに個人的な塊タイプを使用できます。 エンコーダのための推薦を見てください: 個人的な塊(セクション9.8)の使用。
Decoders must be prepared to encounter unrecognized public or
private chunk type codes. Unrecognized chunk types must be
handled as described in Chunk naming conventions (Section 3.3).
認識されていない公共の、または、個人的な塊タイプコードに遭遇するようにデコーダを準備しなければなりません。 (セクション3.3)とコンベンションを命名するChunkで説明されるように認識されていない塊タイプを扱わなければなりません。
5. Deflate/Inflate Compression
5. 圧縮を空気を抜くか、またはふくらませてください。
PNG compression method 0 (the only compression method presently defined for PNG) specifies deflate/inflate compression with a 32K sliding window. Deflate compression is an LZ77 derivative used in zip, gzip, pkzip and related programs. Extensive research has been done supporting its patent-free status. Portable C implementations are freely available.
圧縮方法0(現在PNGのために定義されている唯一の圧縮方法)が指定するPNGは32Kの引窓で圧縮を空気を抜くか、またはふくらませます。 デフレート圧縮はファスナ、gzip、pkzip、および関連するプログラムで使用されるLZ77派生物です。大規模な研究は無特許の状態を支持し終わっていました。 携帯用のC実現は自由に利用可能です。
Boutell, et. al. Informational [Page 29] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[29ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
Deflate-compressed datastreams within PNG are stored in the "zlib" format, which has the structure:
空気を抜く、-、圧縮、PNGの中のdatastreamsは"zlib"形式で格納されます:(形式には、構造があります)。
Compression method/flags code: 1 byte
Additional flags/check bits: 1 byte
Compressed data blocks: n bytes
Check value: 4 bytes
圧縮方法/旗は以下をコード化します。 1バイトのAdditional旗/チェックビット: 1バイトのCompressedデータ・ブロック: nバイトのCheck値: 4バイト
Further details on this format are given in the zlib specification [RFC-1950].
zlib仕様[RFC-1950]でこの形式に関する詳細を与えます。
For PNG compression method 0, the zlib compression method/flags code
must specify method code 8 ("deflate" compression) and an LZ77 window
size of not more than 32K. Note that the zlib compression method
number is not the same as the PNG compression method number. The
additional flags must not specify a preset dictionary.
PNG圧縮方法0として、圧縮方法/旗がコード化するzlibは方法コード8(圧縮に「空気を抜かせる」)と32K以上でないLZ77ウィンドウサイズを指定しなければなりません。 zlib圧縮方法番号がPNG圧縮方法番号と同じでないことに注意してください。 あらかじめセットされて、追加旗はaを指定してはいけません。辞書。
The compressed data within the zlib datastream is stored as a series of blocks, each of which can represent raw (uncompressed) data, LZ77-compressed data encoded with fixed Huffman codes, or LZ77- compressed data encoded with custom Huffman codes. A marker bit in the final block identifies it as the last block, allowing the decoder to recognize the end of the compressed datastream. Further details on the compression algorithm and the encoding are given in the deflate specification [RFC-1951].
それのそれぞれが生(解凍される)のデータを表すことができる一連のブロック、LZ77によって圧縮されたデータが固定ハフマンと共にコードをコード化したか、またはLZ77がカスタムハフマン符号でコード化されたデータを圧縮したので、zlib datastreamの中の圧縮されたデータは格納されます。 最終的なブロックのマーカービットは、それが最後のブロックであると認識します、デコーダが圧縮されたdatastreamの端を認識するのを許容して。 圧縮アルゴリズムとコード化に関する詳細を与える、仕様[RFC-1951]に空気を抜かせてください。
The check value stored at the end of the zlib datastream is calculated on the uncompressed data represented by the datastream. Note that the algorithm used is not the same as the CRC calculation used for PNG chunk check values. The zlib check value is useful mainly as a cross-check that the deflate and inflate algorithms are implemented correctly. Verifying the chunk CRCs provides adequate confidence that the PNG file has been transmitted undamaged.
zlib datastreamの端に格納されたチェック値はdatastreamによって表された解凍されたデータで計算されます。 アルゴリズムが使用した注意は計算がPNG塊に使用したCRCが値をチェックするのと同じではありません。 アルゴリズムの空気を抜いて、ふくらませてください。主にaがそれにクロスチェックするようにzlibチェック価値が役に立つ、正しく実行されます。 塊CRCsについて確かめると、PNGファイルが無傷で送られたという適切な信用は供給されます。
In a PNG file, the concatenation of the contents of all the IDAT chunks makes up a zlib datastream as specified above. This datastream decompresses to filtered image data as described elsewhere in this document.
PNGファイルでは、すべてのIDAT塊のコンテンツの連結が上で指定されるとしてzlib datastreamを作ります。 このdatastreamはほかの場所で本書では説明されるようにフィルターにかけることのイメージデータに減圧されます。
It is important to emphasize that the boundaries between IDAT chunks are arbitrary and can fall anywhere in the zlib datastream. There is not necessarily any correlation between IDAT chunk boundaries and deflate block boundaries or any other feature of the zlib data. For example, it is entirely possible for the terminating zlib check value to be split across IDAT chunks.
IDAT塊の間の境界が任意であり、zlib datastreamでどこでも落下できると強調するのは重要です。 IDAT塊境界の間には、必ず少しの相関関係もありません、そして、zlibデータのブロック境界かいかなる他の特徴にも空気を抜かせてください。 例えば、終わっているzlibチェック価値がIDAT塊の向こう側に分けられるのは、完全に可能です。
Boutell, et. al. Informational [Page 30] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[30ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
In the same vein, there is no required correlation between the structure of the image data (i.e., scanline boundaries) and deflate block boundaries or IDAT chunk boundaries. The complete image data is represented by a single zlib datastream that is stored in some number of IDAT chunks; a decoder that assumes any more than this is incorrect. (Of course, some encoder implementations may emit files in which some of these structures are indeed related. But decoders cannot rely on this.)
同じ流れには、イメージデータ(すなわち、走査線境界)の構造の間には、どんな必要な相関関係もありません、そして、ブロック境界かIDAT塊境界に空気を抜かせてください。 完全なイメージデータは何らかの数のIDAT塊に格納される単一のzlib datastreamによって表されます。 これよりもっと多くのものを仮定するデコーダは不正確です。 (もちろん、いくつかのエンコーダ実現が本当に、これらのいくつかの構造が関係づけられるファイルを放つかもしれません。 しかし、デコーダはこれを当てにすることができません。)
PNG also uses zlib datastreams in zTXt chunks. In a zTXt chunk, the remainder of the chunk following the compression method byte is a zlib datastream as specified above. This datastream decompresses to the user-readable text described by the chunk's keyword. Unlike the image data, such datastreams are not split across chunks; each zTXt chunk contains an independent zlib datastream.
また、PNGはzTXt塊にzlib datastreamsを使用します。 zTXt塊では、圧縮方法バイトに続く塊の残りは上で指定されるとしてzlib datastreamです。 このdatastreamは塊のキーワードによって説明されたユーザ読み込み可能なテキストに減圧されます。 イメージデータと異なって、そのようなdatastreamsは塊の向こう側に分割されません。 それぞれのzTXt塊は独立しているzlib datastreamを含んでいます。
Additional documentation and portable C code for deflate and inflate are available from the Info-ZIP archives at <URL:ftp://ftp.uu.net/pub/archiving/zip/>.
追加のドキュメンテーションと携帯用のCがコード化する、空気を抜いてくださいといって、ふくらませてください、<URL: ftp://ftp.uu.net/pub/archiving/zip/ >のInfo-ZIPアーカイブから、利用可能です。
6. Filter Algorithms
6. フィルタアルゴリズム
This chapter describes the filter algorithms that can be applied before compression. The purpose of these filters is to prepare the image data for optimum compression.
本章は圧縮の前に適用できるフィルタアルゴリズムを説明します。 これらのフィルタの目的は最適な圧縮のためにイメージデータを準備することです。
6.1. Filter types
6.1. フィルタタイプ
PNG filter method 0 defines five basic filter types:
PNGドリップ式0は5つの基本的なフィルタタイプを定義します:
Type Name
型名
0 None
1 Sub
2 Up
3 Average
4 Paeth
0 なにもに、1隻の潜水艦2上3は4Paethを平均します。
(Note that filter method 0 in IHDR specifies exactly this set of
five filter types. If the set of filter types is ever extended, a
different filter method number will be assigned to the extended
set, so that decoders need not decompress the data to discover
that it contains unsupported filter types.)
(IHDRのドリップ式0がまさに5つのフィルタタイプのこのセットを指定することに注意してください。 フィルタタイプのセットが今までに広げられると、異なったドリップ式番号は拡張セットに配属されるでしょう、デコーダがそれがサポートされないフィルタタイプを含むと発見するためにデータを減圧する必要はないように。)
The encoder can choose which of these filter algorithms to apply
on a scanline-by-scanline basis. In the image data sent to the
compression step, each scanline is preceded by a filter type byte
that specifies the filter algorithm used for that scanline.
エンコーダは、走査線ごとのベースでこれらのフィルタアルゴリズムのどれを適用するかを選ぶことができます。 圧縮ステップに送られたイメージデータでは、各走査線はその走査線に使用されるフィルタアルゴリズムを指定するフィルタタイプバイト先行されています。
Boutell, et. al. Informational [Page 31] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[31ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
Filtering algorithms are applied to bytes, not to pixels,
regardless of the bit depth or color type of the image. The
filtering algorithms work on the byte sequence formed by a
scanline that has been represented as described in Image layout
(Section 2.3). If the image includes an alpha channel, the alpha
data is filtered in the same way as the image data.
フィルタリングアルゴリズムはイメージの噛み付いている深さかカラータイプにかかわらず画素ではなく、バイトに適用されます。 フィルタリングアルゴリズムはImageレイアウト(セクション2.3)で説明されるように表された走査線によって形成されたバイト列に取り組みます。 イメージがアルファチャンネルを含んでいるなら、イメージデータと同様に、アルファ・データはフィルターにかけられます。
When the image is interlaced, each pass of the interlace pattern
is treated as an independent image for filtering purposes. The
filters work on the byte sequences formed by the pixels actually
transmitted during a pass, and the "previous scanline" is the one
previously transmitted in the same pass, not the one adjacent in
the complete image. Note that the subimage transmitted in any one
pass is always rectangular, but is of smaller width and/or height
than the complete image. Filtering is not applied when this
subimage is empty.
イメージがインターレースするとき、インターレースパターンの各パスは目的をフィルターにかけるための独立しているイメージとして扱われます。 フィルタは実際にパスの間に伝えられた画素によって形成されたバイト列に動きます、そして、「前の走査線」は完全なイメージで隣接しているものではなく、以前に同じパスで伝えられたものです。 どんなパスでも伝えられた「副-イメージ」が完全なイメージよりいつも長方形ですが、よりわずかな幅、そして/または、高さのものであることに注意してください。 この「副-イメージ」が空であるときに、フィルタリングは適用されていません。
For all filters, the bytes "to the left of" the first pixel in a
scanline must be treated as being zero. For filters that refer to
the prior scanline, the entire prior scanline must be treated as
being zeroes for the first scanline of an image (or of a pass of
an interlaced image).
フィルタ、すべてのバイト、「」 走査線における最初の画素の左に、ゼロであるとして扱わなければなりません。 先の走査線について言及するフィルタに関しては、イメージ(または交錯しているイメージのパスについて)の最初の走査線のためにゼロであるとして全体の先の走査線を扱わなければなりません。
To reverse the effect of a filter, the decoder must use the
decoded values of the prior pixel on the same line, the pixel
immediately above the current pixel on the prior line, and the
pixel just to the left of the pixel above. This implies that at
least one scanline's worth of image data will have to be stored by
the decoder at all times. Even though some filter types do not
refer to the prior scanline, the decoder will always need to store
each scanline as it is decoded, since the next scanline might use
a filter that refers to it.
フィルタの効果を逆にするために、デコーダは同じ線の先の画素、先の線の現在の画素のすぐ上の画素、およびまさしく上の画素の左への画素の解読された値を使用しなければなりません。 これは、少なくとも1つの走査線のイメージデータの価値がいつもデコーダによって格納されなければならないのを含意します。 何人かのフィルタタイプは先の走査線について言及しませんが、デコーダは、いつもそれが解読されるとき各走査線を格納する必要があるでしょう、次の走査線がそれについて言及するフィルタを使用するかもしれないので。
PNG imposes no restriction on which filter types can be applied to
an image. However, the filters are not equally effective on all
types of data. See Recommendations for Encoders: Filter selection
(Section 9.6).
PNGはフィルタタイプをイメージに適用できる制限を全く課しません。 しかしながら、フィルタはすべてのタイプに関するデータで等しく有効ではありません。 エンコーダのための推薦を見てください: 選択(セクション9.6)をフィルターにかけてください。
See also Rationale: Filtering (Section 12.9).
また、Rationaleを見てください: (セクション12.9)をフィルターにかけます。
6.2. Filter type 0: None
6.2. タイプ0をフィルターにかけてください: なし
With the None filter, the scanline is transmitted unmodified; it
is only necessary to insert a filter type byte before the data.
Noneフィルタで、走査線は変更されていなく伝えられます。 それが、単にデータのフィルタタイプバイト前に挿入するのに必要です。
Boutell, et. al. Informational [Page 32] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[32ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
6.3. Filter type 1: Sub
6.3. タイプ1をフィルターにかけてください: 潜水艦
The Sub filter transmits the difference between each byte and the
value of the corresponding byte of the prior pixel.
Subフィルタは先の画素の対応するバイトの各バイトと値の違いを伝えます。
To compute the Sub filter, apply the following formula to each
byte of the scanline:
Subフィルタを計算するには、走査線の各バイトに以下の公式を適用してください:
Sub(x) = Raw(x) - Raw(x-bpp)
生の潜水艦(x)=(x)--生で(x-bpp)
where x ranges from zero to the number of bytes representing the
scanline minus one, Raw(x) refers to the raw data byte at that
byte position in the scanline, and bpp is defined as the number of
bytes per complete pixel, rounding up to one. For example, for
color type 2 with a bit depth of 16, bpp is equal to 6 (three
samples, two bytes per sample); for color type 0 with a bit depth
of 2, bpp is equal to 1 (rounding up); for color type 4 with a bit
depth of 16, bpp is equal to 4 (two-byte grayscale sample, plus
two-byte alpha sample).
xがゼロ〜1を引いて走査線を表すバイト数まで及ぶところと、Raw(x)は走査線でそのバイト位置における未加工データバイトを呼びます、そして、bppは完全な画素(1つへの一斉逮捕)あたりのバイト数と定義されます。 例えば、16のしばらくの深さがあるカラータイプ2において、bppは6(3個のサンプル、1サンプルあたり2バイト)と等しいです。 2のしばらくの深さがあるカラータイプ0において、bppは1(一斉逮捕)と等しいです。 16のしばらくの深さがあるカラータイプ4において、bppは4(2バイトのグレースケールのサンプル、および2バイトのアルファのサンプル)と等しいです。
Note this computation is done for each byte, regardless of bit
depth. In a 16-bit image, each MSB is predicted from the
preceding MSB and each LSB from the preceding LSB, because of the
way that bpp is defined.
噛み付いている深さにかかわらず各バイトのためにこの計算をすることに注意してください。 16ビットのイメージで、各MSBは前のMSBと各LSBから前のLSBから予測されます、bppが定義される方法のために。
Unsigned arithmetic modulo 256 is used, so that both the inputs
and outputs fit into bytes. The sequence of Sub values is
transmitted as the filtered scanline.
無記名の算数の法256が使用されているので、入力と出力の両方がバイトに収まります。 Sub値の系列はフィルターにかけることの走査線として伝えられます。
For all x < 0, assume Raw(x) = 0.
すべてのx<0に関しては、Raw(x)が=0であると仮定してください。
To reverse the effect of the Sub filter after decompression,
output the following value:
減圧の後にSubフィルタの効果を逆にするには、以下の値を出力してください:
Sub(x) + Raw(x-bpp)
潜水艦(x)+生です。(x-bpp)
(computed mod 256), where Raw refers to the bytes already decoded.
(モッズ風の256を)計算しました。そこでは、Rawが既に解読されたバイトについて言及します。
6.4. Filter type 2: Up
6.4. タイプ2をフィルターにかけてください: 上がる
The Up filter is just like the Sub filter except that the pixel
immediately above the current pixel, rather than just to its left,
is used as the predictor.
まさしく左にというよりむしろ現在の画素のすぐ上の画素が予言者として使用されているのを除いて、UpフィルタはまさしくSubフィルタに似ています。
To compute the Up filter, apply the following formula to each byte
of the scanline:
Upフィルタを計算するには、走査線の各バイトに以下の公式を適用してください:
Up(x) = Raw(x) - Prior(x)
(x)では、生の(x)と優先的に等しいです。(x)
Boutell, et. al. Informational [Page 33] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[33ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
where x ranges from zero to the number of bytes representing the
scanline minus one, Raw(x) refers to the raw data byte at that
byte position in the scanline, and Prior(x) refers to the
unfiltered bytes of the prior scanline.
xがゼロ〜1を引いて走査線を表すバイト数まで及ぶところと、Raw(x)は走査線でそのバイト位置における未加工データバイトを呼びます、そして、Prior(x)は先の走査線の非濾過のバイトを呼びます。
Note this is done for each byte, regardless of bit depth.
Unsigned arithmetic modulo 256 is used, so that both the inputs
and outputs fit into bytes. The sequence of Up values is
transmitted as the filtered scanline.
噛み付いている深さにかかわらず各バイトのためにこれをすることに注意してください。 無記名の算数の法256が使用されているので、入力と出力の両方がバイトに収まります。 Up値の系列はフィルターにかけることの走査線として伝えられます。
On the first scanline of an image (or of a pass of an interlaced
image), assume Prior(x) = 0 for all x.
イメージ(または交錯しているイメージのパスについて)の最初の走査線では、すべてのxのためにPrior(x)が=0であると仮定してください。
To reverse the effect of the Up filter after decompression, output
the following value:
減圧の後にUpフィルタの効果を逆にするには、以下の値を出力してください:
Up(x) + Prior(x)
(x) +を優先的に上げてください。(x)
(computed mod 256), where Prior refers to the decoded bytes of the
prior scanline.
(モッズ風の256を)計算しました。そこでは、Priorが先の走査線の解読されたバイトについて言及します。
6.5. Filter type 3: Average
6.5. タイプ3をフィルターにかけてください: 平均
The Average filter uses the average of the two neighboring pixels
(left and above) to predict the value of a pixel.
Averageフィルタは、画素の値を予測するのに2隣接している画素(左と上)の平均を使用します。
To compute the Average filter, apply the following formula to each
byte of the scanline:
Averageフィルタを計算するには、走査線の各バイトに以下の公式を適用してください:
Average(x) = Raw(x) - floor((Raw(x-bpp)+Prior(x))/2)
生の平均(x)=(x)--床(生の(x-bpp)+先の(x))/2)
where x ranges from zero to the number of bytes representing the
scanline minus one, Raw(x) refers to the raw data byte at that
byte position in the scanline, Prior(x) refers to the unfiltered
bytes of the prior scanline, and bpp is defined as for the Sub
filter.
xがゼロ〜1を引いて走査線を表すバイト数まで及ぶところと、Raw(x)は走査線でそのバイト位置における未加工データバイトを呼びます、そして、Prior(x)は先の走査線の非濾過のバイトについて言及します、そして、bppはSubフィルタのように定義されます。
Note this is done for each byte, regardless of bit depth. The
sequence of Average values is transmitted as the filtered
scanline.
噛み付いている深さにかかわらず各バイトのためにこれをすることに注意してください。 Average値の系列はフィルターにかけることの走査線として伝えられます。
The subtraction of the predicted value from the raw byte must be
done modulo 256, so that both the inputs and outputs fit into
bytes. However, the sum Raw(x-bpp)+Prior(x) must be formed
without overflow (using at least nine-bit arithmetic). floor()
indicates that the result of the division is rounded to the next
lower integer if fractional; in other words, it is an integer
division or right shift operation.
生のバイトからの予測値の引き算に法256をしなければなりません、入力と出力の両方がバイトに収まるように。 しかしながら、オーバーフローなしで合計Raw(x-bpp)+先の(x)を形成しなければなりません(少なくとも9ビットの演算を使用して)。床()は、断片的であるなら分割の結果が次の下側の整数に一周するのを示します。 言い換えれば、それは、整数分割か正しいシフト操作です。
Boutell, et. al. Informational [Page 34] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[34ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
For all x < 0, assume Raw(x) = 0. On the first scanline of an
image (or of a pass of an interlaced image), assume Prior(x) = 0
for all x.
すべてのx<0に関しては、Raw(x)が=0であると仮定してください。 イメージ(または交錯しているイメージのパスについて)の最初の走査線では、すべてのxのためにPrior(x)が=0であると仮定してください。
To reverse the effect of the Average filter after decompression,
output the following value:
減圧の後にAverageフィルタの効果を逆にするには、以下の値を出力してください:
Average(x) + floor((Raw(x-bpp)+Prior(x))/2)
平均(x)+床(生の(x-bpp)+先の(x))/2)
where the result is computed mod 256, but the prediction is
calculated in the same way as for encoding. Raw refers to the
bytes already decoded, and Prior refers to the decoded bytes of
the prior scanline.
同様に、結果が計算されるところでは、モッズ風の256、しかし、予測はコード化のように計算されます。 生、言及、バイトは既に解読して、Priorは先の走査線の解読されたバイトについて言及します。
6.6. Filter type 4: Paeth
6.6. タイプ4をフィルターにかけてください: Paeth
The Paeth filter computes a simple linear function of the three
neighboring pixels (left, above, upper left), then chooses as
predictor the neighboring pixel closest to the computed value.
This technique is due to Alan W. Paeth [PAETH].
Paethフィルタは、3隣接している画素の簡単な一次関数を計算して(上を左上を出ます)、次に、予言者として計算された値の最も近くで隣接している画素を選びます。 このテクニックはアランW.Paeth[PAETH]のためです。
To compute the Paeth filter, apply the following formula to each
byte of the scanline:
Paethフィルタを計算するには、走査線の各バイトに以下の公式を適用してください:
Paeth(x) = Raw(x) - PaethPredictor(Raw(x-bpp), Prior(x),
Prior(x-bpp))
生のPaeth(x)=(x)--PaethPredictor(生(x-bpp)の、そして、先の(x)、先の(x-bpp))
where x ranges from zero to the number of bytes representing the
scanline minus one, Raw(x) refers to the raw data byte at that
byte position in the scanline, Prior(x) refers to the unfiltered
bytes of the prior scanline, and bpp is defined as for the Sub
filter.
xがゼロ〜1を引いて走査線を表すバイト数まで及ぶところと、Raw(x)は走査線でそのバイト位置における未加工データバイトを呼びます、そして、Prior(x)は先の走査線の非濾過のバイトについて言及します、そして、bppはSubフィルタのように定義されます。
Note this is done for each byte, regardless of bit depth.
Unsigned arithmetic modulo 256 is used, so that both the inputs
and outputs fit into bytes. The sequence of Paeth values is
transmitted as the filtered scanline.
噛み付いている深さにかかわらず各バイトのためにこれをすることに注意してください。 無記名の算数の法256が使用されているので、入力と出力の両方がバイトに収まります。 Paeth値の系列はフィルターにかけることの走査線として伝えられます。
Boutell, et. al. Informational [Page 35] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[35ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
The PaethPredictor function is defined by the following
pseudocode:
PaethPredictor機能は以下の擬似コードによって定義されます:
function PaethPredictor (a, b, c)
begin
; a = left, b = above, c = upper left
p := a + b - c ; initial estimate
pa := abs(p - a) ; distances to a, b, c
pb := abs(p - b)
pc := abs(p - c)
; return nearest of a,b,c,
; breaking ties in order a,b,c.
if pa <= pb AND pa <= pc then return a
else if pb <= pc then return b
else return c
end
機能PaethPredictor(a、b、c)は始まります。 あと=、上のb=、左上のc=p:=は+bです(c)。 初期の見積りが:=腹筋をpaする、(p(a)) a、b、c Pb:=腹筋(p--b)pc:=腹筋(p--c)への距離。 aで最も近いリターン、b、c。 結びつきが中でaを命令する壊す、b、次に、Pb<がほかにpcの当時のリターンbと等しいならpa<=Pbとpa<=pcがほかにaを返すなら、c.はc終わりを返します。
The calculations within the PaethPredictor function must be
performed exactly, without overflow. Arithmetic modulo 256 is to
be used only for the final step of subtracting the function result
from the target byte value.
まさにオーバーフローなしでPaethPredictor機能の中の計算を実行しなければなりません。 算数の法256は目標バイト価値から関数結果を引き算する最終的なステップにだけ使用されることです。
Note that the order in which ties are broken is critical and must
not be altered. The tie break order is: pixel to the left, pixel
above, pixel to the upper left. (This order differs from that
given in Paeth's article.)
結びつきが壊れているオーダーが批判的であり、変更されてはいけないことに注意してください。 タイブレーク命令は以下の通りです。 左への画素、上の画素、左上への画素。 (このオーダーはPaethの記事で与えられたそれと異なっています。)
For all x < 0, assume Raw(x) = 0 and Prior(x) = 0. On the first
scanline of an image (or of a pass of an interlaced image), assume
Prior(x) = 0 for all x.
すべてのx<0に関しては、Raw(x)が=0とPrior(x)=0であると仮定してください。 イメージ(または交錯しているイメージのパスについて)の最初の走査線では、すべてのxのためにPrior(x)が=0であると仮定してください。
To reverse the effect of the Paeth filter after decompression,
output the following value:
減圧の後にPaethフィルタの効果を逆にするには、以下の値を出力してください:
Paeth(x) + PaethPredictor(Raw(x-bpp), Prior(x), Prior(x-bpp))
Paeth(x)+PaethPredictor(生(x-bpp)の、そして、先の(x)、先の(x-bpp))
(computed mod 256), where Raw and Prior refer to bytes already
decoded. Exactly the same PaethPredictor function is used by both
encoder and decoder.
(モッズ風の256を)計算しました。そこでは、RawとPriorが既に解読されたバイトについて言及します。 まさに同じPaethPredictor機能はエンコーダとデコーダの両方によって使用されます。
7. Chunk Ordering Rules
7. 塊注文は統治されます。
To allow new chunk types to be added to PNG, it is necessary to establish rules about the ordering requirements for all chunk types. Otherwise a PNG editing program cannot know what to do when it encounters an unknown chunk.
新しい塊タイプがPNGに加えられるのを許容するために、すべての塊タイプのための注文要件に関して規則を定めるのが必要です。 さもなければ、未知の塊に遭遇する場合、PNGエディティング・プログラムは、何をしたらよいかを知ることができません。
Boutell, et. al. Informational [Page 36] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[36ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
We define a "PNG editor" as a program that modifies a PNG file and wishes to preserve as much as possible of the ancillary information in the file. Two examples of PNG editors are a program that adds or modifies text chunks, and a program that adds a suggested palette to a truecolor PNG file. Ordinary image editors are not PNG editors in this sense, because they usually discard all unrecognized information while reading in an image. (Note: we strongly encourage programs handling PNG files to preserve ancillary information whenever possible.)
私たちはPNGファイルを変更するプログラムとファイルの補助的情報をできるだけ保存する願望と「PNGエディタ」を定義します。 PNGエディタの2つの例が、テキスト塊を加えるか、または変更するプログラムと、提案されたパレットをtruecolor PNGファイルに追加するプログラムです。 この意味で、普通のイメージ・エディタはPNGエディタではありません、彼らがイメージで読んでいる間、通常すべての認識されていない情報を捨てるので。 (注意: 可能であるときはいつも、私たちは、PNGファイルを処理するプログラムが補助的情報を保存するよう強く奨励します。)
As an example of possible problems, consider a hypothetical new ancillary chunk type that is safe-to-copy and is required to appear after PLTE if PLTE is present. If our program to add a suggested PLTE does not recognize this new chunk, it may insert PLTE in the wrong place, namely after the new chunk. We could prevent such problems by requiring PNG editors to discard all unknown chunks, but that is a very unattractive solution. Instead, PNG requires ancillary chunks not to have ordering restrictions like this.
起こりうる問題に関する例として、仮定している新しい付属の塊がコピーするために安全であり、PLTEが存在しているならPLTEの後に現れるのに必要であるタイプであると考えてください。 提案されたPLTEを加える私たちのプログラムがこの新しい塊を認識しないなら、間違った場所にPLTEを挿入するかもしれません、すなわち、新しい塊の後に。 PNGエディタがすべての未知の塊を捨てるのを必要とすることによって、私たちはそのような問題を防ぐことができるでしょうが、それは非常につまらない解決策です。 代わりに、PNGは、付属の塊にはこのような注文制限がないのを必要とします。
To prevent this type of problem while allowing for future extension, we put some constraints on both the behavior of PNG editors and the allowed ordering requirements for chunks.
今後の拡大を考慮している間、このタイプの問題を防ぐために、私たちはPNGエディタの振舞いと塊のための許容注文要件の両方にいくつかの規制を載せます。
7.1. Behavior of PNG editors
7.1. PNGエディタの振舞い
The rules for PNG editors are:
PNGエディタへの規則は以下の通りです。
* When copying an unknown unsafe-to-copy ancillary chunk, a
PNG editor must not move the chunk relative to any critical
chunk. It can relocate the chunk freely relative to other
ancillary chunks that occur between the same pair of
critical chunks. (This is well defined since the editor
must not add, delete, modify, or reorder critical chunks if
it is preserving unknown unsafe-to-copy chunks.)
* When copying an unknown safe-to-copy ancillary chunk, a PNG
editor must not move the chunk from before IDAT to after
IDAT or vice versa. (This is well defined because IDAT is
always present.) Any other reordering is permitted.
* When copying a known ancillary chunk type, an editor need
only honor the specific chunk ordering rules that exist for
that chunk type. However, it can always choose to apply the
above general rules instead.
* PNG editors must give up on encountering an unknown critical
chunk type, because there is no way to be certain that a
valid file will result from modifying a file containing such
a chunk. (Note that simply discarding the chunk is not good
enough, because it might have unknown implications for the
interpretation of other chunks.)
* コピーするのが危険である未知の付属の塊をコピーするとき、PNGエディタはどんな批判的な塊に比例して塊を動かしてはいけません。 それは同じ組の批判的な塊の間に起こる他の付属の塊に比例して塊を自由に移動させることができます。 (エディタが加えてはいけないのでこれがよく定義される、削除、変更、追加注文塊がそれであるならコピーするのが危険である未知の塊を保存していることに批判的である、) * 未知のコピーするために安全な付属の塊をコピーするとき、必須が塊を後IDATへのIDATの前か逆もまた同様に動かさないPNGエディタです。 (IDATがいつも存在しているので、これはよく定義されます。) いかなる他の再命令も受入れられます。 * 知られている付属の塊タイプをコピーするとき、エディタはその塊タイプのために存在する規則を注文する特定の塊を光栄に思うだけでよいです。 しかしながら、それは、いつも代わりに上の総則を適用するのを選ぶことができます。 * PNGエディタは、未知の重要な塊タイプに遭遇するのに見切りをつけなければなりません、有効なファイルが結果として生じるのを確信している方法が全くそのような塊を含むファイルを変更するのでないので。 (単に塊を捨てるのが十分役に立たないことに注意してください、それには他の塊の解釈のための未知の意味があるかもしれないので。)
Boutell, et. al. Informational [Page 37] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[37ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
These rules are expressed in terms of copying chunks from an input
file to an output file, but they apply in the obvious way if a PNG
file is modified in place.
これらの規則は入力ファイルから出力ファイルまで塊をコピーすることに関して表されますが、PNGファイルが適所で変更されるなら、それらは当たり前の方法的に適用します。
See also Chunk naming conventions (Section 3.3).
また、Chunkが(セクション3.3)とコンベンションを命名しているのを見てください。
7.2. Ordering of ancillary chunks
7.2. 付属の塊の注文
The ordering rules for an ancillary chunk type cannot be any
stricter than this:
注文は、付属の塊のためにタイプがこれより少しも厳しいはずがないと裁決します:
* Unsafe-to-copy chunks can have ordering requirements
relative to critical chunks.
* Safe-to-copy chunks can have ordering requirements relative
to IDAT.
* コピーするのが危険である塊は批判的な塊に比例して注文要件を持つことができます。 * コピーするために安全な塊はIDATに比例して注文要件を持つことができます。
The actual ordering rules for any particular ancillary chunk type
may be weaker. See for example the ordering rules for the
standard ancillary chunk types (Summary of standard chunks,
Section 4.3).
実際の注文は、どんな特定の付属の塊のためにもタイプが、より弱いかもしれないと裁決します。 例えば、注文が標準の付属の塊タイプ(標準の塊の概要、セクション4.3)のために統治されるのを確実にしてください。
Decoders must not assume more about the positioning of any
ancillary chunk than is specified by the chunk ordering rules. In
particular, it is never valid to assume that a specific ancillary
chunk type occurs with any particular positioning relative to
other ancillary chunks. (For example, it is unsafe to assume that
your private ancillary chunk occurs immediately before IEND. Even
if your application always writes it there, a PNG editor might
have inserted some other ancillary chunk after it. But you can
safely assume that your chunk will remain somewhere between IDAT
and IEND.)
デコーダは規則を注文する塊によって指定されるよりどんな付属の塊の位置決めに関する以上も仮定してはいけません。 特定の付属の塊タイプが他の付属の塊に比例したどんな特定の位置決めでも起こると仮定するのは特に、決して有効ではありません。 (例えば、あなたの個人的な付属の塊がIENDの直前起こると仮定するのは危険です。 あなたのアプリケーションがそこにいつもそれを書いても、PNGエディタはそれの後にある他の付属の塊を挿入したかもしれません。 しかし、あなたは、あなたの塊がIDATとIENDの間のどこかに残ると安全に仮定できます。)
7.3. Ordering of critical chunks
7.3. 批判的な塊の注文
Critical chunks can have arbitrary ordering requirements, because
PNG editors are required to give up if they encounter unknown
critical chunks. For example, IHDR has the special ordering rule
that it must always appear first. A PNG editor, or indeed any
PNG-writing program, must know and follow the ordering rules for
any critical chunk type that it can emit.
批判的な塊は任意の注文要件を持つことができます、彼らが未知の批判的な塊に遭遇するならPNGエディタがあきらめなければならないので。 例えば、IHDRには、最初にいつも現れなければならないという特別な注文規則があります。 PNGエディタ、または本当にどんなPNGを書いているプログラムも、それが放つことができるどんな重要な塊タイプのための注文規則も知って、従わなければなりません。
Boutell, et. al. Informational [Page 38] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[38ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
8. Miscellaneous Topics
8. 種々雑多な話題
8.1. File name extension
8.1. ファイル名の拡張子
On systems where file names customarily include an extension
signifying file type, the extension ".png" is recommended for PNG
files. Lower case ".png" is preferred if file names are case-
sensitive.
ファイル名が通例にファイルの種類を意味する拡大を含んでいるシステムの上で、拡大".png"はPNGファイルのために推薦されます。 ファイル名がケース機密であるなら、下側のケース".png"は好まれます。
8.2. Internet media type
8.2. インターネットメディアはタイプされます。
The Internet Assigned Numbers Authority (IANA) has registered
"image/png" as the Internet Media Type for PNG [RFC-2045, RFC-
2048]. For robustness, decoders may choose to also support the
interim media type "image/x-png" which was in use before
registration was complete.
インターネットAssigned民数記Authority(IANA)はPNG[RFC-2045、RFC2048]のためのインターネットメディアTypeとして「イメージ/png」を登録しました。 丈夫さのために、デコーダは、また、登録が完全になる前に使用中であった当座のメディアタイプ「イメージ/x-png」を支持するのを選ぶかもしれません。
8.3. Macintosh file layout
8.3. マッキントッシュファイルレイアウト
In the Apple Macintosh system, the following conventions are
recommended:
アップルマッキントッシュシステムでは、以下のコンベンションはお勧めです:
* The four-byte file type code for PNG files is "PNGf". (This
code has been registered with Apple for PNG files.) The
creator code will vary depending on the creating
application.
* The contents of the data fork must be a PNG file exactly as
described in the rest of this specification.
* The contents of the resource fork are unspecified. It may
be empty or may contain application-dependent resources.
* When transferring a Macintosh PNG file to a non-Macintosh
system, only the data fork should be transferred.
* PNGファイルのための4バイトのファイルの種類コードは"PNGf"です。 (このコードはPNGファイルのためにアップルに示されました。) 作成アプリケーションによって、創造者コードは異なるでしょう。 * データフォークのコンテンツはちょうどこの仕様の残りで説明されるようにPNGファイルであるに違いありません。 * リソースフォークの内容は不特定です。 それは、空であるかもしれないか、またはアプリケーション依存するリソースを含むかもしれません。 * マッキントッシュPNGファイルを非マッキントッシュシステムに移すとき、データフォークだけを移すべきです。
8.4. Multiple-image extension
8.4. 複数のイメージ拡張子
PNG itself is strictly a single-image format. However, it may be
necessary to store multiple images within one file; for example,
this is needed to convert some GIF files. In the future, a
multiple-image format based on PNG may be defined. Such a format
will be considered a separate file format and will have a
different signature. PNG-supporting applications may or may not
choose to support the multiple-image format.
PNG自身は厳密にそうです。ただ一つの画像形式。 しかしながら、1個のファイルの中に複数のイメージを格納するのが必要であるかもしれません。 例えば、これが、いくつかのGIFファイルを変換するのに必要です。 将来、PNGに基づく複数の画像形式は定義されるかもしれません。 そのような形式は、別々のファイル形式であると考えられて、異なった署名を持つでしょう。 PNGを支持しているアプリケーションは、複数の画像形式を支持するのを選ぶかもしれません。
See Rationale: Why not these features? (Section 12.3).
原理を見てください: なぜこれらの特徴でない? (セクション12.3。)
Boutell, et. al. Informational [Page 39] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[39ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
8.5. Security considerations
8.5. セキュリティ問題
A PNG file or datastream is composed of a collection of explicitly
typed "chunks". Chunks whose contents are defined by the
specification could actually contain anything, including malicious
code. But there is no known risk that such malicious code could
be executed on the recipient's computer as a result of decoding
the PNG image.
PNGファイルかdatastreamが明らかにタイプされた「塊」の収集で構成されます。 コンテンツが仕様で定義される塊は実際に悪質なコードを含む何でも含むかもしれません。 しかし、PNGイメージを解読することの結果、受取人のコンピュータでそのような悪質なコードを実行できたという危険は知られていません。
The possible security risks associated with future chunk types
cannot be specified at this time. Security issues will be
considered when evaluating chunks proposed for registration as
public chunks. There is no additional security risk associated
with unknown or unimplemented chunk types, because such chunks
will be ignored, or at most be copied into another PNG file.
このとき、将来の塊タイプに関連している可能なセキュリティ危険を指定できません。 登録のために公共の塊として提案された塊を評価するとき、安全保障問題は考えられるでしょう。 未知の、または、非実行された塊タイプに関連しているどんな追加担保のリスクもありません、そのような塊が無視されるか、または別のPNGファイルの中に高々コピーされるので。
The tEXt and zTXt chunks contain data that is meant to be
displayed as plain text. It is possible that if the decoder
displays such text without filtering out control characters,
especially the ESC (escape) character, certain systems or
terminals could behave in undesirable and insecure ways. We
recommend that decoders filter out control characters to avoid
this risk; see Recommendations for Decoders: Text chunk processing
(Section 10.11).
tEXtとzTXt塊はプレーンテキストとして表示されることになっているデータを含んでいます。 デコーダが制御文字を無視しないでそのようなテキストを表示するなら、特にESC(逃げる)キャラクタ、あるシステムまたは端末が望ましくなくて不安定な方法で反応するかもしれないのは、可能です。 私たちは、デコーダがこの危険を避けるために制御文字を無視することを勧めます。 Decodersに関してRecommendationsを見てください: テキスト塊処理(セクション10.11)。
Because every chunk's length is available at its beginning, and
because every chunk has a CRC trailer, there is a very robust
defense against corrupted data and against fraudulent chunks that
attempt to overflow the decoder's buffers. Also, the PNG
signature bytes provide early detection of common file
transmission errors.
あらゆる塊の長さが始めに有効であり、あらゆる塊がCRCトレーラを持っているので、非常に体力を要しているディフェンスは崩壊したデータに対してデコーダのバッファからはみ出すのを試みる詐欺的な塊に反対しています。 また、PNG署名バイトは一般的なファイル伝送エラーの早期発見を提供します。
A decoder that fails to check CRCs could be subject to data
corruption. The only likely consequence of such corruption is
incorrectly displayed pixels within the image. Worse things might
happen if the CRC of the IHDR chunk is not checked and the width
or height fields are corrupted. See Recommendations for Decoders:
Error checking (Section 10.1).
CRCsをチェックしないデコーダはデータの汚染を受けることがあるかもしれません。 そのような不正の唯一の起こりそうな結果がイメージの中の不当に表示された画素です。 IHDR塊のCRCがチェックされないで、幅か高さの分野が崩壊するなら、さらに悪い事態は起こるかもしれません。 デコーダのための推薦を見てください: (セクション10.1)をチェックする誤り。
A poorly written decoder might be subject to buffer overflow,
because chunks can be extremely large, up to (2^31)-1 bytes long.
But properly written decoders will handle large chunks without
difficulty.
不十分に書かれたデコーダはオーバーフローをバッファリングするようになることがあるかもしれません、塊が長い間-1バイトに(2^31)まで非常に大きい場合があるので。 しかし、適切に書かれたデコーダは難無く大きい塊を扱うでしょう。
Boutell, et. al. Informational [Page 40] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[40ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
9. Recommendations for Encoders
9. エンコーダのための推薦
This chapter gives some recommendations for encoder behavior. The only absolute requirement on a PNG encoder is that it produce files that conform to the format specified in the preceding chapters. However, best results will usually be achieved by following these recommendations.
本章はエンコーダの振舞いのためのいくつかの推薦を与えます。 PNGエンコーダに関する唯一の絶対条件は先の章で指定された形式に一致しているファイルを作り出すということです。 しかしながら、通常、最も良い結果は、これらの推薦に続くことによって、獲得されるでしょう。
9.1. Sample depth scaling
9.1. サンプル深さスケーリング
When encoding input samples that have a sample depth that cannot
be directly represented in PNG, the encoder must scale the samples
up to a sample depth that is allowed by PNG. The most accurate
scaling method is the linear equation
PNGに直接表すことができないサンプルの深さを持っている入力のサンプルをコード化するとき、エンコーダはPNGによって許容されているサンプルの深さにサンプルまで拡大しなければなりません。 最も正確なスケーリング方法は一次方程式です。
output = ROUND(input * MAXOUTSAMPLE / MAXINSAMPLE)
出力はROUNDと等しいです。(入力*MAXOUTSAMPLE / MAXINSAMPLE)
where the input samples range from 0 to MAXINSAMPLE and the
outputs range from 0 to MAXOUTSAMPLE (which is (2^sampledepth)-1).
入力のサンプルがどこで0〜MAXINSAMPLEまで及ぶか、そして、出力は0〜MAXOUTSAMPLE((2^sampledepth)-1である)まで及びます。
A close approximation to the linear scaling method can be achieved
by "left bit replication", which is shifting the valid bits to
begin in the most significant bit and repeating the most
significant bits into the open bits. This method is often faster
to compute than linear scaling. As an example, assume that 5-bit
samples are being scaled up to 8 bits. If the source sample value
is 27 (in the range from 0-31), then the original bits are:
「左では、模写に噛み付いたこと」によって直線的なスケーリング方法への厳密な近似を達成できます。(それは、最も重要なビットの、そして、繰り返している最も重要なビットで開いているビットに始める有効なビットを移動させています)。 計算することではこの方法は直線的なスケーリングよりしばしば速いです。 例として、5ビットのサンプルが8ビットに拡大されていると仮定してください。 ソース標本値が27(0-31からの範囲の)であるなら、元のビットは以下の通りです。
4 3 2 1 0
---------
1 1 0 1 1
4 3 2 1 0 --------- 1 1 0 1 1
Left bit replication gives a value of 222:
左のビット模写は222の値を与えます:
7 6 5 4 3 2 1 0
----------------
1 1 0 1 1 1 1 0
|=======| |===|
| Leftmost Bits Repeated to Fill Open Bits
|
Original Bits
7 6 5 4 3 2 1 0 ---------------- 1 1 0 1 1 1 1 0 |=======| |===| | 開いているビットをいっぱいにするために繰り返された一番左ビット| 元のビット
which matches the value computed by the linear equation. Left bit
replication usually gives the same value as linear scaling, and is
never off by more than one.
一次方程式によって計算された値を合わせます。 左のビット模写は、通常、直線的なスケーリングと同じ値を与えて、より1時までに決して取り止めになっていません。
Boutell, et. al. Informational [Page 41] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[41ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
A distinctly less accurate approximation is obtained by simply
left-shifting the input value and filling the low order bits with
zeroes. This scheme cannot reproduce white exactly, since it does
not generate an all-ones maximum value; the net effect is to
darken the image slightly. This method is not recommended in
general, but it does have the effect of improving compression,
particularly when dealing with greater-than-eight-bit sample
depths. Since the relative error introduced by zero-fill scaling
is small at high sample depths, some encoders may choose to use
it. Zero-fill must not be used for alpha channel data, however,
since many decoders will special-case alpha values of all zeroes
and all ones. It is important to represent both those values
exactly in the scaled data.
入力値を左で単に移行させて、ゼロで下位のビットを満たすことによって、明瞭にそれほど正確でない近似を得ます。 オールもの最大値を発生させないので、この計画はまさに白を再生させることができません。 ネットの効果はイメージをわずかに暗くすることです。 この方法は一般に推薦されませんが、それで、特に8ビット以上に対処するときの圧縮を改良するという効果は深層を抽出します。 無中詰めスケーリングで導入された相対誤差が深層、いくつかのエンコーダがそうする高いサンプルで小さいので、それを使用するのを選んでください。 多くのデコーダはすべてのゼロとすべてのものの特別なケース文字値を使用されるので、しかしながら、アルファチャンネルデータに無中詰めを使用してはいけません。 ちょうどスケーリングされたデータのそれらの値の両方を表すのは重要です。
When the encoder writes an sBIT chunk, it is required to do the
scaling in such a way that the high-order bits of the stored
samples match the original data. That is, if the sBIT chunk
specifies a sample depth of S, the high-order S bits of the stored
data must agree with the original S-bit data values. This allows
decoders to recover the original data by shifting right. The
added low-order bits are not constrained. Note that all the above
scaling methods meet this restriction.
エンコーダがsBIT塊を書くと、そのような方法でスケーリングするために、格納されたサンプルの高位のビットがオリジナルのデータに合っているのが必要です。 すなわち、sBIT塊がSのサンプルの深さを指定するなら、記憶されたデータの高位Sビットは元のS-ビット・データ値に同意しなければなりません。 これで、デコーダは、まさしく移行することによって、オリジナルのデータを回復できます。 加えられた下位のビットは強制的ではありません。 すべての上のスケーリング方法がこの制限を満たすことに注意してください。
When scaling up source data, it is recommended that the low-order
bits be filled consistently for all samples; that is, the same
source value should generate the same sample value at any pixel
position. This improves compression by reducing the number of
distinct sample values. However, this is not a requirement, and
some encoders may choose not to follow it. For example, an
encoder might instead dither the low-order bits, improving
displayed image quality at the price of increasing file size.
ソースデータを拡大するとき、下位のビットがすべてのサンプルのために一貫していっぱいにされるのは、お勧めです。 すなわち、同じソース値はどんな画素位置でも同じ標本値を発生させるべきです。 これは、異なった標本値の数を減少させることによって、圧縮を改良します。 しかしながら、これは要件ではありません、そして、いくつかのエンコーダがそれに続かないのを選ぶかもしれません。 例えば、エンコーダは代わりにうろたえるかもしれません。下位のビット、向上は増加するファイルサイズの価格における画質を表示しました。
In some applications the original source data may have a range
that is not a power of 2. The linear scaling equation still works
for this case, although the shifting methods do not. It is
recommended that an sBIT chunk not be written for such images,
since sBIT suggests that the original data range was exactly
0..2^S-1.
使用目的によっては一次資料データには、2のパワーでない範囲があるかもしれません。 シフト法は利きませんが、直線的なスケーリング方程式はこのような場合まだ利いています。 sBIT塊がそのようなイメージのために書かれていないのは、お勧めです、sBITが、元のデータ範囲がまさに0であったと示唆するので。2^S-1。
9.2. Encoder gamma handling
9.2. エンコーダガンマ取り扱い
See Gamma Tutorial (Chapter 13) if you aren't already familiar
with gamma issues.
既にガンマ問題になじみ深くないなら、Gamma Tutorial(第13章)を見てください。
Proper handling of gamma encoding and the gAMA chunk in an encoder
depends on the prior history of the sample values and on whether
these values have already been quantized to integers.
エンコーダのガンマコード化とgAMA塊の適切な取り扱いは値とこれらの値が既に整数に量子化されたかどうかに関するサンプルの先の歴史によります。
Boutell, et. al. Informational [Page 42] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[42ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
If the encoder has access to sample intensity values in floating-
point or high-precision integer form (perhaps from a computer
image renderer), then it is recommended that the encoder perform
its own gamma encoding before quantizing the data to integer
values for storage in the file. Applying gamma encoding at this
stage results in images with fewer banding artifacts at a given
sample depth, or allows smaller samples while retaining the same
visual quality.
エンコーダが浮動ポイントか高精度整数フォーム(恐らくコンピュータ画像レンダラーからの)のサンプル強度値に近づく手段を持っているなら、格納のためにファイルで整数値にデータを量子化する前にエンコーダがそれ自身のガンマコード化を実行するのは、お勧めです。 現在のところガンマコード化を適用すると、イメージが与えられたサンプルの深さで人工物を括らないのにもたらされるか、または、より小さいサンプルは同じ視覚品質を保有している間、許容されます。
A linear intensity level, expressed as a floating-point value in
the range 0 to 1, can be converted to a gamma-encoded sample value
by
浮動小数点の値として範囲で0〜1に言い表された直線的な強度レベルはガンマでコード化された標本値に変換できます。
sample = ROUND((intensity ^ encoder_gamma) * MAXSAMPLE)
サンプル=ROUND((強度^エンコーダ_ガンマ)*MAXSAMPLE)
The file_gamma value to be written in the PNG gAMA chunk is the
same as encoder_gamma in this equation, since we are assuming the
initial intensity value is linear (in effect, camera_gamma is
1.0).
PNG gAMA塊に書かれているファイル_ガンマ値はエンコーダ_ガンマとこの方程式で同じです、私たちが、初期の強度値が直線的であると(事実上、カメラ_ガンマは1.0です)思っているので。
If the image is being written to a file only, the encoder_gamma
value can be selected somewhat arbitrarily. Values of 0.45 or 0.5
are generally good choices because they are common in video
systems, and so most PNG decoders should do a good job displaying
such images.
イメージがファイルだけに書かれているなら、いくらか任意にエンコーダ_ガンマ値を選択できます。 それらがビデオシステムで一般的であるので0.45か0.5の値が一般に良い選択であるので、ほとんどのPNGデコーダがそのようなイメージを表示しながら、良い仕事をするはずです。
Some image renderers may simultaneously write the image to a PNG
file and display it on-screen. The displayed pixels should be
gamma corrected for the display system and viewing conditions in
use, so that the user sees a proper representation of the intended
scene. An appropriate gamma correction value is
いくつかのイメージレンダラーが、同時に、PNGファイルにイメージを書いて、スクリーンの上にそれを表示するかもしれません。 表示された画素はディスプレイ・システムのために修正されて、使用中の状態を見るガンマであるべきです、ユーザが意図している場面の適切な上演を見るように。 適切なガンマ補正はそうです。
screen_gc = viewing_gamma / display_gamma
スクリーン_gcは_ガンマ/表示_ガンマを見るのと等しいです。
If the renderer wants to write the same gamma-corrected sample
values to the PNG file, avoiding a separate gamma-encoding step
for file output, then this screen_gc value should be written in
the gAMA chunk. This will allow a PNG decoder to reproduce what
the file's originator saw on screen during rendering (provided the
decoder properly supports arbitrary values in a gAMA chunk).
同じガンマで直っている標本値をPNGファイルに書くファイル出力のための別々のガンマをコード化するステップを避けるレンダラー必需品であるなら、このスクリーン_gc値はgAMA塊に書かれるべきです。 これで、PNGデコーダはファイルの創始者が表現の間にスクリーンの上であることを見たものを再生させることができるでしょう(デコーダが適切にgAMA塊における任意の値を支持するなら)。
However, it is equally reasonable for a renderer to apply gamma
correction for screen display using a gamma appropriate to the
viewing conditions, and to separately gamma-encode the sample
values for file storage using a standard value of gamma such as
0.5. In fact, this is preferable, since some PNG decoders may not
accurately display images with unusual gAMA values.
しかしながら、レンダラーが見る状態に適切なガンマを使用することでスクリーン表示のためのガンマ修正を適用して、別々にファイル記憶装置への標本値をガンマでコード化するのは、0.5などのガンマの基準値を使用することで等しく妥当です。 事実上、いくつかのPNGデコーダが正確に珍しいgAMA値があるイメージを表示しないかもしれないので、これは望ましいです。
Boutell, et. al. Informational [Page 43] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[43ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
Computer graphics renderers often do not perform gamma encoding,
instead making sample values directly proportional to scene light
intensity. If the PNG encoder receives sample values that have
already been quantized into linear-light integer values, there is
no point in doing gamma encoding on them; that would just result
in further loss of information. The encoder should just write the
sample values to the PNG file. This "linear" sample encoding is
equivalent to gamma encoding with a gamma of 1.0, so graphics
programs that produce linear samples should always emit a gAMA
chunk specifying a gamma of 1.0.
代わりに標本値を場面光強度に正比例するようにして、コンピュータグラフィックスレンダラーはしばしばガンマコード化を実行するというわけではありません。 PNGエンコーダが既に直線的な光の整数値に量子化された標本値を受けるなら、それらの上のガンマコード化をする意味が全くありません。 それはただ情報の一層の損失をもたらすでしょう。 エンコーダはただPNGファイルに標本値を書くはずです。 この「直線的な」サンプルコード化が1.0のガンマによるガンマコード化に同等であるので、直線的なサンプルを作り出す画像プログラムはいつも1.0のガンマを指定するgAMA塊を放つはずです。
When the sample values come directly from a piece of hardware, the
correct gAMA value is determined by the gamma characteristic of
the hardware. In the case of video digitizers ("frame grabbers"),
gAMA should be 0.45 or 0.5 for NTSC (possibly less for PAL or
SECAM) since video camera transfer functions are standardized.
Image scanners are less predictable. Their output samples may be
linear (gamma 1.0) since CCD sensors themselves are linear, or the
scanner hardware may have already applied gamma correction
designed to compensate for dot gain in subsequent printing (gamma
of about 0.57), or the scanner may have corrected the samples for
display on a CRT (gamma of 0.4-0.5). You will need to refer to
the scanner's manual, or even scan a calibrated gray wedge, to
determine what a particular scanner does.
標本値が直接1個のハードウェアから来るとき、正しいgAMA値はハードウェアのガンマの特性で決定します。 ビデオディジタイザ(「フレームひったくり」)の場合では、ビデオカメラ伝達関数が標準化されるので、gAMAはNTSC(PALかSECAMには、ことによるとより少ない)のための0.45か0.5であるべきです。 イメージスキャナはそれほど予測できません。 CCDセンサ自体が直線的であるので、それらの出力のサンプルが直線的であったかもしれませんか(ガンマ1.0)、スキャナハードウェアが既にその後の印刷(およそ0.57のガンマ)のドット・ゲインを補うように設計されたガンマ修正を当てはまったかもしれませんか、またはスキャナはCRT(0.4-0.5のガンマ)で表示のためのサンプルを修正したかもしれません。 あなたは、スキャナのマニュアルを参照するのが必要である、または特定のスキャナが何をするかを決定するために較正されたグレーのくさびをスキャンさえするでしょう。
File format converters generally should not attempt to convert
supplied images to a different gamma. Store the data in the PNG
file without conversion, and record the source gamma if it is
known. Gamma alteration at file conversion time causes re-
quantization of the set of intensity levels that are represented,
introducing further roundoff error with little benefit. It's
almost always better to just copy the sample values intact from
the input to the output file.
一般に、コンバータが変換するのを試みるはずがないファイル形式は異なったガンマにイメージを供給しました。 PNGファイルに変換なしでデータを格納してください、そして、それが知られているなら、ソースガンマを記録してください。 ファイル変換時のガンマ変更は表される強度レベルのセットの再量子化を引き起こします、少ない利益でさらなるロンダード誤りを導入して。 ほとんどいつもただ入力から出力ファイルまで完全な標本値をコピーしているほうがよいです。
In some cases, the supplied image may be in an image format (e.g.,
TIFF) that can describe the gamma characteristic of the image. In
such cases, a file format converter is strongly encouraged to
write a PNG gAMA chunk that corresponds to the known gamma of the
source image. Note that some file formats specify the gamma of
the display system, not the camera. If the input file's gamma
value is greater than 1.0, it is almost certainly a display system
gamma, and you should use its reciprocal for the PNG gAMA.
いくつかの場合、イメージのガンマの特性について説明できる画像形式(例えば、TIFF)で供給されたイメージがあるかもしれません。 そのような場合、ファイル形式コンバータがソースイメージの知られているガンマに対応するPNG gAMA塊を書くよう強く奨励されます。 いくつかのファイル形式がカメラではなく、ディスプレイ・システムのガンマを指定することに注意してください。 入力ファイルのガンマ値が1.0以上であるなら、それはほぼ確実にディスプレイ・システムガンマです、そして、あなたはPNG gAMAに逆数を使用するべきです。
Boutell, et. al. Informational [Page 44] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[44ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
If the encoder or file format converter does not know how an image
was originally created, but does know that the image has been
displayed satisfactorily on a display with gamma display_gamma
under lighting conditions where a particular viewing_gamma is
appropriate, then the image can be marked as having the
file_gamma:
エンコーダかファイル形式コンバータが、イメージが元々どのように作成されたかを知りませんが、イメージが満足に表示に照明状態の特定の見る_ガンマが適切であるガンマ表示_ガンマで表示されたのを知っているなら、ファイル_ガンマを持っているとしてイメージをマークできます:
file_gamma = viewing_gamma / display_gamma
_ガンマ/表示_ガンマを見るファイル_ガンマ=
This will allow viewers of the PNG file to see the same image that
the person running the file format converter saw. Although this
may not be precisely the correct value of the image gamma, it's
better to write a gAMA chunk with an approximately right value
than to omit the chunk and force PNG decoders to guess at an
appropriate gamma.
これで、PNGファイルのビューアーは人がファイル形式コンバータを動かして、見られたのと同じイメージを見ることができるでしょう。 これが正確にイメージガンマの正しい値でないかもしれませんが、ほとんど正しい値でgAMA塊を書くのは塊を忘れて、PNGデコーダに適切なガンマを推測させるより良いです。
On the other hand, if the image file is being converted as part of
a "bulk" conversion, with no one looking at each image, then it is
better to omit the gAMA chunk entirely. If the image gamma has to
be guessed at, leave it to the decoder to do the guessing.
他方では、イメージ・ファイルが「大量」の変換の一部として変換されているなら、その時、だれも各イメージを見ていなく、gAMA塊を完全に省略しているほうがよいです。 イメージガンマが推測されなければならないなら、推測するようにデコーダに任せてください。
Gamma does not apply to alpha samples; alpha is always represented
linearly.
ガンマはアルファのサンプルに適用されません。 アルファはいつも直線的に表されます。
See also Recommendations for Decoders: Decoder gamma handling
(Section 10.5).
また、Decodersに関してRecommendationsを見てください: デコーダガンマ取り扱い(セクション10.5)。
9.3. Encoder color handling
9.3. エンコーダ色の取り扱い
See Color Tutorial (Chapter 14) if you aren't already familiar
with color issues.
既に色の問題になじみ深くないなら、Color Tutorial(第14章)を見てください。
If it is possible for the encoder to determine the chromaticities
of the source display primaries, or to make a strong guess based
on the origin of the image or the hardware running it, then the
encoder is strongly encouraged to output the cHRM chunk. If it
does so, the gAMA chunk should also be written; decoders can do
little with cHRM if gAMA is missing.
エンコーダがソース表示予備選挙の色度を測定するか、またはイメージかそれを走らせるハードウェアの起源に基づいている強い推測をするのが可能であるなら、エンコーダがcHRM塊を出力するよう強く奨励されます。 また、そうするなら、gAMA塊は書かれるべきです。 gAMAがなくなるなら、デコーダは少ししかcHRMを処理できません。
Boutell, et. al. Informational [Page 45] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[45ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
Video created with recent video equipment probably uses the CCIR
709 primaries and D65 white point [ITU-BT709], which are:
最近のビデオ機器で作成されたビデオはたぶんCCIR709予備選挙とD65の白いポイント[ITU-BT709]を使用します。(それは、以下の通りです)。
R G B White
x 0.640 0.300 0.150 0.3127
y 0.330 0.600 0.060 0.3290
R G B白いx0.640 0.300 0.150 0.3127y0.330 0.600 0.060 0.3290
An older but still very popular video standard is SMPTE-C [SMPTE-
170M]:
より古い、しかし、まだ非常にポピュラーなビデオ規格はSMPTE-C[SMPTE170M]です:
R G B White
x 0.630 0.310 0.155 0.3127
y 0.340 0.595 0.070 0.3290
R G B白いx0.630 0.310 0.155 0.3127y0.340 0.595 0.070 0.3290
The original NTSC color primaries have not been used in decades.
Although you may still find the NTSC numbers listed in standards
documents, you won't find any images that actually use them.
オリジナルのNTSC色の予備選挙は何10年間も使用されていません。 まだ規格文書に記載されたNTSC番号は見つけることができますが、あなたは実際にそれらを使用するどんなイメージも見つけないでしょう。
Scanners that produce PNG files as output should insert the filter
chromaticities into a cHRM chunk and the camera_gamma into a gAMA
chunk.
出力されるようにPNGファイルを作り出すスキャナーズはcHRM塊へのフィルタ色度とカメラ_ガンマをgAMA塊に挿入するべきです。
In the case of hand-drawn or digitally edited images, you have to
determine what monitor they were viewed on when being produced.
Many image editing programs allow you to specify what type of
monitor you are using. This is often because they are working in
some device-independent space internally. Such programs have
enough information to write valid cHRM and gAMA chunks, and should
do so automatically.
手で描かれたかデジタルに編集されたイメージの場合では、生産されると、あなたは、それらがどんなモニターで見られたかを決心しなければなりません。 多くのイメージエディティング・プログラムで、あなたは、どんなタイプのモニターを使用しているかを指定できます。 これは彼らが何らかの装置から独立しているスペースでしばしば内部的に働いているからです。 そのようなプログラムは、有効なcHRMとgAMAに塊を書くことができるくらいの情報を持って、それほど自動的にするはずです。
If the encoder is compiled as a portion of a computer image
renderer that performs full-spectral rendering, the monitor values
that were used to convert from the internal device-independent
color space to RGB should be written into the cHRM chunk. Any
colors that are outside the gamut of the chosen RGB device should
be clipped or otherwise constrained to be within the gamut; PNG
does not store out of gamut colors.
エンコーダが完全なスペクトル表現を実行するコンピュータ画像レンダラーの一部としてコンパイルされるなら、内部の装置から独立している色のスペースからRGBまで変換するのに使用されたモニター値はcHRM塊に書かれるべきです。 選ばれたRGB装置の全域の外にあるどんな色も、切り取られるべきであるか、または別の方法で全域の中にあるのが抑制されるべきです。 PNGは全域で色を格納しません。
If the computer image renderer performs calculations directly in
device-dependent RGB space, a cHRM chunk should not be written
unless the scene description and rendering parameters have been
adjusted to look good on a particular monitor. In that case, the
data for that monitor (if known) should be used to construct a
cHRM chunk.
コンピュータ画像レンダラーが直接装置依存するRGBスペースで計算して、特定のモニターの上で良く見えるように場面記述と表現パラメタを調整していないなら、cHRM塊を書くべきではありません。 その場合、そのモニター(知られているなら)へのデータは、cHRM塊を構成するのに使用されるべきです。
Boutell, et. al. Informational [Page 46] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[46ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
There are often cases where an image's exact origins are unknown,
particularly if it began life in some other format. A few image
formats store calibration information, which can be used to fill
in the cHRM chunk. For example, all PhotoCD images use the CCIR
709 primaries and D65 whitepoint, so these values can be written
into the cHRM chunk when converting a PhotoCD file. PhotoCD also
uses the SMPTE-170M transfer function, which is closely
approximated by a gAMA of 0.5. (PhotoCD can store colors outside
the RGB gamut, so the image data will require gamut mapping before
writing to PNG format.) TIFF 6.0 files can optionally store
calibration information, which if present should be used to
construct the cHRM chunk. GIF and most other formats do not store
any calibration information.
特にある他の形式で人生を始めたなら、ケースがイメージの正確な起源が未知であるところにしばしばあります。 いくつかの画像形式が調整情報を格納します。(cHRM塊に記入するのにそれを使用できます)。 例えば、すべてのPhotoCDイメージがCCIR709予備選挙とD65 whitepointを使用するので、PhotoCDファイルを変換するとき、cHRM塊にこれらの値を書くことができます。 また、フォトCDはSMPTE-170Mの伝達関数を使用します。(それは、0.5のgAMAによって密接に近似されています)。 (フォトCDがRGB全域の外に色を格納できるので、イメージデータはPNG形式に書く前に、全域マッピングを必要とするでしょう。) 6.0がファイルするTIFFは任意に調整情報を格納できます。(存在しているなら、それは、cHRM塊を構成するのに使用されるべきです)。 GIFと他のほとんどの形式は少しの調整情報も格納しません。
It is not recommended that file format converters attempt to
convert supplied images to a different RGB color space. Store the
data in the PNG file without conversion, and record the source
primary chromaticities if they are known. Color space
transformation at file conversion time is a bad idea because of
gamut mismatches and rounding errors. As with gamma conversions,
it's better to store the data losslessly and incur at most one
conversion when the image is finally displayed.
そのファイル形式コンバータ試みは変換するのが異なったRGB色のスペースにイメージを供給したことが勧められません。 PNGファイルに変換なしでデータを格納してください、そして、それらが知られているなら、ソースの第一の色度を記録してください。 全域ミスマッチと丸め誤差のためにファイル変換時の色の宇宙変化は悪い考えです。 最終的にイメージを表示するとき、ガンマ変換のように、losslesslyにデータを格納して、最も1つで変換を被るのは、より良いです。
See also Recommendations for Decoders: Decoder color handling
(Section 10.6).
また、Decodersに関してRecommendationsを見てください: デコーダ色の取り扱い(セクション10.6)。
9.4. Alpha channel creation
9.4. アルファチャンネル創造
The alpha channel can be regarded either as a mask that
temporarily hides transparent parts of the image, or as a means
for constructing a non-rectangular image. In the first case, the
color values of fully transparent pixels should be preserved for
future use. In the second case, the transparent pixels carry no
useful data and are simply there to fill out the rectangular image
area required by PNG. In this case, fully transparent pixels
should all be assigned the same color value for best compression.
アルファチャンネルを一時イメージの透明な部分を隠すマスク、または非長方形のイメージを構成するための手段と見なすことができます。 前者の場合、完全に見え透いた画素の色の価値は今後の使用のために守られるべきです。 2番目の場合には、見え透いた画素は、どんな役に立つデータも運ばないで、PNGによって必要とされた長方形の画像領域に書き込むために、単にそこにあります。 この場合、同じ色の値は最も良い圧縮のために完全に見え透いた画素にすべて割り当てられるべきです。
Image authors should keep in mind the possibility that a decoder
will ignore transparency control. Hence, the colors assigned to
transparent pixels should be reasonable background colors whenever
feasible.
イメージ作者はデコーダが透明コントロールを無視する可能性を覚えておくべきです。 したがって、可能であるときはいつも、見え透いた画素に割り当てられた色は妥当な背景色であるべきです。
For applications that do not require a full alpha channel, or
cannot afford the price in compression efficiency, the tRNS
transparency chunk is also available.
また、完全なアルファチャンネルを必要としないことができないか、圧縮効率における価格を都合することができないアプリケーションに、tRNS透明塊も利用可能です。
Boutell, et. al. Informational [Page 47] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[47ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
If the image has a known background color, this color should be
written in the bKGD chunk. Even decoders that ignore transparency
may use the bKGD color to fill unused screen area.
イメージに知られている背景色があるなら、この色はbKGD塊に書かれるべきです。 透明を無視するデコーダさえ、未使用の画面領域をいっぱいにするのにbKGD色を使用するかもしれません。
If the original image has premultiplied (also called "associated")
alpha data, convert it to PNG's non-premultiplied format by
dividing each sample value by the corresponding alpha value, then
multiplying by the maximum value for the image bit depth, and
rounding to the nearest integer. In valid premultiplied data, the
sample values never exceed their corresponding alpha values, so
the result of the division should always be in the range 0 to 1.
If the alpha value is zero, output black (zeroes).
オリジナルのイメージに前掛け算をさせられた(また、「関連している」と呼ばれた)アルファ・データがあるなら、対応する文字値に各標本値を割って、次に、最大値でイメージの噛み付いている深さに増えるのによるPNGの非前掛け算をさせられた形式にそれを変換して、最も近い整数に一周を変換してください。 有効な前掛け算をさせられたデータに、標本値がそれらの対応する文字値を決して超えていないので、分割の結果が範囲にいつも0〜1にあるべきです。 文字値がゼロであるなら、黒(ゼロ)を出力してください。
9.5. Suggested palettes
9.5. 提案されたパレット
A PLTE chunk can appear in truecolor PNG files. In such files,
the chunk is not an essential part of the image data, but simply
represents a suggested palette that viewers may use to present the
image on indexed-color display hardware. A suggested palette is
of no interest to viewers running on truecolor hardware.
PLTE塊はtruecolor PNGファイルに現れることができます。 そのようなファイルでは、塊は、イメージデータの不可欠の部分ではありませんが、単に、ビューアーが索引をつけられたカラーディスプレイハードウェアに関するイメージを提示するのに使用するかもしれない提案されたパレットを表します。 提案されたパレットには、ビューアーへのどんな関心もtruecolorハードウェアで動かないのがあります。
If an encoder chooses to provide a suggested palette, it is
recommended that a hIST chunk also be written to indicate the
relative importance of the palette entries. The histogram values
are most easily computed as "nearest neighbor" counts, that is,
the approximate usage of each palette entry if no dithering is
applied. (These counts will often be available for free as a
consequence of developing the suggested palette.)
エンコーダが、提案されたパレットを提供するのを選ぶなら、また、hIST塊がパレットエントリーの相対的な重要性を示すために書かれているのは、お勧めです。 ヒストグラム値は「最も近い隣人」カウントとして最も容易に計算されます、すなわち、それぞれのパレットエントリーの大体の用法はディザリングでないなら適用されています。 (これらのカウントは提案されたパレットを開発する結果としてしばしばただで利用可能になるでしょう。)
For images of color type 2 (truecolor without alpha channel), it
is recommended that the palette and histogram be computed with
reference to the RGB data only, ignoring any transparent-color
specification. If the file uses transparency (has a tRNS chunk),
viewers can easily adapt the resulting palette for use with their
intended background color. They need only replace the palette
entry closest to the tRNS color with their background color (which
may or may not match the file's bKGD color, if any).
カラータイプ2(アルファチャンネルのないtruecolor)のイメージに関しては、パレットとヒストグラムがRGBデータだけに関して計算されるのは、お勧めです、どんな透明色仕様も無視して。 ファイルが透明(tRNS塊を持っている)を使用するなら、ビューアーは彼らの意図している背景色で容易に使用のための結果として起こるパレットを適合させることができます。 彼らは自分達の背景色(もしあればファイルのbKGD色に合うかもしれない)でパレットエントリーをtRNS色の最も近くに取り替えるだけでよいです。
For images of color type 6 (truecolor with alpha channel), it is
recommended that a bKGD chunk appear and that the palette and
histogram be computed with reference to the image as it would
appear after compositing against the specified background color.
This definition is necessary to ensure that useful palette entries
are generated for pixels having fractional alpha values. The
resulting palette will probably only be useful to viewers that
present the image against the same background color. It is
recommended that PNG editors delete or recompute the palette if
they alter or remove the bKGD chunk in an image of color type 6.
カラータイプ6(アルファチャンネルがあるtruecolor)のイメージに関しては、bKGD塊が見えて、パレットとヒストグラムが指定された背景色に対する合成の後に現れるようにイメージに関して計算されるのは、お勧めです。 この定義が、役に立つパレットエントリーが断片的な文字値を持っている何画素も発生するのを保証するのに必要です。 結果として起こるパレットはたぶん単に同じ背景色に対してイメージを提示するビューアーの役に立ちます。 彼らがカラータイプ6のイメージによるbKGD塊を変更するか、または取り除くなら、PNGエディタがパレットを削除するか、または再計算するのが、お勧めです。
Boutell, et. al. Informational [Page 48] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[48ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
If PLTE appears without bKGD in an image of color type 6, the
circumstances under which the palette was computed are
unspecified.
PLTEがbKGDなしでカラータイプ6のイメージで現れるなら、パレットが計算された事情は不特定です。
9.6. Filter selection
9.6. フィルタ選択
For images of color type 3 (indexed color), filter type 0 (None)
is usually the most effective. Note that color images with 256 or
fewer colors should almost always be stored in indexed color
format; truecolor format is likely to be much larger.
カラータイプ3(色に索引をつけます)のイメージに関しては、通常、フィルタタイプ0(なにも)は最も有能です。 256があるカラーイメージか、より少ない色が索引をつけられた色の形式でほとんどいつも格納されるべきであることに注意してください。 truecolor形式ははるかに大きい傾向があります。
Filter type 0 is also recommended for images of bit depths less
than 8. For low-bit-depth grayscale images, it may be a net win
to expand the image to 8-bit representation and apply filtering,
but this is rare.
また、フィルタタイプ0は噛み付いている深層8のイメージのために推薦されます。 低噛み付いている深さグレースケールイメージに関しては、8ビットの表現にイメージを広げて、フィルタリングを適用するのが、ネットの勝利であるかもしれませんが、これはまれです。
For truecolor and grayscale images, any of the five filters may
prove the most effective. If an encoder uses a fixed filter, the
Paeth filter is most likely to be the best.
truecolorとグレースケールイメージに関しては、5個のフィルタのいずれも最も効果的であると判明するかもしれません。 エンコーダが固定フィルタを使用するなら、Paethフィルタは最も良い最も傾向があります。
For best compression of truecolor and grayscale images, we
recommend an adaptive filtering approach in which a filter is
chosen for each scanline. The following simple heuristic has
performed well in early tests: compute the output scanline using
all five filters, and select the filter that gives the smallest
sum of absolute values of outputs. (Consider the output bytes as
signed differences for this test.) This method usually
outperforms any single fixed filter choice. However, it is likely
that much better heuristics will be found as more experience is
gained with PNG.
truecolorとグレースケールイメージの最も良い要約のために、私たちはフィルタが各走査線に選ばれている適応型のフィルタリングアプローチを推薦します。 以下の簡単なヒューリスティックは早めのテストでよく振る舞いました: すべての5個のフィルタを使用することで出力走査線を計算してください、そして、出力の絶対値の最少額を与えるフィルタを選択してください。 (出力バイトがこのテストのためのサインされた違いであるとみなしてください。) 通常、この方法はどんなただ一つの固定フィルタ選択よりも優れています。 しかしながら、PNGと共に、より多くの経験をするのに従って、より良い発見的教授法が見つけられるのは、それだけありそうです。
Filtering according to these recommendations is effective on
interlaced as well as noninterlaced images.
これらの推薦に従ったフィルタリングは交錯して非交錯しているイメージで有効です。
9.7. Text chunk processing
9.7. テキスト塊処理
A nonempty keyword must be provided for each text chunk. The
generic keyword "Comment" can be used if no better description of
the text is available. If a user-supplied keyword is used, be
sure to check that it meets the restrictions on keywords.
それぞれのテキスト塊にnonemptyキーワードを提供しなければなりません。 テキストのどんなより良い記述も利用可能でないなら、「コメント」という一般的なキーワードを使用できます。 ユーザによって供給されたキーワードが使用されているなら、キーワードで制限を満たすのを必ずチェックしてください。
PNG text strings are expected to use the Latin-1 character set.
Encoders should avoid storing characters that are not defined in
Latin-1, and should provide character code remapping if the local
system's character set is not Latin-1.
PNGテキスト文字列がラテン語-1文字の組を使用すると予想されます。 エンコーダは、ラテン語-1で定義されないキャラクタを格納するのを避けるべきであり、ローカルシステムの文字の組がラテン語-1でないならキャラクタコード再写像を前提とするはずです。
Encoders should discourage the creation of single lines of text
longer than 79 characters, in order to facilitate easy reading.
エンコーダは、簡単な読書を容易にするために79のキャラクタより長い間、テキストの単線の創造に水をさしているはずです。
Boutell, et. al. Informational [Page 49] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[49ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
It is recommended that text items less than 1K (1024 bytes) in
size should be output using uncompressed tEXt chunks. In
particular, it is recommended that the basic title and author
keywords should always be output using uncompressed tEXt chunks.
Lengthy disclaimers, on the other hand, are ideal candidates for
zTXt.
サイズにおける1K(1024バイト)未満のテキスト項目が解凍されたtEXt塊を使用する出力であることはお勧めです。 基本のタイトルと作者キーワードがいつも解凍されたtEXt塊を使用する出力であることは特に、お勧めです。 他方では、長い注意書きはzTXtの理想的な候補です。
Placing large tEXt and zTXt chunks after the image data (after
IDAT) can speed up image display in some situations, since the
decoder won't have to read over the text to get to the image data.
But it is recommended that small text chunks, such as the image
title, appear before IDAT.
イメージデータ(IDATの後の)の後に大きいtEXtとzTXt塊を置くと、いくつかの状況における画像表示を早くできます、デコーダがイメージデータを始めるためにテキストを読み通す必要はないので。 しかし、イメージタイトルなどの小さいテキスト塊がIDATの前に現れるのは、お勧めです。
9.8. Use of private chunks
9.8. 個人的な塊の使用
Applications can use PNG private chunks to carry information that
need not be understood by other applications. Such chunks must be
given names with lowercase second letters, to ensure that they can
never conflict with any future public chunk definition. Note,
however, that there is no guarantee that some other application
will not use the same private chunk name. If you use a private
chunk type, it is prudent to store additional identifying
information at the beginning of the chunk data.
アプリケーションは、必要性が他のアプリケーションに解釈されないという情報を運ぶのにPNGの個人的な塊を使用できます。 そのような塊は、どんな今後の公共の塊定義とも決して衝突できないのを保証するためには2番目の小文字の手紙をもっている名でなければなりません。 しかしながら、ある他のアプリケーションが同じ個人的な塊名を使用しないという保証が全くないことに注意してください。 あなたが個人的な塊タイプを使用するなら、塊データの始めに追加身元が分かる情報を格納するのは慎重です。
Use an ancillary chunk type (lowercase first letter), not a
critical chunk type, for all private chunks that store information
that is not absolutely essential to view the image. Creation of
private critical chunks is discouraged because they render PNG
files unportable. Such chunks should not be used in publicly
available software or files. If private critical chunks are
essential for your application, it is recommended that one appear
near the start of the file, so that a standard decoder need not
read very far before discovering that it cannot handle the file.
イメージを見るのに絶対に不可欠でない情報を格納するすべての個人的な塊に、重要な塊タイプではなく、付属の塊タイプ(小文字の最初の手紙)を使用してください。 それらがPNGファイルを「非-携帯用」に表すので、個人的な批判的な塊の創造はお勧めできないです。 公的に利用可能なソフトウェアかファイルでそのような塊を使用するべきではありません。 あなたのアプリケーションに、個人的な批判的な塊が不可欠であるなら、人がファイルの始まりの近くに現れるのは、お勧めです、標準のデコーダが非常にそれがファイルを扱うことができないと発見する前に遠くに読む必要はないように。
If you want others outside your organization to understand a chunk
type that you invent, contact the maintainers of the PNG
specification to submit a proposed chunk name and definition for
addition to the list of special-purpose public chunks (see
Additional chunk types, Section 4.4). Note that a proposed public
chunk name (with uppercase second letter) must not be used in
publicly available software or files until registration has been
approved.
あなたの組織の外における他のものにあなたが発明する塊タイプを理解して欲しいなら、PNG仕様の維持装置に連絡して(Additional塊タイプを見てください、セクション4.4)、専用公共の塊のリストへの追加のための提案された塊名と定義を提出してください。 登録が承認されるまで公的に利用可能なソフトウェアかファイルで提案された公共の塊名(2番目の大文字している手紙がある)を使用してはいけないことに注意してください。
If an ancillary chunk contains textual information that might be
of interest to a human user, you should not create a special chunk
type for it. Instead use a tEXt chunk and define a suitable
keyword. That way, the information will be available to users not
using your software.
付属の塊が人間のユーザにとって、興味深いかもしれない文字情報を含んでいるなら、あなたはそれのための特別な塊タイプを創造するべきではありません。 代わりにtEXt塊を使用してください、そして、適当なキーワードを定義してください。 そのように、情報は、あなたのソフトウェアを使用しないことでユーザにとって利用可能になるでしょう。
Boutell, et. al. Informational [Page 50] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[50ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
Keywords in tEXt chunks should be reasonably self-explanatory,
since the idea is to let other users figure out what the chunk
contains. If of general usefulness, new keywords can be
registered with the maintainers of the PNG specification. But it
is permissible to use keywords without registering them first.
tEXt塊におけるキーワードは合理的に自明であるべきです、考えが他のユーザ図的に、塊が含むものを外に出すことであるので。 一般的な有用性では、PNG仕様の維持装置に新しいキーワードを登録できるなら。 しかし、最初にそれらを登録しないでキーワードを使用するのは許されています。
9.9. Private type and method codes
9.9. 個人的なタイプと方法コード
This specification defines the meaning of only some of the
possible values of some fields. For example, only compression
method 0 and filter types 0 through 4 are defined. Numbers
greater than 127 must be used when inventing experimental or
private definitions of values for any of these fields. Numbers
below 128 are reserved for possible future public extensions of
this specification. Note that use of private type codes may
render a file unreadable by standard decoders. Such codes are
strongly discouraged except for experimental purposes, and should
not appear in publicly available software or files.
この仕様はいくつかの分野のいくつかだけの可能な値の意味を定義します。 例えば、圧縮方法0とフィルタタイプ0〜4だけが定義されます。 値の実験的であるか個人的な定義をこれらの分野のどれかに発明するとき、127以上の数を使用しなければなりません。 No.128はこの仕様の可能な今後の公共の拡大のために予約されます。 個人的なタイプコードの使用が標準のデコーダでファイルを読みにくく表すかもしれないことに注意してください。 そのようなコードは、実験目的以外に、強くがっかりしていて、公的に利用可能なソフトウェアかファイルに現れるべきではありません。
10. Recommendations for Decoders
10. デコーダのための推薦
This chapter gives some recommendations for decoder behavior. The only absolute requirement on a PNG decoder is that it successfully read any file conforming to the format specified in the preceding chapters. However, best results will usually be achieved by following these recommendations.
本章はデコーダの振舞いのためのいくつかの推薦を与えます。 PNGデコーダに関する唯一の絶対条件は首尾よくどんなファイルの従うことを先の章で指定された形式に読み込んだということです。 しかしながら、通常、最も良い結果は、これらの推薦に続くことによって、獲得されるでしょう。
10.1. Error checking
10.1. 誤りの照合
To ensure early detection of common file-transfer problems,
decoders should verify that all eight bytes of the PNG file
signature are correct. (See Rationale: PNG file signature,
Section 12.11.) A decoder can have additional confidence in the
file's integrity if the next eight bytes are an IHDR chunk header
with the correct chunk length.
一般的なファイル転送問題の早期発見を確実にするために、デコーダは、PNGファイル署名のすべての8バイトが適度であることを確かめるはずです。 (Rationaleを見てください: PNGファイル署名、セクション12.11) デコーダは次の8バイトが適度の塊の長さがあるIHDR塊ヘッダーであるならファイルの保全における追加信用を持つことができます。
Unknown chunk types must be handled as described in Chunk naming
conventions (Section 3.3). An unknown chunk type is not to be
treated as an error unless it is a critical chunk.
(セクション3.3)とコンベンションを命名するChunkで説明されるように未知の塊タイプを扱わなければなりません。 それがあらゆる重大でない塊であるなら未知の塊タイプを誤りとして扱ってはいけません。
It is strongly recommended that decoders should verify the CRC on
each chunk.
デコーダが各塊でCRCについて確かめるはずであることが強く勧められます。
In some situations it is desirable to check chunk headers (length
and type code) before reading the chunk data and CRC. The chunk
type can be checked for plausibility by seeing whether all four
bytes are ASCII letters (codes 65-90 and 97-122); note that this
need only be done for unrecognized type codes. If the total file
いくつかの状況で、塊のデータとCRCを読む前に塊ヘッダー(長さとタイプコード)をチェックするのは望ましいです。 すべての4バイトがASCII手紙(コード65-90と97-122)であるかどうかわかることによって、もっともらしさがないかどうか塊タイプをチェックできます。 認識されていないタイプコードのためにこの必要性をするだけであることに注意してください。 合計であるなら、ファイルしてください。
Boutell, et. al. Informational [Page 51] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[51ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
size is known (from file system information, HTTP protocol, etc),
the chunk length can be checked for plausibility as well.
サイズを知っていて(ファイルシステム情報、HTTPプロトコルなどから)、また、もっともらしさがないかどうか塊の長さをチェックできます。
If CRCs are not checked, dropped/added data bytes or an erroneous
chunk length can cause the decoder to get out of step and
misinterpret subsequent data as a chunk header. Verifying that
the chunk type contains letters is an inexpensive way of providing
early error detection in this situation.
CRCsがチェックされないなら、低下したか加えられたデータ・バイトか誤った塊の長さが、デコーダが塊ヘッダーとして調子外れになって、順次データを誤解することを引き起こす場合があります。 塊タイプが手紙を含むことを確かめるのは、早めの誤り検出をこの状況に提供する安価な方法です。
For known-length chunks such as IHDR, decoders should treat an
unexpected chunk length as an error. Future extensions to this
specification will not add new fields to existing chunks; instead,
new chunk types will be added to carry new information.
IHDRなどの知られている長さの塊のために、デコーダは予期していなかった塊の長さを誤りとして扱うはずです。 この仕様への今後の拡大は既存の塊に新しい分野を加えないでしょう。 代わりに、新しい塊タイプは、新情報を運ぶために加えられるでしょう。
Unexpected values in fields of known chunks (for example, an
unexpected compression method in the IHDR chunk) must be checked
for and treated as errors. However, it is recommended that
unexpected field values be treated as fatal errors only in
critical chunks. An unexpected value in an ancillary chunk can be
handled by ignoring the whole chunk as though it were an unknown
chunk type. (This recommendation assumes that the chunk's CRC has
been verified. In decoders that do not check CRCs, it is safer to
treat any unexpected value as indicating a corrupted file.)
知られている塊(例えば、IHDR塊における予期していなかった圧縮方法)の分野の予期していなかった値は、誤りとしてチェックで扱わなければなりません。 しかしながら、予期していなかった分野値が批判的な塊だけにおける致命的な誤りとして扱われるのは、お勧めです。 まるでそれが未知の塊タイプであるかのように全体の塊を無視することによって、付属の塊における予期していなかった値を扱うことができます。 (この推薦は、塊のCRCが確かめられたと仮定します。 CRCsをチェックしないデコーダでは、崩壊したファイルを示すとしてどんな予期していなかった値も扱うのは、より安全です。)
10.2. Pixel dimensions
10.2. 画素の重要性
Non-square pixels can be represented (see the pHYs chunk), but
viewers are not required to account for them; a viewer can present
any PNG file as though its pixels are square.
非正方形画素を表すことができますが(pHYs塊を見てください)、ビューアーは彼らの原因になるのに必要ではありません。 まるで画素が正方形であるかのようにビューアーはどんなPNGファイルも提示できます。
Conversely, viewers running on display hardware with non-square
pixels are strongly encouraged to rescale images for proper
display.
逆に、非正方形画素があるディスプレーされたハードウェアを動かしているビューアーが強く適切な表示のための「再-スケール」イメージに奨励されます。
10.3. Truecolor image handling
10.3. Truecolorイメージ取り扱い
To achieve PNG's goal of universal interchangeability, decoders
are required to accept all types of PNG image: indexed-color,
truecolor, and grayscale. Viewers running on indexed-color
display hardware need to be able to reduce truecolor images to
indexed format for viewing. This process is usually called "color
quantization".
PNGの普遍的な互換性の目標を達成するために、デコーダがすべてのタイプのPNGイメージを受け入れるのに必要です: 索引をつけられた色、truecolor、およびグレースケール。 索引をつけられたカラーディスプレイハードウェアで動いているビューアーは、見る索引をつけられた形式にtruecolorイメージを減らすことができる必要があります。 通常、この過程は「色の量子化」と呼ばれます。
Boutell, et. al. Informational [Page 52] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[52ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
A simple, fast way of doing this is to reduce the image to a fixed
palette. Palettes with uniform color spacing ("color cubes") are
usually used to minimize the per-pixel computation. For
photograph-like images, dithering is recommended to avoid ugly
contours in what should be smooth gradients; however, dithering
introduces graininess that can be objectionable.
これをする簡単で、速い方法は固定パレットにイメージを減らすことです。 通常、一定の色のスペース(「カラー立方体」)があるパレットは、1画素あたりの計算を最小にするのに使用されます。 写真のようなイメージに関しては、ディザリングが平坦な勾配であるべきであるところにおける醜い輪郭を避けることが勧められます。 しかしながら、ディザリングは好ましくない場合がある粒状性を導入します。
The quality of rendering can be improved substantially by using a
palette chosen specifically for the image, since a color cube
usually has numerous entries that are unused in any particular
image. This approach requires more work, first in choosing the
palette, and second in mapping individual pixels to the closest
available color. PNG allows the encoder to supply a suggested
palette in a PLTE chunk, but not all encoders will do so, and the
suggested palette may be unsuitable in any case (it may have too
many or too few colors). High-quality viewers will therefore need
to have a palette selection routine at hand. A large lookup table
is usually the most feasible way of mapping individual pixels to
palette entries with adequate speed.
特にイメージに選ばれたパレットを使用することによって、実質的に表現の品質を改良できます、カラー立方体にはどんな特定のイメージで未使用であることの頻繁なエントリーも通常あるので。 このアプローチは、より多くの仕事を必要とします、最も近い利用可能な色に個々の画素を写像する際に最初にパレット、および2番目を選ぶ際に。 すべてのエンコーダがそうするというわけではないでしょう、そして、PNGはエンコーダにPLTE塊で提案されたパレットを供給させますが、どのような場合でも、提案されたパレットは不適当であるかもしれません(それには、多く過ぎるかあまりにわずかな色しかないかもしれません)。 したがって、高品質なビューアーはパレット選択ルーチンを近く必要とするでしょう。 大きいルックアップ表は適切な速度で個々の画素をパレットエントリーに写像する通常最も可能な方法です。
Numerous implementations of color quantization are available. The
PNG reference implementation, libpng, includes code for the
purpose.
色の量子化の頻繁な実現は利用可能です。 PNG参照実現(libpng)は目的のためのコードを含んでいます。
10.4. Sample depth rescaling
10.4. サンプル深さ再スケーリング
Decoders may wish to scale PNG data to a lesser sample depth (data
precision) for display. For example, 16-bit data will need to be
reduced to 8-bit depth for use on most present-day display
hardware. Reduction of 8-bit data to 5-bit depth is also common.
デコーダは表示のために、より少ないサンプルの深さ(データ精度)にPNGデータについて合わせて調整したがっているかもしれません。 例えば、16ビットのデータは、最も現代の表示ハードウェアにおける使用のために8ビットの深さまで減少する必要があるでしょう。 また、5ビットの深さへの8ビットのデータの整理も一般的です。
The most accurate scaling is achieved by the linear equation
最も正確なスケーリングは一次方程式によって達成されます。
output = ROUND(input * MAXOUTSAMPLE / MAXINSAMPLE)
出力はROUNDと等しいです。(入力*MAXOUTSAMPLE / MAXINSAMPLE)
where
どこ
MAXINSAMPLE = (2^sampledepth)-1
MAXOUTSAMPLE = (2^desired_sampledepth)-1
MAXINSAMPLE=(2^sampledepth)-1MAXOUTSAMPLEは-1と等しいです(2^は_sampledepthを望んでいました)。
A slightly less accurate conversion is achieved by simply shifting
right by sampledepth-desired_sampledepth places. For example, to
reduce 16-bit samples to 8-bit, one need only discard the low-
order byte. In many situations the shift method is sufficiently
accurate for display purposes, and it is certainly much faster.
(But if gamma correction is being done, sample rescaling can be
merged into the gamma correction lookup table, as is illustrated
in Decoder gamma handling, Section 10.5.)
わずかに正確でない変換は、ちょうどsampledepthが必要な_sampledepth場所のそばで単に移行することによって、達成されます。 例えば、16ビットのサンプルを8ビットまで減らすために、1つは低オーダーバイトを捨てるだけでよいです。 多くの状況で、シフト方法は表示目的のために十分正確です、そして、確かに、それははるかに速いです。 (しかし、ガンマ修正が完了しているなら、そのままなガンマ補正ルックアップ表にサンプル再スケーリングをDecoderガンマ取り扱いでイラスト入りで合併できます、セクション10.5。)
Boutell, et. al. Informational [Page 53] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[53ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
When an sBIT chunk is present, the original pre-PNG data can be
recovered by shifting right to the sample depth specified by sBIT.
Note that linear scaling will not necessarily reproduce the
original data, because the encoder is not required to have used
linear scaling to scale the data up. However, the encoder is
required to have used a method that preserves the high-order bits,
so shifting always works. This is the only case in which shifting
might be said to be more accurate than linear scaling.
sBIT塊が存在しているとき、まさしくsBITによって指定されたサンプルの深さに移行することによって、オリジナルのプレPNGデータを回復できます。 直線的なスケーリングが必ずオリジナルのデータを再生させるというわけではないことに注意してください、エンコーダはデータを拡大するのに直線的なスケーリングを使用したのに必要でないので。 しかしながら、エンコーダが高位のビットを保存する方法を使用したのに必要であるので、移行はいつも働いています。 これは移行が直線的なスケーリングより正確であると言われているかもしれない唯一のそうです。
When comparing pixel values to tRNS chunk values to detect
transparent pixels, it is necessary to do the comparison exactly.
Therefore, transparent pixel detection must be done before
reducing sample precision.
見え透いた画素を検出するためにtRNS塊値にピクセル値をたとえるとき、まさに比較するのが必要です。 したがって、サンプルの精度を減少させる前に、わかりやすい画素検出をしなければなりません。
10.5. Decoder gamma handling
10.5. デコーダガンマ取り扱い
See Gamma Tutorial (Chapter 13) if you aren't already familiar
with gamma issues.
既にガンマ問題になじみ深くないなら、Gamma Tutorial(第13章)を見てください。
To produce correct tone reproduction, a good image display program
should take into account the gammas of the image file and the
display device, as well as the viewing_gamma appropriate to the
lighting conditions near the display. This can be done by
calculating
正しい階調再現を起こすために、良い画像表示プログラムはイメージ・ファイルとディスプレイ装置のガンマを考慮に入れるはずです、ほぼ表示で照明状態に適切な見る_ガンマと同様に。 計算することによって、これができます。
gbright = insample / MAXINSAMPLE
bright = gbright ^ (1.0 / file_gamma)
vbright = bright ^ viewing_gamma
gcvideo = vbright ^ (1.0 / display_gamma)
fbval = ROUND(gcvideo * MAXFBVAL)
insample / MAXINSAMPLE明るい=gbright^(1.0/ファイル_ガンマ)gbright=vbrightは_ガンマgcvideo=vbright^(1.0/表示_ガンマ)fbval=ROUNDを見る明るい^と等しいです。(gcvideo*MAXFBVAL)
where MAXINSAMPLE is the maximum sample value in the file (255 for
8-bit, 65535 for 16-bit, etc), MAXFBVAL is the maximum value of a
frame buffer sample (255 for 8-bit, 31 for 5-bit, etc), insample
is the value of the sample in the PNG file, and fbval is the value
to write into the frame buffer. The first line converts from
integer samples into a normalized 0 to 1 floating point value, the
second undoes the gamma encoding of the image file to produce a
linear intensity value, the third adjusts for the viewing
conditions, the fourth corrects for the display system's gamma
value, and the fifth converts to an integer frame buffer sample.
In practice, the second through fourth lines can be merged into
MAXINSAMPLEがファイル(8ビット255、16ビット65535など)の最大の標本値であるところでは、MAXFBVALはフレームバッファのサンプル(8ビット255、5ビット31など)の最大値です、そして、「不-サンプル」はPNGファイルのサンプルの値です、そして、fbvalはフレームバッファの中に書く値です。 0〜1つの正常にされた浮動小数点値への整数のサンプルからの最初の線転向者、2番目は直線的な強度値を生産するためにイメージ・ファイルのガンマコード化を元に戻して、3番目は見る状態のために適応して、4番目はディスプレイ・システムのガンマのために整数フレームバッファのサンプルに値、および5番目の転向者の誤りを正します。 実際には、2番目〜4番目の線に溶け込むことができます。
gcvideo = gbright^(viewing_gamma / (file_gamma*display_gamma))
gcvideoはgbright^と等しいです。(_ガンマ/(ファイル_ガンマ*表示_ガンマ)を見ます)
so as to perform only one power calculation. For color images, the
entire calculation is performed separately for R, G, and B values.
1つのパワー計算だけを実行してください。 カラーイメージにおいて、全体の計算はR、G、およびB値のために別々に実行されます。
Boutell, et. al. Informational [Page 54] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[54ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
It is not necessary to perform transcendental math for every
pixel. Instead, compute a lookup table that gives the correct
output value for every possible sample value. This requires only
256 calculations per image (for 8-bit accuracy), not one or three
calculations per pixel. For an indexed-color image, a one-time
correction of the palette is sufficient, unless the image uses
transparency and is being displayed against a nonuniform
background.
あらゆる画素のために先験的な数学を実行するのは必要ではありません。 代わりに、あらゆる可能な標本値のために正しい出力値を与えるルックアップ表を計算してください。 これは1画素あたり1か3つの計算ではなく、イメージ(8ビットの精度のための)あたり256の計算だけを必要とします。 索引をつけられたカラーイメージでは、パレットの1回の修正は十分です、イメージが透明を使用して、不均等なバックグラウンドに対して表示されていない場合。
In some cases even the cost of computing a gamma lookup table may
be a concern. In these cases, viewers are encouraged to have
precomputed gamma correction tables for file_gamma values of 1.0
and 0.5 with some reasonable choice of viewing_gamma and
display_gamma, and to use the table closest to the gamma indicated
in the file. This will produce acceptable results for the majority
of real files.
いくつかの場合、ガンマルックアップ表を計算する費用さえ関心であるかもしれません。 これらの場合では、ビューアーは、1.0と0.5のファイル_ガンマ値のために_ガンマと表示_ガンマを見ることの何らかの正当な選択でガンマ補正テーブルを前計算して、ファイルで示されたガンマの最も近くでテーブルを使用するよう奨励されます。 これは実際のファイルの大部分のために許容できる結果を生むでしょう。
When the incoming image has unknown gamma (no gAMA chunk), choose
a likely default file_gamma value, but allow the user to select a
new one if the result proves too dark or too light.
入って来るイメージに未知のガンマ(gAMA塊がない)があるときにはありそうなデフォルトファイル_ガンマ値を選びなさい、ただし、結果が暗過ぎるか、または軽過ぎると判明するなら、ユーザに新しいものを選択させてください。
In practice, it is often difficult to determine what value of
display_gamma should be used. In systems with no built-in gamma
correction, the display_gamma is determined entirely by the CRT.
Assuming a CRT_gamma of 2.5 is recommended, unless you have
detailed calibration measurements of this particular CRT
available.
実際には、表示_ガンマのどんな値が使用されるべきであるかを決定するのはしばしば難しいです。 内蔵のガンマ修正のないシステムでは、表示_ガンマは完全にCRTで決定します。 あなたが利用可能なこの特定のCRTの較正測定値を詳しく述べていないなら、2.5のCRT_ガンマを仮定するのはお勧めです。
However, many modern frame buffers have lookup tables that are
used to perform gamma correction, and on these systems the
display_gamma value should be the gamma of the lookup table and
CRT combined. You may not be able to find out what the lookup
table contains from within an image viewer application, so you may
have to ask the user what the system's gamma value is.
Unfortunately, different manufacturers use different ways of
specifying what should go into the lookup table, so interpretation
of the system gamma value is system-dependent. Gamma Tutorial
(Chapter 13) gives some examples.
しかしながら、多くの現代のフレームバッファがガンマ修正を実行するのに使用されるルックアップ表を持っています、そして、表示_ガンマ値はこれらのシステムの上では、結合されたルックアップ表とCRTのガンマであるべきです。 ルックアップ表が画像ビューワアプリケーションから何を含むかを見つけることができないかもしれないので、あなたは、システムのガンマ値が何であるかをユーザに尋ねなければならないかもしれません。 残念ながら、異なったメーカーがルックアップ表に入るべきであることを指定する異なった方法を使用するので、システムガンマ値の解釈はシステム依存しています。 ガンマTutorial(第13章)はいくつかの例を出します。
The response of real displays is actually more complex than can be
described by a single number (display_gamma). If actual
measurements of the monitor's light output as a function of
voltage input are available, the fourth and fifth lines of the
computation above can be replaced by a lookup in these
measurements, to find the actual frame buffer value that most
nearly gives the desired brightness.
本当の表示の応答は実際に1つの数(表示_ガンマ)で説明できるより複雑です。 電圧入力の機能としてのモニターの光熱出力の実測が利用可能であるなら、大部分がほとんど与える実際のフレーム緩衝値に必要な明るさを見つけるために上の計算の4番目と5番目の線をこれらの測定値のルックアップに取り替えることができます。
Boutell, et. al. Informational [Page 55] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[55ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
The value of viewing_gamma depends on lighting conditions; see
Gamma Tutorial (Chapter 13) for more detail. Ideally, a viewer
would allow the user to specify viewing_gamma, either directly
numerically, or via selecting from "bright surround", "dim
surround", and "dark surround" conditions. Viewers that don't
want to do this should just assume a value for viewing_gamma of
1.0, since most computer displays live in brightly-lit rooms.
見る_ガンマの値を照明条件に依存します。 その他の詳細に関してGamma Tutorial(第13章)を見てください。 理想的に、ビューアーは、数の上でか直接「明るい取り囲むもの」、「薄暗い取り囲むもの」、および「暗い取り囲むもの」状態から選び抜くことを通して_ガンマを見ながら、ユーザを指定させるでしょう。 これをしたがっていないビューアーは_1.0のガンマを見るためにただ値を仮定するべきです、ほとんどのコンピュータのディスプレイが明るく点灯された部屋に住んでいるので。
When viewing images that are digitized from video, or that are
destined to become video frames, the user might want to set the
viewing_gamma to about 1.25 regardless of the actual level of room
lighting. This value of viewing_gamma is "built into" NTSC video
practice, and displaying an image with that viewing_gamma allows
the user to see what a TV set would show under the current room
lighting conditions. (This is not the same thing as trying to
obtain the most accurate rendition of the content of the scene,
which would require adjusting viewing_gamma to correspond to the
room lighting level.) This is another reason viewers might want
to allow users to adjust viewing_gamma directly.
ビデオからデジタル化されるか、またはビデオフレームになるように運命づけられているイメージを見るとき、ユーザは、実際のレベルの余地にかかわらずおよそ1.25への見る_ガンマが火が付くように設定したがっているかもしれません。 NTSCビデオ習慣は見る_ガンマのこの値に「組み込まれます」、そして、それが_ガンマを見ているイメージを表示するのはユーザがテレビが現在の余地の照明条件のもとで示しているものを見るのを許容します。 (これは余地の照明レベルに相当するように_ガンマを見ながら適応するのを必要とするだろう場面の内容の最も正確な表現を得ようとするのと同じものではありません。) これはビューアーが、直接_ガンマを見ながらユーザが適応するのを許したがっているかもしれない別の理由です。
10.6. Decoder color handling
10.6. デコーダ色の取り扱い
See Color Tutorial (Chapter 14) if you aren't already familiar
with color issues.
既に色の問題になじみ深くないなら、Color Tutorial(第14章)を見てください。
In many cases, decoders will treat image data in PNG files as
device-dependent RGB data and display it without modification
(except for appropriate gamma correction). This provides the
fastest display of PNG images. But unless the viewer uses exactly
the same display hardware as the original image author used, the
colors will not be exactly the same as the original author saw,
particularly for darker or near-neutral colors. The cHRM chunk
provides information that allows closer color matching than that
provided by gamma correction alone.
多くの場合、デコーダは、装置依存するRGBデータとしてPNGファイルのイメージデータを扱って、変更(適切なガンマ修正を除いた)なしでそれを表示するでしょう。 これはPNGイメージの最も速い表示を提供します。 しかし、ビューアーがオリジナルのイメージ作者としてのハードウェアが使用したまさに同じ表示を使用しない場合、色はまさに原作者が見たのと同じにならないでしょう、特により暗いか中立の色のために。 cHRM塊はガンマ修正で単独で提供されたそれより厳密な色のマッチングを許す情報を提供します。
Decoders can use the cHRM data to transform the image data from
RGB to XYZ and thence into a perceptually linear color space such
as CIE LAB. They can then partition the colors to generate an
optimal palette, because the geometric distance between two colors
in CIE LAB is strongly related to how different those colors
appear (unlike, for example, RGB or XYZ spaces). The resulting
palette of colors, once transformed back into RGB color space,
could be used for display or written into a PLTE chunk.
デコーダは、イメージデータをRGBからXYZまでそこからCIE LABなどの知覚のに直線的な色のスペースの中に変えるのにcHRMデータを使用できます。 次に、彼らは最適のパレットを発生させるように色を仕切ることができます、CIE LABの2つの色の間の幾何学上距離が強くそれらの色がどれくらい異なるように見えるかと(例えば、RGBかXYZ空間と異なって)関係づけられるので。 一度RGB色のスペースに変えて戻された色の結果として起こるパレットを表示に使用したか、またはPLTE塊に書くことができました。
Decoders that are part of image processing applications might also
transform image data into CIE LAB space for analysis.
また、イメージプロセッシングアプリケーションの一部であるデコーダは分析のためにイメージデータをCIE LABスペースに変えるかもしれません。
Boutell, et. al. Informational [Page 56] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[56ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
In applications where color fidelity is critical, such as product
design, scientific visualization, medicine, architecture, or
advertising, decoders can transform the image data from source_RGB
to the display_RGB space of the monitor used to view the image.
This involves calculating the matrix to go from source_RGB to XYZ
and the matrix to go from XYZ to display_RGB, then combining them
to produce the overall transformation. The decoder is responsible
for implementing gamut mapping.
色の信義が批判的であるプロダクトデザイン、サイエンティフィック・ビジュアライゼーション、薬、構造、または広告などの応用では、デコーダはイメージデータをソース_RGBからイメージを見るのに使用されるモニターの表示_RGBスペースに変えることができます。 これは、_RGBを表示しにXYZから行きにソース_RGBからXYZとマトリクスまで行くためにマトリクスを計算することを伴います、次に、総合的な変化を起こすためにそれらを結合して。 デコーダは全域マッピングを実行するのに原因となります。
Decoders running on platforms that have a Color Management System
(CMS) can pass the image data, gAMA and cHRM values to the CMS for
display or further processing.
Color Management System(CMS)を持っているプラットホームで走るデコーダは表示かさらなる処理のためにイメージデータ、gAMA、およびcHRM値をCMSに渡すことができます。
Decoders that provide color printing facilities can use the
facilities in Level 2 PostScript to specify image data in
calibrated RGB space or in a device-independent color space such
as XYZ. This will provide better color fidelity than a simple RGB
to CMYK conversion. The PostScript Language Reference manual
gives examples of this process [POSTSCRIPT]. Such decoders are
responsible for implementing gamut mapping between source_RGB
(specified in the cHRM chunk) and the target printer. The
PostScript interpreter is then responsible for producing the
required colors.
カラー印刷施設を提供するデコーダは、較正されたRGBスペースかXYZなどの装置から独立している色のスペースでイメージデータを指定するのにLevel2ポストスクリプトに施設を使用できます。 これは簡単なRGBより良い色の信義をCMYK変換に提供するでしょう。 ポストスクリプトLanguage Referenceマニュアルはこの過程[POSTSCRIPT]に関する例を出します。 そのようなデコーダはソース_RGB(cHRM塊では、指定される)と目標プリンタの間の全域マッピングを実行するのに原因となります。 ポストスクリプトインタプリタはその時、必要な色を発生させるのに責任があります。
Decoders can use the cHRM data to calculate an accurate grayscale
representation of a color image. Conversion from RGB to gray is
simply a case of calculating the Y (luminance) component of XYZ,
which is a weighted sum of the R G and B values. The weights
depend on the monitor type, i.e., the values in the cHRM chunk.
Decoders may wish to do this for PNG files with no cHRM chunk. In
that case, a reasonable default would be the CCIR 709 primaries
[ITU-BT709]. Do not use the original NTSC primaries, unless you
really do have an image color-balanced for such a monitor. Few
monitors ever used the NTSC primaries, so such images are probably
nonexistent these days.
デコーダは、カラーイメージの正確なグレースケール表現について計算するのにcHRMデータを使用できます。 RGBからグレーまでの変換は単にR GとB値の荷重している合計であるXYZのY(輝度)の部品について計算するケースです。 重りはすなわち、モニタータイプ、cHRM塊における値に依存します。 デコーダはPNGファイルのためにcHRM塊なしでこれをしたがっているかもしれません。 その場合、合理的なデフォルトはCCIR709予備選挙[ITU-BT709]でしょう。 そのようなモニターにおいて、色でバランスのとれているイメージが本当にないなら、オリジナルのNTSC予備選挙を使用しないでください。 わずかなモニターしか今までにNTSC予備選挙を使用しなかったので、そのようなイメージは最近、たぶん実在しません。
10.7. Background color
10.7. 背景色
The background color given by bKGD will typically be used to fill
unused screen space around the image, as well as any transparent
pixels within the image. (Thus, bKGD is valid and useful even
when the image does not use transparency.) If no bKGD chunk is
present, the viewer will need to make its own decision about a
suitable background color.
bKGDによって与えられた背景色はイメージの周りに未使用のスクリーンスペースをいっぱいにするのに通常使用されるでしょう、イメージの中のどんな見え透いた画素と同様に。 (イメージが透明を使用さえしないとき、その結果、bKGDは有効であって、役に立ちます。) どんなbKGD塊も存在していないと、ビューアーは、適当な背景色に関するそれ自身の決定をする必要があるでしょう。
Boutell, et. al. Informational [Page 57] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[57ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
Viewers that have a specific background against which to present
the image (such as Web browsers) should ignore the bKGD chunk, in
effect overriding bKGD with their preferred background color or
background image.
イメージ(ウェブブラウザなどの)を提示する特定のバックグラウンドを持っているビューアーはbKGD塊を無視するべきです、事実上、彼らの都合のよい背景色か背景画像でbKGDをくつがえして。
The background color given by bKGD is not to be considered
transparent, even if it happens to match the color given by tRNS
(or, in the case of an indexed-color image, refers to a palette
index that is marked as transparent by tRNS). Otherwise one would
have to imagine something "behind the background" to composite
against. The background color is either used as background or
ignored; it is not an intermediate layer between the PNG image and
some other background.
bKGDによって与えられた背景色は透明であることは考えられないことです、tRNS(または、索引をつけられたカラーイメージの場合では、透明であるとtRNSによってマークされるパレットインデックスを参照する)によって与えられた色を合わせるのが起こっても。 さもなければ、人は、何かが合成する「バックグラウンド」であると想像しなければならないでしょう。 背景色は、バックグラウンドとして使用されるか、または無視されます。 それはPNGイメージとある他のバックグラウンドの間の中間層ではありません。
Indeed, it will be common that bKGD and tRNS specify the same
color, since then a decoder that does not implement transparency
processing will give the intended display, at least when no
partially-transparent pixels are present.
本当に、部分的に見え透いていない画素が存在しているとき、bKGDとtRNSが同じ色を指定して、それ以来透明処理を実行しないデコーダが意図している表示を与えるのは少なくとも一般的になるでしょう。
10.8. Alpha channel processing
10.8. アルファチャンネル処理
In the most general case, the alpha channel can be used to
composite a foreground image against a background image; the PNG
file defines the foreground image and the transparency mask, but
not the background image. Decoders are not required to support
this most general case. It is expected that most will be able to
support compositing against a single background color, however.
最も一般的な場合では、背景画像に対してフォアグラウンド画像を合成するのにアルファチャンネルを使用できます。 PNGファイルは背景画像ではなく、フォアグラウンド画像と透明マスクを定義します。 デコーダは、この最も一般的なケースを支えるのに必要ではありません。 しかしながら、大部分が、ただ一つの背景色に対して合成するのを支持できると予想されます。
The equation for computing a composited sample value is
複合試料値を計算するための方程式はそうです。
output = alpha * foreground + (1-alpha) * background
出力は+ (1アルファ)のアルファ*フォアグランド*バックグラウンドと等しいです。
where alpha and the input and output sample values are expressed
as fractions in the range 0 to 1. This computation should be
performed with linear (non-gamma-encoded) sample values. For
color images, the computation is done separately for R, G, and B
samples.
範囲のアルファと入出力標本値が断片として0〜1に表されるところ。 この計算は直線的な(コード化された非ガンマ)標本値で実行されるべきです。 カラーイメージにおいて、R、G、およびBのサンプルのために別々に計算します。
The following code illustrates the general case of compositing a
foreground image over a background image. It assumes that you
have the original pixel data available for the background image,
and that output is to a frame buffer for display. Other variants
are possible; see the comments below the code. The code allows
the sample depths and gamma values of foreground image, background
image, and frame buffer/CRT all to be different. Don't assume
they are the same without checking.
以下のコードは背景画像の上にフォアグラウンド画像を合成する一般的なケースを例証します。 それはあなたには背景画像に利用可能なオリジナルのピクセルデータがあって、表示のためのフレームバッファには出力があると仮定します。 他の異形は可能です。 コードの下でコメントを見てください。 コードは、異なるようにフォアグラウンド画像、背景画像の深層とガンマ値をサンプルに許容して、フレームバッファ/CRTにすべてを許容します。 チェックすると仮定しないでください。それらが同じである
Boutell, et. al. Informational [Page 58] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[58ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
This code is standard C, with line numbers added for reference in
the comments below.
このコードは行番号が以下でのコメントにおける参照のために加えられている規格Cです。
01 int foreground[4]; /* image pixel: R, G, B, A */
02 int background[3]; /* background pixel: R, G, B */
03 int fbpix[3]; /* frame buffer pixel */
04 int fg_maxsample; /* foreground max sample */
05 int bg_maxsample; /* background max sample */
06 int fb_maxsample; /* frame buffer max sample */
07 int ialpha;
08 float alpha, compalpha;
09 float gamfg, linfg, gambg, linbg, comppix, gcvideo;
01 intフォアグランド[4]。 /*イメージ画素: R、G、B、A*/02intバックグラウンド[3]。 /*バックグラウンド画素: R、G、B*/03int fbpix[3]。 /*フレームバッファ画素*/04int fg_maxsample。 /*フォアグランド最大のサンプル*/05int bg_maxsample。 /*バックグラウンド最大のサンプル*/06int fb_maxsample。 /*フレームバッファ最大のサンプル*/07int ialpha。 08 アルファ、compalphaを浮かべてください。 09 gamfg、linfg、gambg、linbg、comppix、gcvideoを浮かべてください。
/* Get max sample values in data and frame buffer */
10 fg_maxsample = (1 << fg_sample_depth) - 1;
11 bg_maxsample = (1 << bg_sample_depth) - 1;
12 fb_maxsample = (1 << frame_buffer_sample_depth) - 1;
/*
* Get integer version of alpha.
* Check for opaque and transparent special cases;
* no compositing needed if so.
*
* We show the whole gamma decode/correct process in
* floating point, but it would more likely be done
* with lookup tables.
*/
13 ialpha = foreground[3];
フレームバッファ*/10fg_maxsampleは(1つの<<fg_サンプル_の深さ)と等しいです--/*はデータの最大標本値を得ます、そして、1 11 bg_maxsampleは(1つの<<bg_サンプル_の深さ)と等しいです--1 12 fb_maxsampleは(1つの<<フレーム_バッファ_のサンプル_深さ)と等しいです--1 /**はアルファの整数バージョンを得ます。 * 不透明で見え透いた特別なケースがないかどうかチェックしてください。 * そうだとすれば、必要であることで、合成しません。 * * 私たちは、全体のガンマが*浮動小数点の過程を解読するか、または修正するのを示しますが、おそらく、ルックアップ表がある*をそれにするでしょう。 */13ialphaはフォアグランド[3]と等しいです。
14 if (ialpha == 0) {
/*
* Foreground image is transparent here.
* If the background image is already in the frame
* buffer, there is nothing to do.
*/
15 ;
16 } else if (ialpha == fg_maxsample) {
/*
* Copy foreground pixel to frame buffer.
*/
17 for (i = 0; i < 3; i++) {
18 gamfg = (float) foreground[i] / fg_maxsample;
19 linfg = pow(gamfg, 1.0/fg_gamma);
20 comppix = linfg;
21 gcvideo = pow(comppix,viewing_gamma/display_gamma);
22 fbpix[i] = (int) (gcvideo * fb_maxsample + 0.5);
23 }
14、(ialpha=0)です。{ /**フォアグラウンド画像はここで見え透いています。 * 背景画像がフレーム*バッファに既にあるなら、何もすることがありません。 */ 15 ; 16 } ほかにもかかわらず、(ialpha=fg_maxsample)、フレームバッファ(i=0; i<3; i++)のための*/17への/**コピーフォアグランド画素{18gamfgは_フォアグランド[i]/fg maxsampleと等しいです(浮かべます); 19linfg=pow(gamfg、1.0/fg_ガンマ); 20comppix=linfg; 21gcvideo=pow(_ガンマ/表示_ガンマを見るcomppix); 22fbpix[i]=(int)(gcvideo*fb_maxsample+0.5); 23}
Boutell, et. al. Informational [Page 59] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[59ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
24 } else {
/*
* Compositing is necessary.
* Get floating-point alpha and its complement.
* Note: alpha is always linear; gamma does not
* affect it.
*/
25 alpha = (float) ialpha / fg_maxsample;
26 compalpha = 1.0 - alpha;
27 for (i = 0; i < 3; i++) {
/*
* Convert foreground and background to floating
* point, then linearize (undo gamma encoding).
*/
28 gamfg = (float) foreground[i] / fg_maxsample;
29 linfg = pow(gamfg, 1.0/fg_gamma);
30 gambg = (float) background[i] / bg_maxsample;
31 linbg = pow(gambg, 1.0/bg_gamma);
/*
* Composite.
*/
32 comppix = linfg * alpha + linbg * compalpha;
/*
* Gamma correct for display.
* Convert to integer frame buffer pixel.
*/
33 gcvideo = pow(comppix,viewing_gamma/display_gamma);
34 fbpix[i] = (int) (gcvideo * fb_maxsample + 0.5);
35 }
36 }
24、ほか{ /**合成が必要です。 * 浮動小数点のアルファと1の補数を得てください。 * 以下に注意してください。 アルファはいつも直線的です。 ガンマは影響しません。*それに影響してください。 */25アルファはialpha / fg_maxsampleと等しいです(浮かべます)。 26 compalphaは1.0--アルファと等しいです。 27、(i=0。 i<3。 i++)、浮揚式の*への/**転向者フォアグランドとバックグラウンドは、指して、次に、linearizeされます(ガンマコード化を元に戻してください)。 */28gamfgは_フォアグランド[i]/fg maxsampleと等しいです(浮かべます)。 29 linfgはpow(gamfg、1.0/fg_ガンマ)と等しいです。 30 gambgは_バックグラウンド[i]/bg maxsampleと等しいです(浮かべます)。 31 linbgはpow(gambg、1.0/bg_ガンマ)と等しいです。 /**合成物。 */32comppix=linfg*アルファ+linbg*compalpha。 表示に、正しい/**ガンマ。 * 整数フレームバッファ画素に変えてください。 */33gcvideoはpow(_ガンマ/表示_ガンマを見るcomppix)と等しいです。 34 fbpix[i]は(int)(gcvideo*fb_maxsample+0.5)と等しいです。 35 } 36 }
Variations:
変化:
* If output is to another PNG image file instead of a frame
buffer, lines 21, 22, 33, and 34 should be changed to be
something like
* フレームバッファの代わりにイメージ・ファイル、線21、22、33、および34があるように変わるべきである別のPNGに出力があるなら
/*
* Gamma encode for storage in output file.
* Convert to integer sample value.
*/
gamout = pow(comppix, outfile_gamma);
outpix[i] = (int) (gamout * out_maxsample + 0.5);
出力ファイルにおける格納への/**ガンマエンコード。 * 整数標本値に変えてください。 */gamoutはpow(comppix、出力ファイル_ガンマ)と等しいです。 outpix[i]は(int)(_maxsample+0.5からのgamout*)と等しいです。
Also, it becomes necessary to process background pixels when
alpha is zero, rather than just skipping pixels. Thus, line
15 will need to be replaced by copies of lines 17-23, but
processing background instead of foreground pixel values.
また、アルファがただ画素をスキップするよりむしろゼロであることのバックグラウンド画素を処理するのは必要になります。 したがって、線15は、線17-23のコピーに取り替えますが、フォアグランドピクセル値の代わりにバックグラウンドを処理する必要があるでしょう。
Boutell, et. al. Informational [Page 60] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[60ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
* If the sample depths of the output file, foreground file,
and background file are all the same, and the three gamma
values also match, then the no-compositing code in lines
14-23 reduces to nothing more than copying pixel values from
the input file to the output file if alpha is one, or
copying pixel values from background to output file if alpha
is zero. Since alpha is typically either zero or one for
the vast majority of pixels in an image, this is a great
savings. No gamma computations are needed for most pixels.
* When the sample depths and gamma values all match, it may
appear attractive to skip the gamma decoding and encoding
(lines 28-31, 33-34) and just perform line 32 using gamma-
encoded sample values. Although this doesn't hurt image
quality too badly, the time savings are small if alpha
values of zero and one are special-cased as recommended
here.
* If the original pixel values of the background image are no
longer available, only processed frame buffer pixels left by
display of the background image, then lines 30 and 31 need
to extract intensity from the frame buffer pixel values
using code like
* 出力ファイル、フォアグランドファイル、およびバックグラウンドの深層がファイルするサンプルがちょうど同じであり、また、3つのガンマ値が合っているなら、線14-23における合成していないコードはアルファが1であるならピクセル値をただ入力ファイルから出力ファイルまでコピーするか、またはアルファがゼロであるならバックグラウンドから出力ファイルまでピクセル値をコピーするのに減少します。 アルファが通常イメージによる画素のかなりの大部分のゼロかひとりのどちらかであるので、これはすばらしい貯蓄です。 ガンマ計算は全くほとんどの画素に必要ではありません。 * サンプルであるときに、深層とガンマ値はすべて合って、それは(線28-31、33-34)を解読して、コード化するガンマをスキップして、ガンマのコード化された標本値を使用することで線32をただ実行するために魅力的に見えるかもしれません。 これはあまりひどく画質に害を与えませんが、ゼロと1の文字値がここで推薦されるように特別にケースに入れられるなら、定期貯金はわずかです。 * 背景画像の元のピクセル値がもう利用可能でなく、処理フレームバッファ画素だけが背景画像の表示でいなくなって、次に、30を裏打ちして、31が、画素が使用コードを評価するフレームバッファから強度を抽出する必要があるなら
/*
* Decode frame buffer value back into linear space.
*/
gcvideo = (float) fbpix[i] / fb_maxsample;
linbg = pow(gcvideo, display_gamma / viewing_gamma);
/**はフレーム緩衝値を直線的なスペースに解読して戻します。 */gcvideoはfbpix[i] / fb_maxsampleと等しいです(浮かべます)。 linbgはpow(gcvideo、表示_ガンマ/見る_ガンマ)と等しいです。
However, some roundoff error can result, so it is better to
have the original background pixels available if at all
possible.
* Note that lines 18-22 are performing exactly the same gamma
computation that is done when no alpha channel is present.
So, if you handle the no-alpha case with a lookup table, you
can use the same lookup table here. Lines 28-31 and 33-34
can also be done with (different) lookup tables.
* Of course, everything here can be done in integer
arithmetic. Just be careful to maintain sufficient
precision all the way through.
しかしながら、何らかのロンダード誤りが結果として生じることができるので、できれば、有効な元のバックグラウンド画素を持っているほうがよいです。 * 線18-22がまさにどんなアルファチャンネルも出席していないとき行われるのと同じガンマ計算を実行していることに注意してください。 それで、ルックアップ表でアルファがないケースを扱うなら、あなたはここで同じルックアップ表を使用できます。 また(異なる)のルックアップ表で28-31と33-34をできる線。 * もちろん、整数演算でここのすべてができます。 通じて十分な精度をいっぱいに維持するようにただ注意してください。
Note: in floating point, no overflow or underflow checks are
needed, because the input sample values are guaranteed to be
between 0 and 1, and compositing always yields a result that is in
between the input values (inclusive). With integer arithmetic,
some roundoff-error analysis might be needed to guarantee no
overflow or underflow.
以下に注意してください。 浮動小数点、オーバーフローまたはどんなアンダーフローチェックでも、入力標本値が0〜1になるように保証されるので必要であり、いつも利回りを合成するのは、入力値(包括的な)の間にある結果ではありません。 整数演算で、何らかのロンダードエラー解析が、どんなオーバーフローもアンダーフローも保証しないように必要であるかもしれません。
Boutell, et. al. Informational [Page 61] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[61ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
When displaying a PNG image with full alpha channel, it is
important to be able to composite the image against some
background, even if it's only black. Ignoring the alpha channel
will cause PNG images that have been converted from an
associated-alpha representation to look wrong. (Of course, if the
alpha channel is a separate transparency mask, then ignoring alpha
is a useful option: it allows the hidden parts of the image to be
recovered.)
完全なアルファチャンネルでPNGイメージを表示するとき、何らかのバックグラウンドに対してイメージを合成できるのは重要です、それが黒いだけであっても。 アルファチャンネルを無視すると、関連アルファ表現から変換されたPNGイメージは間違っているように見えるでしょう。 (もちろん、アルファチャンネルが別々の透明マスクであるなら、次に、アルファを無視するのは、役に立つオプションです: それで、イメージの被蓋部は回復します。)
Even if the decoder author does not wish to implement true
compositing logic, it is simple to deal with images that contain
only zero and one alpha values. (This is implicitly true for
grayscale and truecolor PNG files that use a tRNS chunk; for
indexed-color PNG files, it is easy to check whether tRNS contains
any values other than 0 and 255.) In this simple case,
transparent pixels are replaced by the background color, while
others are unchanged. If a decoder contains only this much
transparency capability, it should deal with a full alpha channel
by treating all nonzero alpha values as fully opaque; that is, do
not replace partially transparent pixels by the background. This
approach will not yield very good results for images converted
from associated-alpha formats, but it's better than doing nothing.
デコーダ作者が正しい合成論理を実行したくなくてもさえ、ゼロと1つの文字値だけを含むイメージに対処するのは簡単です。 (tRNS塊を使用するグレースケールとtruecolor PNGファイルには、これがそれとなく本当です; 索引をつけられたカラーPNGファイルに関して、tRNSが何か0と255以外の値を含むかどうかチェックするのが簡単です。) この簡単な場合では、見え透いた画素を背景色に取り替えますが、他のものは変わりがありません。 デコーダがこれだけの透明能力だけを含んでいるなら、文字値が同じくらい完全に不透明にするすべての非零を扱うことによって、完全なアルファチャンネルに対処するべきです。 すなわち、部分的に見え透いた画素をバックグラウンドに取り替えないでください。 このアプローチが関連文字の書式から変換されたイメージのための非常に良い結果をもたらしませんが、それは何もしないより良いです。
10.9. Progressive display
10.9. 進歩的な表示
When receiving images over slow transmission links, decoders can
improve perceived performance by displaying interlaced images
progressively. This means that as each pass is received, an
approximation to the complete image is displayed based on the data
received so far. One simple yet pleasing effect can be obtained
by expanding each received pixel to fill a rectangle covering the
yet-to-be-transmitted pixel positions below and to the right of
the received pixel. This process can be described by the
following pseudocode:
遅いトランスミッションリンクの上にイメージを受け取るとき、デコーダは次第に交錯しているイメージを表示するのによる知覚された性能を向上させることができます。 これは、それぞれのパスが受け取られているとき完全なイメージへの近似が今までのところ受け取られているデータに基づいて表示されることを意味します。 それぞれの容認された画素単位で長方形覆いをいっぱいにするために広がることによって1つの簡単な、しかし、微笑ましい効果を得ることができる、まだ未来、伝える、右と容認された画素の右への画素位置。 以下の擬似コードはこの過程について説明できます:
Starting_Row [1..7] = { 0, 0, 4, 0, 2, 0, 1 }
Starting_Col [1..7] = { 0, 4, 0, 2, 0, 1, 0 }
Row_Increment [1..7] = { 8, 8, 8, 4, 4, 2, 2 }
Col_Increment [1..7] = { 8, 8, 4, 4, 2, 2, 1 }
Block_Height [1..7] = { 8, 8, 4, 4, 2, 2, 1 }
Block_Width [1..7] = { 8, 4, 4, 2, 2, 1, 1 }
_0、0、4、0、2、0、_通り[1 .7]=1を始めて、_8、8、4、4、2、2、8、8、8、4、4、2、2あん部_0、4、0、2、0、1、0通り_増分[1 .7]=増分[1 .7]=1が妨げるあん部[1 .7]=を始めて、高さ[1 .7]の=8、8、4、4、2、2、1は_幅[1 .7]の=を妨げます。{ 8, 4, 4, 2, 2, 1, 1 }
pass := 1
while pass <= 7
begin
row := Starting_Row[pass]
_通りを始めて、パス<=7が列の:=を始めている間、:=1を渡してください。[パス]
while row < height
<の高さをこいでくださいという間
Boutell, et. al. Informational [Page 62] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[62ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
begin
col := Starting_Col[pass]
あん部:=始め_Colを始めてください。[パス]
while col < width
begin
visit (row, col,
min (Block_Height[pass], height - row),
min (Block_Width[pass], width - col))
col := col + Col_Increment[pass]
end
row := row + Row_Increment[pass]
end
あん部<幅である間、訪問(列、あん部、分(_Heightを妨げてください[通ってください]、高さ--船をこぐ)、分(ブロック_Width[通る]、幅--あん部))あん部:=あん部+あん部_Increment[通る]端の列の:=列+通りの_Increment[通る]エンドを始めてください。
pass := pass + 1
end
パス:=パス+1エンド
Here, the function "visit(row,column,height,width)" obtains the
next transmitted pixel and paints a rectangle of the specified
height and width, whose upper-left corner is at the specified row
and column, using the color indicated by the pixel. Note that row
and column are measured from 0,0 at the upper left corner.
ここに、機能は、次の伝えられた画素を入手して、指定された列とコラムには左上隅がある指定された高さと幅の長方形を塗装して、画素によって示された色を使用することで「訪問(列、コラム、高さ、幅)にされます」。 列とコラムが0、左上隅の0から測定されることに注意してください。
If the decoder is merging the received image with a background
image, it may be more convenient just to paint the received pixel
positions; that is, the "visit()" function sets only the pixel at
the specified row and column, not the whole rectangle. This
produces a "fade-in" effect as the new image gradually replaces
the old. An advantage of this approach is that proper alpha or
transparency processing can be done as each pixel is replaced.
Painting a rectangle as described above will overwrite
background-image pixels that may be needed later, if the pixels
eventually received for those positions turn out to be wholly or
partially transparent. Of course, this is only a problem if the
background image is not stored anywhere offscreen.
デコーダが受信されたイメージを背景画像に合併しているなら、まさしく容認された画素が置く塗料により便利であるかもしれません。 すなわち、「訪問()」機能は全体の長方形ではなく、指定された列とコラムで画素だけを設定します。 新しいイメージが徐々に老人を取り替えるとき、これは「フェードイン」効果を生みます。 このアプローチの利点はその適切なアルファであるか各画素を取り替えるとき、透明処理ができます。 上で説明されるように長方形を塗装すると、結局それらの位置に受け取られた画素が完全にである部分的に判明するなら後で必要であるかもしれない背景画像画素は透明な状態で上書きされるでしょう。 もちろん、背景画像が何処にも格納されない場合にだけ、これは問題です。画面外。
10.10. Suggested-palette and histogram usage
10.10. 提案されたパレットとヒストグラム用法
In truecolor PNG files, the encoder may have provided a suggested
PLTE chunk for use by viewers running on indexed-color hardware.
truecolor PNGファイルでは、エンコーダが索引をつけられたカラーハードウェアで動いているビューアーによる使用に提案されたPLTE塊を提供したかもしれません。
If the image has a tRNS chunk, the viewer will need to adapt the
suggested palette for use with its desired background color. To
do this, replace the palette entry closest to the tRNS color with
the desired background color; or just add a palette entry for the
background color, if the viewer can handle more colors than there
are PLTE entries.
イメージにtRNS塊があると、ビューアーは、必要な背景色で使用のための提案されたパレットを適合させる必要があるでしょう。 これをするには、必要な背景色でパレットエントリーをtRNS色の最も近くに取り替えてください。 または、ただ背景色のためのパレットエントリーを加えてください、ビューアーがPLTEエントリーがあるより多くの色を扱うことができるなら。
Boutell, et. al. Informational [Page 63] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[63ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
For images of color type 6 (truecolor with alpha channel), any
suggested palette should have been designed for display of the
image against a uniform background of the color specified by bKGD.
Viewers should probably ignore the palette if they intend to use a
different background, or if the bKGD chunk is missing. Viewers
can use a suggested palette for display against a different
background than it was intended for, but the results may not be
very good.
カラータイプ6(アルファチャンネルがあるtruecolor)のイメージに関しては、どんな提案されたパレットもイメージの表示のためにbKGDによって指定された色の一定のバックグラウンドに対して設計されるべきでした。 彼らが異なったバックグラウンドを使用するつもりであるか、またはbKGD塊がなくなるなら、ビューアーはたぶんパレットを無視するべきです。 ビューアーは表示に意図したのと異なったバックグラウンドに対して提案されたパレットを使用できますが、結果はそれほど良くないかもしれません。
If the viewer presents a transparent truecolor image against a
background that is more complex than a single color, it is
unlikely that the suggested palette will be optimal for the
composite image. In this case it is best to perform a truecolor
compositing step on the truecolor PNG image and background image,
then color-quantize the resulting image.
ビューアーがただ一つの色より複雑なバックグラウンドに対して見え透いたtruecolorイメージを提示するなら、提案されたパレットが合成画像に最適になるのは、ありそうもないです。 この場合、truecolor PNGイメージと背景画像にtruecolorの合成ステップを実行して、次に、結果として起こるイメージを色で量子化するのは最も良いです。
The histogram chunk is useful when the viewer cannot provide as
many colors as are used in the image's palette. If the viewer is
only short a few colors, it is usually adequate to drop the
least-used colors from the palette. To reduce the number of
colors substantially, it's best to choose entirely new
representative colors, rather than trying to use a subset of the
existing palette. This amounts to performing a new color
quantization step; however, the existing palette and histogram can
be used as the input data, thus avoiding a scan of the image data.
ビューアーがイメージのパレットで使用されるのと同じくらい多くの色を提供できないとき、ヒストグラム塊は役に立ちます。 ビューアーが背が低いだけであるなら、いくつかは着色して、通常、パレットから最も最少に使用された色を落とすのは適切です。 色数を減少させるために、実質的に、既存のパレットの部分集合を使用しようとするよりむしろ完全に新しい代表している色を選ぶのは最も良いです。 これは、新しい色の量子化ステップを実行するのに達します。 しかしながら、入力データとして既存のパレットとヒストグラムを使用できます、その結果、イメージデータのスキャンを避けます。
If no palette or histogram chunk is provided, a decoder can
develop its own, at the cost of an extra pass over the image data.
Alternatively, a default palette (probably a color cube) can be
used.
どんなパレットもヒストグラム塊も提供しないなら、デコーダはそれ自身のものを開発できます、イメージデータの上の余分なパスの費用で。 あるいはまた、デフォルトパレット(たぶんカラー立方体)を使用できます。
See also Recommendations for Encoders: Suggested palettes (Section
9.5).
また、Encodersに関してRecommendationsを見てください: パレット(セクション9.5)を示しました。
10.11. Text chunk processing
10.11. テキスト塊処理
If practical, decoders should have a way to display to the user
all tEXt and zTXt chunks found in the file. Even if the decoder
does not recognize a particular text keyword, the user might be
able to understand it.
実用的であるなら、デコーダで、ファイルですべてのtEXtをユーザに表示する方法とzTXt塊を見つけるはずです。 デコーダが特定のテキストキーワードを認識しないでも、ユーザはそれを理解できるかもしれません。
PNG text is not supposed to contain any characters outside the ISO
8859-1 "Latin-1" character set (that is, no codes 0-31 or 127-
159), except for the newline character (decimal 10). But decoders
might encounter such characters anyway. Some of these characters
can be safely displayed (e.g., TAB, FF, and CR, decimal 9, 12, and
13, respectively), but others, especially the ESC character
(decimal 27), could pose a security hazard because unexpected
PNGテキストはISO8859-1の外に「ニューラインキャラクタ(10進10)以外の1インチのラテン語の文字の組(すなわち、コードがありません0-31か127- 159)」であることでどんなキャラクタも含むべきではありません。 しかし、デコーダはとにかくそのようなキャラクタに遭遇するかもしれません。 安全にこれらの何人かのキャラクタを見せることができましたが(それぞれ例えば、TAB、FFとCR、9、12、および13の小数)、他のもの(特にESCキャラクタ(10進27))は、予期していないので、セキュリティ危険を引き起こすことができました。
Boutell, et. al. Informational [Page 64] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[64ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
actions may be taken by display hardware or software. To prevent
such hazards, decoders should not attempt to directly display any
non-Latin-1 characters (except for newline and perhaps TAB, FF,
CR) encountered in a tEXt or zTXt chunk. Instead, ignore them or
display them in a visible notation such as "\nnn". See Security
considerations (Section 8.5).
表示ハードウェアかソフトウェアは行動を取るかもしれません。 そのような危険を防ぐために、デコーダは、直接tEXtかzTXt塊で遭遇するどんな非ラテンの1つのキャラクタ(ニューラインと恐らくTAB、FF以外のCR)も見せるのを試みるはずがありません。 「代わりに、それらを無視するか、または」 \nnnなどの目に見える記法でそれらを表示してください。」 Security問題(セクション8.5)を見てください。
Even though encoders are supposed to represent newlines as LF, it
is recommended that decoders not rely on this; it's best to
recognize all the common newline combinations (CR, LF, and CR-LF)
and display each as a single newline. TAB can be expanded to the
proper number of spaces needed to arrive at a column multiple of
8.
エンコーダはLFとしてニューラインを表すべきですが、デコーダがこれを当てにしないのは、お勧めです。 ただ一つのニューラインとしてそれぞれすべての一般的なニューライン組み合わせ(CR、LF、およびCR-LF)と表示を認識するのは最も良いです。 8のコラム倍数に到着するのに必要である空間の適切な数にTABを広げることができます。
Decoders running on systems with non-Latin-1 character set
encoding should provide character code remapping so that Latin-1
characters are displayed correctly. Some systems may not provide
all the characters defined in Latin-1. Mapping unavailable
characters to a visible notation such as "\nnn" is a good
fallback. In particular, character codes 127-255 should be
displayed only if they are printable characters on the decoding
system. Some systems may interpret such codes as control
characters; for security, decoders running on such systems should
not display such characters literally.
非ラテンの1つの文字の組コード化でシステムで動くデコーダがキャラクタコード再写像を提供するはずであるので、正しくラテン語-1キャラクタを見せます。 いくつかのシステムはラテン語-1で定義されたすべてのキャラクタを提供しないかもしれません。 「」 \nnnなどの目に見える記法への入手できないキャラクタを写像します」は良い後退です。 特定のキャラクタコードで、それらが解読システムの上の印刷可能なキャラクタである場合にだけ127-255を表示するべきです。 いくつかのシステムが制御文字のようなコードを解釈するかもしれません。 セキュリティのために、そのようなシステムで動くデコーダは文字通りそのようなキャラクタを見せるはずがありません。
Decoders should be prepared to display text chunks that contain
any number of printing characters between newline characters, even
though encoders are encouraged to avoid creating lines in excess
of 79 characters.
デコーダはニューラインキャラクタの間にいろいろな表示文字を含むテキスト塊を表示するように準備されるべきです、エンコーダが、79のキャラクタを超えて線を作成するのを避けるよう奨励されますが。
11. Glossary
11. 用語集
a^b
Exponentiation; a raised to the power b. C programmers should be
careful not to misread this notation as exclusive-or. Note that
in gamma-related calculations, zero raised to any power is valid
and must give a zero result.
^b Exponentiation。 aはbを巾乗しました。 Cプログラマは、排他的論理和としてこの記法を誤読しないように慎重であるはずです。 どんなパワーへも高くしているゼロがガンマ関連の計算で、有効であり、結果を全くaに与えてはいけないことに注意してください。
Alpha
A value representing a pixel's degree of transparency. The more
transparent a pixel, the less it hides the background against
which the image is presented. In PNG, alpha is really the degree
of opacity: zero alpha represents a completely transparent pixel,
maximum alpha represents a completely opaque pixel. But most
people refer to alpha as providing transparency information, not
opacity information, and we continue that custom here.
画素の透明度を表すアルファA価値。 画素が見え透けば見え透くほど、それはイメージが提示されるバックグラウンドを隠しません。 PNGでは、アルファは本当に不透明の度合いです: 最大のアルファは、どんなアルファも完全に見え透いた画素を表さないと完全に不明瞭な画素表します。 しかし、ほとんどの人々が不透明度の情報ではなく、透明情報を提供するとアルファを呼びます、そして、私たちはここでその習慣を続けています。
Boutell, et. al. Informational [Page 65] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[65ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
Ancillary chunk
A chunk that provides additional information. A decoder can still
produce a meaningful image, though not necessarily the best
possible image, without processing the chunk.
追加情報を提供する付属の塊A塊。 必ず塊を処理することのない可能な限り良いイメージであるというわけではありませんが、デコーダはまだ意味のある画像を作り出すことができます。
Bit depth
The number of bits per palette index (in indexed-color PNGs) or
per sample (in other color types). This is the same value that
appears in IHDR.
ビットのパレットインデックス(索引をつけられたカラーPNGsの)かサンプル(他のカラータイプによる)あたりの数に深さに噛み付きました。 これはIHDRに現れる同じ値です。
Byte
Eight bits; also called an octet.
バイトEightビット。 また、八重奏と呼ばれます。
Channel
The set of all samples of the same kind within an image; for
example, all the blue samples in a truecolor image. (The term
"component" is also used, but not in this specification.) A
sample is the intersection of a channel and a pixel.
同じ種類のすべてのサンプルのセットはイメージの中でチャネルを開設します。 例えば、truecolorイメージのすべての青いサンプル。 (「コンポーネント」という用語は、また、使用されますが、この仕様で使用されるというわけではありません。) サンプルはチャンネルと画素の交差点です。
Chromaticity
A pair of values x,y that precisely specify the hue, though not
the absolute brightness, of a perceived color.
知覚された色の絶対明るさではありませんが、正確に色を指定する値x、yの色度A組。
Chunk
A section of a PNG file. Each chunk has a type indicated by its
chunk type name. Most types of chunks also include some data.
The format and meaning of the data within the chunk are determined
by the type name.
PNGの塊A部はファイルされます。 各塊には、塊型名によって示されたタイプがあります。 また、ほとんどのタイプの塊はいくつかのデータを含んでいます。 塊の中のデータの形式と意味は型名で決定します。
Composite
As a verb, to form an image by merging a foreground image and a
background image, using transparency information to determine
where the background should be visible. The foreground image is
said to be "composited against" the background.
As a動詞を合成して、フォアグラウンド画像と背景画像を合併することによって、イメージを形成してください、バックグラウンドがどこで目に見えるべきであるかを決定するのに透明情報を使用して。 イメージが言われているフォアグランドはバックグラウンドを「合成しました」。
CRC
Cyclic Redundancy Check. A CRC is a type of check value designed
to catch most transmission errors. A decoder calculates the CRC
for the received data and compares it to the CRC that the encoder
calculated, which is appended to the data. A mismatch indicates
that the data was corrupted in transit.
CRC周期冗長検査。 CRCはほとんどの伝送エラーを捕らえるように設計された一種のチェック値です。 デコーダは、受信データのためにCRCについて計算して、エンコーダが計算したCRCとそれを比較します(データに追加されます)。 ミスマッチは、データがトランジットで崩壊したのを示します。
Critical chunk
A chunk that must be understood and processed by the decoder in
order to produce a meaningful image from a PNG file.
PNGファイルから意味のある画像を作り出すためにデコーダで理解されて、処理しなければならない批判的な塊A塊。
CRT
Cathode Ray Tube: a common type of computer display hardware.
CRTブラウン管: コンピュータの普通形はハードウェアを表示します。
Boutell, et. al. Informational [Page 66] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[66ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
Datastream
A sequence of bytes. This term is used rather than "file" to
describe a byte sequence that is only a portion of a file. We
also use it to emphasize that a PNG image might be generated and
consumed "on the fly", never appearing in a stored file at all.
バイトのDatastream A系列。 今期はファイルの一部であるにすぎないバイト列について説明するために「ファイルする」よりむしろ使用されます。 また、私たちはPNGイメージが発生して、「急いで」消費されるかもしれないと強調するのにそれを使用します、全く格納されたファイルに決して現れないで。
Deflate
The name of the compression algorithm used in standard PNG files,
as well as in zip, gzip, pkzip, and other compression programs.
Deflate is a member of the LZ77 family of compression methods.
使用される圧縮アルゴリズムの名前に空気を抜かせてください。PNGがファイルして、ファスナ、gzip(pkzipの、そして、他の圧縮プログラム)空気を抜かせる規格に、圧縮方法のLZ77家のメンバーがいます。
Filter
A transformation applied to image data in hopes of improving its
compressibility. PNG uses only lossless (reversible) filter
algorithms.
フィルタA変化は圧縮性を改良するという望みでイメージデータに適用されました。 PNGはlosslessの(リバーシブル)のフィルタアルゴリズムだけを使用します。
Frame buffer
The final digital storage area for the image shown by a computer
display. Software causes an image to appear onscreen by loading
it into the frame buffer.
フレームはコンピュータのディスプレイで示されたイメージのための最終的なデジタル保存領域をバッファリングします。 ソフトウェアは、フレームバッファにそれをロードすることによって、イメージをテレビに見せます。
Gamma
The brightness of mid-level tones in an image. More precisely, a
parameter that describes the shape of the transfer function for
one or more stages in an imaging pipeline. The transfer function
is given by the expression
中間レベルの明るさがイメージで調子を変えさせるガンマ。 より正確に、転送の形について説明するパラメタはイメージパイプラインの1つ以上のステージに機能します。 表現で伝達関数を与えます。
output = input ^ gamma
出力は入力^ガンマと等しいです。
where both input and output are scaled to the range 0 to 1.
両方の入出力が0〜1に範囲に合わせて調整されるところ。
Grayscale
An image representation in which each pixel is represented by a
single sample value representing overall luminance (on a scale
from black to white). PNG also permits an alpha sample to be
stored for each pixel of a grayscale image.
各画素が総合的な輝度(黒から白までのスケールの)を表すただ一つの標本値によって表されるグレースケールAnイメージ表現。 また、PNGは、アルファのサンプルがグレースケールイメージの各画素のために格納されるのを可能にします。
Indexed color
An image representation in which each pixel is represented by a
single sample that is an index into a palette or lookup table.
The selected palette entry defines the actual color of the pixel.
各画素がインデックスであるただ一つのサンプルによって表される色のAnイメージ表現にパレットかルックアップ表に索引をつけました。 選択されたパレットエントリーは画素の実際の色を定義します。
Lossless compression
Any method of data compression that guarantees the original data
can be reconstructed exactly, bit-for-bit.
ビットのために噛み付かれて、まさにオリジナルのデータを保証するデータ圧縮の可逆圧縮Any方法を再建できます。
Boutell, et. al. Informational [Page 67] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[67ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
Lossy compression
Any method of data compression that reconstructs the original data
approximately, rather than exactly.
周囲でオリジナルのデータを再建するデータ圧縮の非可逆圧縮Any方法。
LSB
Least Significant Byte of a multi-byte value.
マルチバイト価値のLSB Least Significant Byte。
Luminance
Perceived brightness, or grayscale level, of a color. Luminance
and chromaticity together fully define a perceived color.
輝度Perceivedの明るさ、または色のグレースケールレベル。 輝度と一緒に色度は知覚された色を完全に定義します。
LUT
Look Up Table. In general, a table used to transform data. In
frame buffer hardware, a LUT can be used to map indexed-color
pixels into a selected set of truecolor values, or to perform
gamma correction. In software, a LUT can be used as a fast way of
implementing any one-variable mathematical function.
LUTはテーブルを見上げます。 一般に、テーブルは以前はよくデータを変えていました。 船体の骨組を組み立て終えてバッファハードウェア、選択されたセットのtruecolor値に索引をつけられたカラー画素を写像するか、またはガンマ修正を実行するのにLUTを使用できます。 ソフトウェアでは、どんな1可変な数学の機能も実行する速い方法としてLUTを使用できます。
MSB
Most Significant Byte of a multi-byte value.
マルチバイト価値のMSB Most Significant Byte。
Palette
The set of colors available in an indexed-color image. In PNG, a
palette is an array of colors defined by red, green, and blue
samples. (Alpha values can also be defined for palette entries,
via the tRNS chunk.)
パレット、索引をつけられたカラーイメージで利用可能な色のセット。 PNGでは、パレットは赤くて、緑色の、そして、青いサンプルによって定義された色の勢ぞろいです。 (また、tRNS塊でパレットエントリーと文字値を定義できます。)
Pixel
The information stored for a single grid point in the image. The
complete image is a rectangular array of pixels.
情報がただ一つの格子点のためにイメージに格納した画素。 完全なイメージは画素の長方形のアレイです。
PNG editor
A program that modifies a PNG file and preserves ancillary
information, including chunks that it does not recognize. Such a
program must obey the rules given in Chunk Ordering Rules (Chapter
7).
PNGファイルを変更して、それが認識しない塊を含む補助的情報を保存するPNGエディタAプログラム。 そのようなプログラムはChunk Ordering Rules(第7章)で与えられた規則に従わなければなりません。
Sample
A single number in the image data; for example, the red value of a
pixel. A pixel is composed of one or more samples. When
discussing physical data layout (in particular, in Image layout,
Section 2.3), we use "sample" to mean a number stored in the image
array. It would be more precise but much less readable to say
"sample or palette index" in that context. Elsewhere in the
specification, "sample" means a color value or alpha value. In
the indexed-color case, these are palette entries not palette
indexes.
イメージデータのAただ一つの番号を抽出してください。 例えば、画素の赤い値。 画素は1個以上のサンプルで構成されます。 物理的なデータレイアウト(特にImageレイアウトにおけるセクション2.3)について議論するとき、私たちは、イメージアレイに格納された数を意味するのに「サンプル」を使用します。 より正確ですが、その文脈で「サンプルかパレットインデックス」を言うのは、あまりそれほど読み込み可能でないでしょう。 仕様のほかの場所では、「サンプル」が色の値か文字値を意味します。 索引をつけられた色の場合では、これらはパレットインデックスではなく、パレットエントリーです。
Boutell, et. al. Informational [Page 68] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[68ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
Sample depth
The precision, in bits, of color values and alpha values. In
indexed-color PNGs the sample depth is always 8 by definition of
the PLTE chunk. In other color types it is the same as the bit
depth.
ビットの色の精度が評価する深さと文字値を抽出してください。 いつもサンプルの深さは定義上索引をつけられたカラーPNGsでは、8です。PLTE塊について。 他のカラータイプでは、それは噛み付いている深さと同じです。
Scanline
One horizontal row of pixels within an image.
イメージの中の走査線One横の列の画素。
Truecolor
An image representation in which pixel colors are defined by
storing three samples for each pixel, representing red, green, and
blue intensities respectively. PNG also permits an alpha sample
to be stored for each pixel of a truecolor image.
画素色が3を格納することによって定義されるTruecolor Anイメージ表現は各画素のためにそれぞれ赤を表す緑色の、そして、青い強度を抽出します。 また、PNGは、アルファのサンプルがtruecolorイメージの各画素のために格納されるのを可能にします。
White point
The chromaticity of a computer display's nominal white value.
コンピュータ表示の色度の白いポイントは名目上の白い値です。
zlib
A particular format for data that has been compressed using
deflate-style compression. Also the name of a library
implementing this method. PNG implementations need not use the
zlib library, but they must conform to its format for compressed
data.
スタイルに空気を抜かせている圧縮を使用することで圧縮されたデータのためのzlibのA特定の形式。 この方法を実行するライブラリの名前も。 PNG実現はzlibライブラリを使用する必要はありませんが、それらは圧縮されたデータのための形式に従わなければなりません。
12. Appendix: Rationale
12. 付録: 原理
(This appendix is not part of the formal PNG specification.)
(この付録は正式なPNG仕様の一部ではありません。)
This appendix gives the reasoning behind some of the design decisions in PNG. Many of these decisions were the subject of considerable debate. The authors freely admit that another group might have made different decisions; however, we believe that our choices are defensible and consistent.
この付録はPNGでデザイン決定のいくつか後ろで推理を与えます。 これらの決定の多くがかなりの討論の対象でした。 作者は、別のグループが異なった決定をしたかもしれないことを自由に認めます。 しかしながら、私たちは、私たちの選択が防御可能であって、一貫していると信じています。
12.1. Why a new file format?
12.1. なぜ新しいファイル形式?
Does the world really need yet another graphics format? We
believe so. GIF is no longer freely usable, but no other commonly
used format can directly replace it, as is discussed in more
detail below. We might have used an adaptation of an existing
format, for example GIF with an unpatented compression scheme.
But this would require new code anyway; it would not be all that
much easier to implement than a whole new file format. (PNG is
designed to be simple to implement, with the exception of the
compression engine, which would be needed in any case.) We feel
that this is an excellent opportunity to design a new format that
fixes some of the known limitations of GIF.
世界は本当にさらに別のグラフィックス形式を必要としますか? 私たちはそのように信じています。 GIFはもう自由に使用可能ではありませんが、他のどんな一般的に使用された形式も直接それを取り替えることができません、さらに詳細に以下で議論するように。 私たちは既存の形式の適合、例えば「非-特許をと」られた圧縮技術があるGIFを使用したかもしれません。 しかし、これはとにかく新法を必要とするでしょう。 それはすべて真新しいファイル形式より道具に簡単なそれだけであるというわけではありません。 (PNGは実行するのが簡単であるように設計されています、圧縮エンジンを除いて。)(どのような場合でも、エンジンが必要でしょう)。 私たちは、これがGIFの知られている限界のいくつかを修理する新しい形式を設計する素晴らしい機会であると感じます。
Boutell, et. al. Informational [Page 69] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[69ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
12.2. Why these features?
12.2. なぜこれらの特徴?
The features chosen for PNG are intended to address the needs of
applications that previously used the special strengths of GIF.
In particular, GIF is well adapted for online communications
because of its streamability and progressive display capability.
PNG shares those attributes.
PNGに選ばれた特徴が以前にGIFの特別な強さを使用したアプリケーションの必要性を記述することを意図します。 特に、GIFはstreamabilityと進歩的な表示能力のためにオンラインコミュニケーションのためによく適合させられます。 PNGはそれらの属性を共有します。
We have also addressed some of the widely known shortcomings of
GIF. In particular, PNG supports truecolor images. We know of no
widely used image format that losslessly compresses truecolor
images as effectively as PNG does. We hope that PNG will make use
of truecolor images more practical and widespread.
また、私たちはGIFの広く知られている短所のいくつかを記述しました。 特に、PNGはtruecolorイメージを支持します。 私たちはlosslesslyにPNGがそうするのと同じくらい有効にtruecolorイメージを圧縮する広く使用された画像形式を全く知りません。 PNGが、より実用的であって、truecolorイメージの使用を広範囲にさせることを願っています。
Some form of transparency control is desirable for applications in
which images are displayed against a background or together with
other images. GIF provided a simple transparent-color
specification for this purpose. PNG supports a full alpha channel
as well as transparent-color specifications. This allows both
highly flexible transparency and compression efficiency.
イメージがバックグラウンドに対して他のイメージと共に表示されるアプリケーションに、何らかの形式の透明コントロールは望ましいです。 GIFはこのために簡単な透明色仕様を提供しました。 PNGは透明色仕様としてまた、完全なアルファチャンネルを支えます。 これは非常にフレキシブルな透明と圧縮効率の両方を許容します。
Robustness against transmission errors has been an important
consideration. For example, images transferred across Internet
are often mistakenly processed as text, leading to file
corruption. PNG is designed so that such errors can be detected
quickly and reliably.
伝送エラーに対する丈夫さは重要な考慮すべき事柄です。 例えば、ファイル不正に通じて、インターネットの向こう側に移されたイメージはテキストとしてしばしば誤って処理されます。 PNGが設計されているので、そのような誤りをすぐに、そして確かに検出できます。
PNG has been expressly designed not to be completely dependent on
a single compression technique. Although deflate/inflate
compression is mentioned in this document, PNG would still exist
without it.
PNGは、完全にただ一つの圧縮のテクニックに依存しているというわけではないように明白に設計されています。 空気を抜くか、またはふくらませてください。圧縮は本書では言及されて、PNGはそれなしでまだ存在しているでしょう。
12.3. Why not these features?
12.3. なぜこれらの特徴でない?
Some features have been deliberately omitted from PNG. These
choices were made to simplify implementation of PNG, promote
portability and interchangeability, and make the format as simple
and foolproof as possible for users. In particular:
いくつかの特徴が故意にPNGから省略されました。 PNGの実現を簡素化して、携帯性と互換性を促進して、形式をできるだけユーザにとって簡単できわめて簡単にするのをこれらの選択をしました。 特に:
Boutell, et. al. Informational [Page 70] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[70ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
* There is no uncompressed variant of PNG. It is possible to
store uncompressed data by using only uncompressed deflate
blocks (a feature normally used to guarantee that deflate
does not make incompressible data much larger). However,
PNG software must support full deflate/inflate; any software
that does not is not compliant with the PNG standard. The
two most important features of PNG---portability and
compression---are absolute requirements for online
applications, and users demand them. Failure to support full
deflate/inflate compromises both of these objectives.
* There is no lossy compression in PNG. Existing formats such
as JFIF already handle lossy compression well. Furthermore,
available lossy compression methods (e.g., JPEG) are far
from foolproof --- a poor choice of quality level can ruin
an image. To avoid user confusion and unintentional loss of
information, we feel it is best to keep lossy and lossless
formats strictly separate. Also, lossy compression is
complex to implement. Adding JPEG support to a PNG decoder
might increase its size by an order of magnitude. This
would certainly cause some decoders to omit support for the
feature, which would destroy our goal of interchangeability.
* There is no support for CMYK or other unusual color spaces.
Again, this is in the name of promoting portability. CMYK,
in particular, is far too device-dependent to be useful as a
portable image representation.
* There is no standard chunk for thumbnail views of images.
In discussions with software vendors who use thumbnails in
their products, it has become clear that most would not use
a "standard" thumbnail chunk. For one thing, every vendor
has a different idea of what the dimensions and
characteristics of a thumbnail ought to be. Also, some
vendors keep thumbnails in separate files to accommodate
varied image formats; they are not going to stop doing that
simply because of a thumbnail chunk in one new format.
Proprietary chunks containing vendor-specific thumbnails
appear to be more practical than a common thumbnail format.
* PNGの解凍された異形が全くありません。 店に、使用することによって解凍されただけである解凍されたデータがブロックに空気を抜かせるのは(通常、それが空気を抜くのを保証するのに使用される特徴で、圧縮不可能なデータははるかに大きくなりません)、可能です。 しかしながら、PNGソフトウェア必須サポート満は、空気を抜くか、またはふくらませられます。 それがするどんなソフトウェアもPNG規格で対応します。 PNGの2つの最も重要な特徴---携帯性と圧縮---絶対条件はオンラインアプリケーションのためのものです、そして、ユーザは彼らを要求します。 いっぱいに支持する失敗は、妥協のこれらの目的の両方を空気を抜くか、またはふくらませます。 * 非可逆圧縮が全くPNGにありません。 JFIFが既に非可逆圧縮をよく扱うとき、存在はそのようなものをフォーマットします。 その上、利用可能な非可逆圧縮方法(例えば、JPEG)は全くきわめて簡単ではありません。--- 品質水準の不十分な選択はイメージを台無しにすることができます。 情報のユーザ混乱と意図的でない損失を避けるために、私たちは、損失性とlossless形式を厳密に別々に保つのが最も良いと感じます。 また、非可逆圧縮も、実行するために複雑です。 PNGデコーダにJPEGサポートを加えると、サイズは1桁増加するかもしれません。 確かに、これで、いくつかのデコーダが特徴のサポートを省略するでしょう。(特徴は私たちの互換性の目標を破壊するでしょう)。 * CMYKか他の珍しい色空間のサポートが全くありません。 一方、携帯性を促進することの名にかけてこれはあります。 CMYKは装置特にはるかに携帯用のイメージ表現として役に立つように思えないほど依存しています。 * イメージの小さい視点のためのどんな標準の塊もありません。 それらの製品の中に親指の爪を使用するソフトウェア業者との議論では、大部分が小さい「標準」の塊を使用しないだろうというのは明確になりました。 一つには、すべての業者には、親指の爪の寸法と特性が何であるべきであるかに関する異なった考えがあります。 また、いくつかの業者が様々な画像形式に対応するために別々のファイルに親指の爪を保ちます。 そんなに単に小さい塊のために、彼らは1つの新しい形式で手を止めないでしょう。 業者特有の親指の爪を含む独占塊は一般的な小さい形式より実用的であるように見えます。
It is worth noting that private extensions to PNG could easily add
these features. We will not, however, include them as part of the
basic PNG standard.
PNGへの個人的な拡大が容易にこれらの特徴を加えるかもしれないことに注意する価値があります。 しかしながら、私たちは基本的なPNG規格の一部としてそれらを入れるつもりではありません。
Boutell, et. al. Informational [Page 71] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[71ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
PNG also does not support multiple images in one file. This
restriction is a reflection of the reality that many applications
do not need and will not support multiple images per file. In any
case, single images are a fundamentally different sort of object
from sequences of images. Rather than make false promises of
interchangeability, we have drawn a clear distinction between
single-image and multi-image formats. PNG is a single-image
format. (But see Multiple-image extension, Section 8.4.)
PNGも1個のファイルの複数のイメージを支持しません。 この制限は、多くのアプリケーションが必要としない現実の反映であり、ファイル単位で複数のイメージを支持しないでしょう。 どのような場合でも、ただ一つのイメージは基本的にイメージの系列と異なった種類の物です。 むしろ、私たちは互換性の誤った見込みをするよりただ一つのイメージとマルチ画像形式の間で明らかな区別を引き起こしました。 PNGはただ一つの画像形式です。 (しかし、Multiple-イメージ拡張子、セクション8.4を見てください。)
12.4. Why not use format X?
12.4. なぜ形式Xを使用しませんか?
Numerous existing formats were considered before deciding to
develop PNG. None could meet the requirements we felt were
important for PNG.
多数の既存の形式はPNGを開発すると決める前に、考えられました。 なにも私たちがPNGに重要であると感じた必要条件は満たすことができませんでした。
GIF is no longer suitable as a universal standard because of legal
entanglements. Although just replacing GIF's compression method
would avoid that problem, GIF does not support truecolor images,
alpha channels, or gamma correction. The spec has more subtle
problems too. Only a small subset of the GIF89 spec is actually
portable across a variety of implementations, but there is no
codification of the most portable part of the spec.
GIFは法的な掛り合いのためにもう世界基準として適当ではありません。 ただGIFのものを取り替えますが、圧縮方法はその問題を避けて、GIFはtruecolorイメージ、アルファチャンネル、またはガンマ修正を支えません。 仕様には、より微妙な問題もあります。 GIF89仕様の小さい部分集合だけが実際にさまざまな実現の向こう側に携帯用ですが、仕様の最も携帯用の部分の成文化が全くありません。
TIFF is far too complex to meet our goals of simplicity and
interchangeability. Defining a TIFF subset would meet that
objection, but would frustrate users making the reasonable
assumption that a file saved as TIFF from their existing software
would load into a program supporting our flavor of TIFF.
Furthermore, TIFF is not designed for stream processing, has no
provision for progressive display, and does not currently provide
any good, legally unencumbered, lossless compression method.
TIFFは私たちの簡単さと互換性の目標を達成できないくらい複雑です。 TIFF部分集合を定義すると、その異論が満たされるでしょうが、彼らの既存のソフトウェアからのTIFFは私たちのTIFFの風味を支持するプログラムにロードするでしょう、したがって、ファイルが保存されたという妥当な想定をしているユーザが失望させられるでしょう。 その上、TIFFは流れの処理のために設計されていなくて、また進歩的な表示のために支給を全く持たないで、また現在、少しの良くて、法的に邪魔されないlossless圧縮方法も提供しません。
IFF has also been suggested, but is not suitable in detail:
available image representations are too machine-specific or not
adequately compressed. The overall chunk structure of IFF is a
useful concept that PNG has liberally borrowed from, but we did
not attempt to be bit-for-bit compatible with IFF chunk structure.
Again this is due to detailed issues, notably the fact that IFF
FORMs are not designed to be serially writable.
IFFはまた、示されましたが、詳細に適当ではありません: 利用可能なイメージ表現は、マシン特有過ぎるか適切に圧縮されていません。 IFFの総合的な塊構造はPNGが気前よく借りさせる役に立つ概念ですが、私たちは、IFF塊構造とのコンパチブルビットビットであることを試みませんでした。 一方、これは詳細な問題、IFF FORMsが順次書き込み可能になるように設計されていないという著しく事実のためです。
Lossless JPEG is not suitable because it does not provide for the
storage of indexed-color images. Furthermore, its lossless
truecolor compression is often inferior to that of PNG.
索引をつけられたカラーイメージの格納に備えないので、Lossless JPEGは適当ではありません。 その上、lossless truecolor圧縮はPNGのものにしばしば劣っています。
Boutell, et. al. Informational [Page 72] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[72ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
12.5. Byte order
12.5. バイトオーダー
It has been asked why PNG uses network byte order. We have
selected one byte ordering and used it consistently. Which order
in particular is of little relevance, but network byte order has
the advantage that routines to convert to and from it are already
available on any platform that supports TCP/IP networking,
including all PC platforms. The functions are trivial and will be
included in the reference implementation.
それはPNGがなぜネットワークバイトオーダーを使用するか尋ねられました。 私たちは、一貫して1つのバイト順を選択して、それを使用しました。 ネットワークバイトオーダーには、どれが注文されるかは、ほとんど特に関連性のものではありませんが、それとそれから変換するルーチンが既にそうである利点がTCP/IPネットワークをサポートするどんなプラットホームでも利用可能な状態であります、すべてのPCプラットホームを含んでいて。機能は、些細であり、参照実現に含まれるでしょう。
12.6. Interlacing
12.6. 交錯します。
PNG's two-dimensional interlacing scheme is more complex to
implement than GIF's line-wise interlacing. It also costs a
little more in file size. However, it yields an initial image
eight times faster than GIF (the first pass transmits only 1/64th
of the pixels, compared to 1/8th for GIF). Although this initial
image is coarse, it is useful in many situations. For example, if
the image is a World Wide Web imagemap that the user has seen
before, PNG's first pass is often enough to determine where to
click. The PNG scheme also looks better than GIF's, because
horizontal and vertical resolution never differ by more than a
factor of two; this avoids the odd "stretched" look seen when
interlaced GIFs are filled in by replicating scanlines.
Preliminary results show that small text in an interlaced PNG
image is typically readable about twice as fast as in an
equivalent GIF, i.e., after PNG's fifth pass or 25% of the image
data, instead of after GIF's third pass or 50%. This is again due
to PNG's more balanced increase in resolution.
PNGの二次元交錯計画は、実行するためにGIFが立ち並んでいる的に交錯するより複雑です。 また、それはファイルサイズでもう少しかかります。 しかしながら、それはGIFより8倍速い初期のイメージをもたらします(最初のパスが画素について1/64番目だけに送られます、GIFのために1/8番目と比べて)。 この初期のイメージは粗いのですが、それは多くの状況で役に立ちます。 例えば、イメージがユーザが以前見たことがあるWWWイメージマップであるなら、PNGの最初のパスは、どこをクリックするかを決定するためにしばしば十分です。 また、PNG計画はGIFのより良く見えます、水平で垂直な解決が2のさらに1以上要素で決して異ならないので。 これは走査線を模写することによってインターレースGIFが記入されると見られた状態で変な「伸ばされた」外観を避けます。 予備の結果は、交錯しているPNGイメージによる小さいテキストが同等なGIFの2倍およそ速く通常読み込み可能であることを示します、すなわち、PNGのイメージデータの5番目のパスか25%後に、GIFの3番目のパスか50%後の代わりに。 これは再び解決のPNGの、よりバランスのとれている増加のためです。
12.7. Why gamma?
12.7. なぜガンマ?
It might seem natural to standardize on storing sample values that
are linearly proportional to light intensity (that is, have gamma
of 1.0). But in fact, it is common for images to have a gamma of
less than 1. There are three good reasons for this:
それは光強度(すなわち、1.0のガンマを持っている)に比例している直線的である標本値を格納するとき標準化するために自然に見えるかもしれません。 しかし、事実上、イメージには1未満のガンマがあるのは、一般的です。 この3つのもっともな理由があります:
* For reasons detailed in Gamma Tutorial (Chapter 13), all
video cameras apply a "gamma correction" function to the
intensity information. This causes the video signal to have
a gamma of about 0.5 relative to the light intensity in the
original scene. Thus, images obtained by frame-grabbing
video already have a gamma of about 0.5.
* The human eye has a nonlinear response to intensity, so
linear encoding of samples either wastes sample codes in
bright areas of the image, or provides too few sample codes
to avoid banding artifacts in dark areas of the image, or
both. At least 12 bits per sample are needed to avoid
* Gamma Tutorial(第13章)で詳細な理由で、すべてのビデオカメラが「ガンマ補正」機能を強度情報に適用します。 これで、ビデオ信号には、元の場面の光強度に比例しておよそ0.5のガンマがあります。 したがって、フレームをつかむビデオによって得られたイメージは既におよそ0.5のガンマを持ちます。 * 人の目は、強度への非線形の応答、どちらの廃棄物のサンプルがもイメージの明るい領域でコード化するサンプルのとても直線的なコード化を持っているか、またはイメージ、または両方の暗黒領域で人工物を括るのを避けるためにあまりにわずかなサンプルコードしか備えません。 少なくとも避ける1サンプルあたりのビットが必要である12
Boutell, et. al. Informational [Page 73] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[73ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
visible artifacts in linear encoding with a 100:1 image
intensity range. An image gamma in the range 0.3 to 0.5
allocates sample values in a way that roughly corresponds to
the eye's response, so that 8 bits/sample are enough to
avoid artifacts caused by insufficient sample precision in
almost all images. This makes "gamma encoding" a much
better way of storing digital images than the simpler linear
encoding.
* Many images are created on PCs or workstations with no gamma
correction hardware and no software willing to provide gamma
correction either. In these cases, the images have had
their lighting and color chosen to look best on this
platform --- they can be thought of as having "manual" gamma
correction built in. To see what the image author intended,
it is necessary to treat such images as having a file_gamma
value in the range 0.4-0.6, depending on the room lighting
level that the author was working in.
100がある直線的なコード化: 1つの画像強度における目に見える人工物は及びます。 範囲0.3〜0.5のイメージガンマはおよそ目の応答に対応する方法で標本値を割り当てます、8個のビット/サンプルがほとんどすべてのイメージによる不十分なサンプルの精度によって引き起こされた人工物を避けるために十分であるように。 これは、より簡単な直線的なコード化より「ガンマコード化」をディジタル画像を格納するはるかに良いようにします。 * 多くのイメージがPCかワークステーションの上でガンマ補正ハードウェアが思いますが、ガンマ修正を提供しても構わないと思っていない少しもソフトウェアなしでも作成されます。 イメージで、見るためにこのプラットホームでこれらの場合が、最も上手にそれらの照明と色を選んでいました。--- 「手動」のガンマ修正を組み込ませるとそれらを考えることができます。 イメージ作者が意図したものを見るのに、範囲0.4-0.6にファイル_ガンマ値を持っているようなイメージを扱うのが必要です、作者が働いていた余地の照明レベルによって。
In practice, image gamma values around 1.0 and around 0.5 are both
widely found. Older image standards such as GIF often do not
account for this fact. The JFIF standard specifies that images in
that format should use linear samples, but many JFIF images found
on the Internet actually have a gamma somewhere near 0.4 or 0.5.
The variety of images found and the variety of systems that people
display them on have led to widespread problems with images
appearing "too dark" or "too light".
実際には、1.0とおよそ0.5の周りのイメージガンマ値はともに広く見つけられます。 GIFなどの、より古いイメージ規格はしばしばこの事実を説明するというわけではありません。 JFIF規格は、その形式のイメージが直線的なサンプルを使用するべきであると指定しますが、インターネットで見つけられた多くのJFIFイメージが実際に0.4か0.5におけるどこかにガンマを持っています。 見つけられたイメージのバラエティーと人々が彼らを表示するシステムのバラエティーは「暗過ぎる」か「軽過ぎる」ように見えるイメージに関する広範囲の問題を引き起こしました。
PNG expects viewers to compensate for image gamma at the time that
the image is displayed. Another possible approach is to expect
encoders to convert all images to a uniform gamma at encoding
time. While that method would speed viewers slightly, it has
fundamental flaws:
PNGは、ビューアーがイメージを表示する時にイメージガンマを補うと予想します。 別の可能なアプローチはエンコーダが時間をコード化するところですべてのイメージを一定のガンマに変換すると予想することです。 その方法はビューアーをわずかに促進するでしょうが、それには、根本的な欠陥があります:
* Gamma correction is inherently lossy due to quantization and
roundoff error. Requiring conversion at encoding time thus
causes irreversible loss. Since PNG is intended to be a
lossless storage format, this is undesirable; we should
store unmodified source data.
* The encoder might not know the source gamma value. If the
decoder does gamma correction at viewing time, it can adjust
the gamma (change the displayed brightness) in response to
feedback from a human user. The encoder has no such
recourse.
* Whatever "standard" gamma we settled on would be wrong for
some displays. Hence viewers would still need gamma
correction capability.
* 本来量子化とロンダード誤りのためにガンマ修正は損失性です。 その結果、時間をコード化するのに変換を必要とすると、不可逆的損失は引き起こされます。 PNGがlossless格納形式であることを意図するので、これは望ましくありません。 私たちは変更されていないソースデータを格納するべきです。 * エンコーダはソースガンマ値を知らないかもしれません。 デコーダがビューイング・タイムにガンマ修正をするなら、それは人間のユーザからのフィードバックに対応してガンマ(表示された明るさを変える)を調整できます。 エンコーダには、どんなそのような償還請求もありません。 * いくつかの表示において、私たちが決めたどんな「標準」のガンマも間違っているでしょう。 したがって、ビューアーはまだガンマ補正能力を必要とするでしょう。
Boutell, et. al. Informational [Page 74] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[74ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
Since there will always be images with no gamma or an incorrect
recorded gamma, good viewers will need to incorporate gamma
adjustment code anyway. Gamma correction at viewing time is thus
the right way to go.
イメージがガンマも不正確な記録されたガンマなしでいつもあるので、良いビューアーは、とにかくガンマ調整コードを取り入れる必要があるでしょう。 その結果、ビューイング・タイムのガンマ修正は行く正しい方法です。
See Gamma Tutorial (Chapter 13) for more information.
詳しい情報に関してGamma Tutorial(第13章)を見てください。
12.8. Non-premultiplied alpha
12.8. 非前掛け算をさせられたアルファ
PNG uses "unassociated" or "non-premultiplied" alpha so that
images with separate transparency masks can be stored losslessly.
Another common technique, "premultiplied alpha", stores pixel
values premultiplied by the alpha fraction; in effect, the image
is already composited against a black background. Any image data
hidden by the transparency mask is irretrievably lost by that
method, since multiplying by a zero alpha value always produces
zero.
PNGは、losslesslyに別々の透明マスクがあるイメージを格納できるように"非連想"の、または、「非前掛け算をさせられた」アルファを使用します。 「前掛け算をさせられたアルファ」という別の一般的なテクニックはアルファ分画によって前掛け算をさせられるピクセル値を格納します。 事実上、イメージは黒いバックグラウンドに対して既に合成されます。 透明マスクに隠れているどんなイメージデータも取り返しがつかないほどその方法で失われています、ゼロで増えて、文字値がいつもゼロを生産するので。
Some image rendering techniques generate images with premultiplied
alpha (the alpha value actually represents how much of the pixel
is covered by the image). This representation can be converted to
PNG by dividing the sample values by alpha, except where alpha is
zero. The result will look good if displayed by a viewer that
handles alpha properly, but will not look very good if the viewer
ignores the alpha channel.
いくつかのイメージ表現のテクニックが前掛け算をさせられたアルファでイメージを発生させます(文字値は実際に画素の多くがイメージでどう覆われているかを表します)。 アルファで標本値を分割するアルファがゼロであるところを除いて、この表現をPNGに変換できます。 結果は、適切にアルファを扱うビューアーによって表示されると良く見えますが、ビューアーがアルファチャンネルを無視するなら、非常に良く見えないでしょう。
Although each form of alpha storage has its advantages, we did not
want to require all PNG viewers to handle both forms. We
standardized on non-premultiplied alpha as being the lossless and
more general case.
それぞれの形式のアルファ格納には、利点がありますが、私たちは、すべてのPNGビューアーが. 私たちがlosslessと、より一般的なケースであるとして非前掛け算をさせられたアルファで標準化した両方のフォームを扱うのを必要としたくはありませんでした。
12.9. Filtering
12.9. フィルタリング
PNG includes filtering capability because filtering can
significantly reduce the compressed size of truecolor and
grayscale images. Filtering is also sometimes of value on
indexed-color images, although this is less common.
PNGは、フィルタリングがtruecolorとグレースケールイメージの圧縮されたサイズをかなり減少させることができるので能力をフィルターにかけるのを含んでいます。 フィルタリングには、これはそれほど一般的ではありませんが、また、時々価値が索引をつけられたカラーイメージにあります。
The filter algorithms are defined to operate on bytes, rather than
pixels; this gains simplicity and speed with very little cost in
compression performance. Tests have shown that filtering is
usually ineffective for images with fewer than 8 bits per sample,
so providing pixelwise filtering for such images would be
pointless. For 16 bit/sample data, bytewise filtering is nearly
as effective as pixelwise filtering, because MSBs are predicted
from adjacent MSBs, and LSBs are predicted from adjacent LSBs.
フィルタアルゴリズムは画素よりむしろバイトを作動させるために定義されます。 これは圧縮性能における非常に少ない費用に従った簡単さと速度を獲得します。 そのようなイメージは無意味でしょう、テストが、イメージには、通常、フィルタリングが1サンプルあたり8ビット未満のために効力がないのを示したので、したがって、提供はフィルタリングをpixelwiseします。 ビット/は、16のために、データを抽出して、bytewiseされます。フィルタリングはフィルタリングをpixelwiseするのとほとんど同じくらい有効です、MSBsが隣接しているMSBsから予測されて、LSBsが隣接しているLSBsから予測されるので。
Boutell, et. al. Informational [Page 75] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[75ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
The encoder is allowed to change filters for each new scanline.
This creates no additional complexity for decoders, since a
decoder is required to contain defiltering logic for every filter
type anyway. The only cost is an extra byte per scanline in the
pre-compression datastream. Our tests showed that when the same
filter is selected for all scanlines, this extra byte compresses
away to almost nothing, so there is little storage cost compared
to a fixed filter specified for the whole image. And the
potential benefits of adaptive filtering are too great to ignore.
Even with the simplistic filter-choice heuristics so far
discovered, adaptive filtering usually outperforms fixed filters.
In particular, an adaptive filter can change behavior for
successive passes of an interlaced image; a fixed filter cannot.
エンコーダはそれぞれの新しい走査線のためにフィルタを変えることができます。 これはデコーダのためのどんな追加複雑さも作成しません、デコーダがとにかくすべてのフィルタタイプのための「反-フィルターにかけ」る論理を含むのに必要であるので。 プレ圧縮datastreamにおける走査線あたり唯一の費用が余分な1バイトです。 私たちのテストは、固定フィルタと比べて、格納がほとんど無ほとんどない遠くでの湿布がかかるこの余分なバイトが、同じフィルタがいつすべての走査線のために選択されるかを全体のイメージに指定したのを示しました。 そして、適応型のフィルタリングの潜在的利益は無視できないくらいすばらしいです。 安易なフィルタ選択発見的教授法さえ今までのところ発見されている状態で、通常、適応型のフィルタリングは固定フィルタより優れています。 特に、適応フィルターは交錯しているイメージの連続したパスのための振舞いを変えることができます。 固定フィルタはそうすることができません。
12.10. Text strings
12.10. テキスト文字列
Most graphics file formats include the ability to store some
textual information along with the image. But many applications
need more than that: they want to be able to store several
identifiable pieces of text. For example, a database using PNG
files to store medical X-rays would likely want to include
patient's name, doctor's name, etc. A simple way to do this in
PNG would be to invent new private chunks holding text. The
disadvantage of such an approach is that other applications would
have no idea what was in those chunks, and would simply ignore
them. Instead, we recommend that textual information be stored in
standard tEXt chunks with suitable keywords. Use of tEXt tells
any PNG viewer that the chunk contains text that might be of
interest to a human user. Thus, a person looking at the file with
another viewer will still be able to see the text, and even
understand what it is if the keywords are reasonably self-
explanatory. (To this end, we recommend spelled-out keywords, not
abbreviations that will be hard for a person to understand.
Saving a few bytes on a keyword is false economy.)
ほとんどのグラフィックスファイル形式がイメージに伴う何らかの文字情報を格納する能力を含んでいます。 しかし、多くのアプリケーションがそれ以上を必要とします: 彼らは数個の身元保証可能なテキストを格納できるようになりたがっています。 例えば、医療X線を格納するのにPNGファイルを使用するデータベースはおそらく患者の名前、医師の名前などを含みたがっているでしょう。 PNGでこれをする簡単な方法はテキストを保持する新しい個人的な塊を発明するだろうことです。 そのようなアプローチの不都合は他のアプリケーションがそれらの塊にはあったものが分からないだろう、単にそれらを無視するだろうということです。 代わりに、私たちは、文字情報が標準のtEXt塊に適当なキーワードで格納されることを勧めます。 tEXtの使用は、塊が人間のユーザにとって、興味深いかもしれないテキストを含むとどんなPNGビューアーにも言います。 したがって、別のビューアーでファイルを見ている人は、テキストを考えて、キーワードが自己かなり説明していると、それが何であるかをまだ理解さえできるでしょう。 (このために、私たちは、人にとって困難になる略語ではなく、詳しく説明しているキーワードが分かることを勧めます。 キーワードの数バイトを節約するのは、不経済です。)
The ISO 8859-1 (Latin-1) character set was chosen as a compromise
between functionality and portability. Some platforms cannot
display anything more than 7-bit ASCII characters, while others
can handle characters beyond the Latin-1 set. We felt that
Latin-1 represents a widely useful and reasonably portable
character set. Latin-1 is a direct subset of character sets
commonly used on popular platforms such as Microsoft Windows and X
Windows. It can also be handled on Macintosh systems with a
simple remapping of characters.
ISO8859-1(ラテン-1)文字の組は機能性と携帯性の間の妥協として選ばれました。 いくつかのプラットホームは7ビットのASCII文字より何も多いものを表示できませんが、他のものはラテン語-1セットを超えてキャラクタを扱うことができます。 私たちは、ラテン語-1が広く役に立って合理的に携帯用の文字の組を表すと感じました。 ラテン-1はマイクロソフトWindowsやX-windowsなどのポピュラーなプラットホームで一般的に使用される文字の組のダイレクト部分集合です。 また、マッキントッシュシステムの上でキャラクタの簡単な再写像でそれを扱うことができます。
There is presently no provision for text employing character sets
other than Latin-1. We recognize that the need for other character
sets will increase. However, PNG already requires that
現在、ラテン語-1以外の文字の組を使うテキストへの支給が全くありません。 私たちは、他の文字の組の必要性が大きくなると認めます。 しかしながら、PNGは既にそれを必要とします。
Boutell, et. al. Informational [Page 76] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[76ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
programmers implement a number of new and unfamiliar features, and
text representation is not PNG's primary purpose. Since PNG
provides for the creation and public registration of new ancillary
chunks of general interest, we expect that text chunks for other
character sets, such as Unicode, eventually will be registered and
increase gradually in popularity.
プログラマは多くの新しくてなじみのない特徴を実行します、そして、テキスト表現はPNGの第一の目的ではありません。 PNGが新しい付属の一般的に関心の塊の創造と公共の登録に備えるので、私たちは、ユニコードなどの他の文字の組のためのテキスト塊が結局登録されていると予想して、徐々に人気が増します。
12.11. PNG file signature
12.11. PNGファイル署名
The first eight bytes of a PNG file always contain the following
values:
PNGファイルの最初の8バイトはいつも以下の値を含んでいます:
(decimal) 137 80 78 71 13 10 26 10
(hexadecimal) 89 50 4e 47 0d 0a 1a 0a
(ASCII C notation) \211 P N G \r \n %%BODY%%32 \n
211(10進)の137 80 78 71 13 10 26 10(16進)89 50 4e47 0d 0a 1a 0a(ASCII C記法)円のN G\r円nの032円のP\n
This signature both identifies the file as a PNG file and provides
for immediate detection of common file-transfer problems. The
first two bytes distinguish PNG files on systems that expect the
first two bytes to identify the file type uniquely. The first
byte is chosen as a non-ASCII value to reduce the probability that
a text file may be misrecognized as a PNG file; also, it catches
bad file transfers that clear bit 7. Bytes two through four name
the format. The CR-LF sequence catches bad file transfers that
alter newline sequences. The control-Z character stops file
display under MS-DOS. The final line feed checks for the inverse
of the CR-LF translation problem.
この署名は、ファイルがPNGファイルであると認識して、一般的なファイル転送問題の即座の検出に備えます。最初の2バイトは最初の2バイトが唯一ファイルの種類を特定すると予想するシステムのPNGファイルを区別します。 最初のバイトはテキストファイルがPNGファイルとしてmisrecognizedされるかもしれないという確率を減少させるために非ASCII値として選ばれています。 また、それはビット7をきれいにする悪いファイル転送を捕らえます。 バイト2〜fourは形式を命名します。 CR-LF系列はニューライン系列を変更する悪いファイル転送を捕らえます。 コントロールZキャラクタはMS-DOSの下でファイル表示を止めます。 最終的な改行はCR-LF翻訳問題の逆がないかどうかチェックします。
A decoder may further verify that the next eight bytes contain an
IHDR chunk header with the correct chunk length; this will catch
bad transfers that drop or alter null (zero) bytes.
デコーダは、次の8バイトが適度の塊の長さでIHDR塊ヘッダーを含むことをさらに確かめるかもしれません。 これはヌル(ゼロ)のバイトを低下するか、または変更する悪い転送を捕らえるでしょう。
Note that there is no version number in the signature, nor indeed
anywhere in the file. This is intentional: the chunk mechanism
provides a better, more flexible way to handle format extensions,
as explained in Chunk naming conventions (Section 12.13).
バージョン番号が全く署名と、本当にファイルで何処にもないことに注意してください。 これは意図的です: 塊メカニズムは形式拡大を扱うより良くて、よりフレキシブルな方法を提供します、(セクション12.13)とコンベンションを命名するChunkで説明されるように。
12.12. Chunk layout
12.12. 塊レイアウト
The chunk design allows decoders to skip unrecognized or
uninteresting chunks: it is simply necessary to skip the
appropriate number of bytes, as determined from the length field.
塊デザインで、デコーダは認識されていないかおもしろくない塊をスキップできます: 適切なバイト数をスキップするのが長さの分野から決定するように単に必要です。
Limiting chunk length to (2^31)-1 bytes avoids possible problems
for implementations that cannot conveniently handle 4-byte
unsigned values. In practice, chunks will usually be much shorter
than that anyway.
塊の長さを(2^31)に-1バイト制限すると、起こりうる問題は便利に4バイトの無記名の値を扱うことができない実現のために避けられます。 実際には、通常、塊はそれよりはるかにとにかく不足するでしょう。
Boutell, et. al. Informational [Page 77] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[77ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
A separate CRC is provided for each chunk in order to detect
badly-transferred images as quickly as possible. In particular,
critical data such as the image dimensions can be validated before
being used.
できるだけはやくひどくわたっているイメージを検出するために別々のCRCを各塊に提供します。 使用される前に特に、イメージの重要性などの批判的なデータを有効にすることができます。
The chunk length is excluded from the CRC so that the CRC can be
calculated as the data is generated; this avoids a second pass
over the data in cases where the chunk length is not known in
advance. Excluding the length from the CRC does not create any
extra risk of failing to discover file corruption, since if the
length is wrong, the CRC check will fail: the CRC will be computed
on the wrong set of bytes and then be tested against the wrong
value from the file.
塊の長さはデータが発生するときCRCについて計算できるようにCRCから除かれます。 これは塊の長さがあらかじめ知られていないケースの中のデータの上で2番目のパスを避けます。 CRCに長さを入れないようにするのはファイル不正を発見しないという少しの超過危険も作成しません、長さが間違っていると、CRCチェックが失敗するので: CRCは間違ったセットのバイトで計算されて、次に、間違った値に対してファイルからテストされるでしょう。
12.13. Chunk naming conventions
12.13. 塊命名規則
The chunk naming conventions allow safe, flexible extension of the
PNG format. This mechanism is much better than a format version
number, because it works on a feature-by-feature basis rather than
being an overall indicator. Decoders can process newer files if
and only if the files use no unknown critical features (as
indicated by finding unknown critical chunks). Unknown ancillary
chunks can be safely ignored. We decided against having an
overall format version number because experience has shown that
format version numbers hurt portability as much as they help.
Version numbers tend to be set unnecessarily high, leading to
older decoders rejecting files that they could have processed
(this was a serious problem for several years after the GIF89 spec
came out, for example). Furthermore, private extensions can be
made either critical or ancillary, and standard decoders should
react appropriately; overall version numbers are no help for
private extensions.
塊命名規則はPNG形式の安全で、フレキシブルな拡大を許します。 このメカニズムは形式バージョン番号よりはるかに良いです、むしろ総合的なインディケータであるより特徴ごとのベースに取り組むので。 そして、デコーダが、より新しいファイルを処理できる、ファイルがどんな未知のきわどい特徴も使用しない場合にだけ(未知の批判的な塊を見つけることによって示されるように)。 安全に未知の付属の塊を無視できます。 私たちは、経験が目立ったので総合的な形式バージョン番号を持たないように形式バージョン番号が携帯性に彼らが助けるのと同じくらいたくさん害を与えたと決めました。 バージョン番号は、不必要に高く設定される傾向があります、それらが処理したかもしれないファイルを拒絶するより古いデコーダに通じて(GIF89仕様が出て来た例えば、後に数年間これは深刻な問題でした)。 その上、個人的な拡大を批判的であるか付属にすることができます、そして、標準のデコーダは適切に反応するはずです。 総合的なバージョン番号は個人的な拡大のための助けではありません。
A hypothetical chunk for vector graphics would be a critical
chunk, since if ignored, important parts of the intended image
would be missing. A chunk carrying the Mandelbrot set coordinates
for a fractal image would be ancillary, since other applications
could display the image without understanding what the image
represents. In general, a chunk type should be made critical only
if it is impossible to display a reasonable representation of the
intended image without interpreting that chunk.
ベクタグラフィックスのための仮定している塊は重大な塊です、無視されるなら、意図しているイメージの重要な部分がなくなるでしょう、したがって。 フラクタルイメージのためにマンデルブローセット座標を運ぶ塊は付属でしょう、イメージが何を表すかを理解していない他のアプリケーションがイメージを表示するかもしれないので。 一般に、その塊を解釈しないで意図しているイメージの合理的な表現を表示するのが不可能である場合にだけ塊タイプを批判的にするべきです。
Boutell, et. al. Informational [Page 78] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[78ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
The public/private property bit ensures that any newly defined
public chunk type name cannot conflict with proprietary chunks
that could be in use somewhere. However, this does not protect
users of private chunk names from the possibility that someone
else may use the same chunk name for a different purpose. It is a
good idea to put additional identifying information at the start
of the data for any private chunk type.
公衆/私財ビットは、どんな新たに定義された公共の塊型名もどこかで使用中であるかもしれない独占塊と衝突できないのを確実にします。 しかしながら、これは他の誰かが異なる役割に同じ塊名を使用するかもしれない可能性から個人的な塊名のユーザを保護しません。 どんな個人的な塊タイプのためにもデータの始めに追加身元が分かる情報を置くのは、名案です。
When a PNG file is modified, certain ancillary chunks may need to
be changed to reflect changes in other chunks. For example, a
histogram chunk needs to be changed if the image data changes. If
the file editor does not recognize histogram chunks, copying them
blindly to a new output file is incorrect; such chunks should be
dropped. The safe/unsafe property bit allows ancillary chunks to
be marked appropriately.
PNGファイルが変更されているとき、ある付属の塊は、他の塊における変化を反映するために変えられる必要があるかもしれません。 例えば、イメージデータが変化するなら、ヒストグラム塊は、変えられる必要があります。 ファイルのエディタがヒストグラム塊を認めないなら、盲目的に新しい出力ファイルにそれらをコピーするのは不正確です。 そのような塊は落とされるべきです。 安全であるか危険な特性のビットは、付属の塊が適切にマークされるのを許容します。
Not all possible modification scenarios are covered by the
safe/unsafe semantics. In particular, chunks that are dependent
on the total file contents are not supported. (An example of such
a chunk is an index of IDAT chunk locations within the file:
adding a comment chunk would inadvertently break the index.)
Definition of such chunks is discouraged. If absolutely necessary
for a particular application, such chunks can be made critical
chunks, with consequent loss of portability to other applications.
In general, ancillary chunks can depend on critical chunks but not
on other ancillary chunks. It is expected that mutually dependent
information should be put into a single chunk.
すべての可能な変更シナリオが安全であるか危険な意味論でカバーされているというわけではありません。 特に、総ファイルコンテンツに依存する塊は支持されません。 (そのような塊に関する例はファイルの中のIDAT塊位置のインデックスです: コメント塊がうっかりインデックスを破ると言い足します。) そのような塊の定義はお勧めできないです。 特定用途に絶対に必要であるなら、そのような塊は人工の重大な塊であるかもしれません、他のアプリケーションへの携帯性の結果の損失で。 一般に、付属の塊は、批判的な塊によりますが、他の付属の塊に関して依存できません。 互いに依存する情報がただ一つの塊に入れられるべきであると予想されます。
In some situations it may be unavoidable to make one ancillary
chunk dependent on another. Although the chunk property bits are
insufficient to represent this case, a simple solution is
available: in the dependent chunk, record the CRC of the chunk
depended on. It can then be determined whether that chunk has
been changed by some other program.
いくつかの状況で、1つの付属の塊を別のものに依存するようにするのは避けられないかもしれません。 塊特性のビットは本件を表すためには不十分ですが、簡単な解決策は利用可能です: 依存する塊に、依存した塊のCRCを記録してください。 そして、ある他のプログラムでその塊を変えたかどうかが決定できます。
The same technique can be useful for other purposes. For example,
if a program relies on the palette being in a particular order, it
can store a private chunk containing the CRC of the PLTE chunk.
If this value matches when the file is again read in, then it
provides high confidence that the palette has not been tampered
with. Note that it is not necessary to mark the private chunk
unsafe-to-copy when this technique is used; thus, such a private
chunk can survive other editing of the file.
同じテクニックは他の目的の役に立つ場合があります。 例えば、プログラムが特定のオーダーにあるパレットを当てにするなら、それはPLTE塊のCRCを含む個人的な塊を格納できます。 再びファイルで読まれるとき、この値が合っているなら、それはパレットがいじられていないという高い信用を供給します。 このテクニックが使用されているときには個人的な塊がコピーするのが危険であるとマークするのは必要でないことに注意してください。 したがって、そのような個人的な塊はファイルの他の編集を乗り切ることができます。
Boutell, et. al. Informational [Page 79] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[79ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
12.14. Palette histograms
12.14. パレットヒストグラム
A viewer may not be able to provide as many colors as are listed
in the image's palette. (For example, some colors could be
reserved by a window system.) To produce the best results in this
situation, it is helpful to have information about the frequency
with which each palette index actually appears, in order to choose
the best palette for dithering or to drop the least-used colors.
Since images are often created once and viewed many times, it
makes sense to calculate this information in the encoder, although
it is not mandatory for the encoder to provide it.
ビューアーはイメージのパレットに記載されているのと同じくらい多くの色を提供できないかもしれません。 (例えば、ウィンドウシステムはいくつかの色を予約できました。) それぞれのパレットインデックスが実際に現れる頻度の情報を持っているのは役立っています、この状況で最も良い結果を生むならディザリングか最も最少に使用された色を落とすために最も良いパレットを選ぶために。 イメージがしばしば一度作成されて、何回も見られるので、エンコーダでこの情報について計算する意味になります、エンコーダがそれを提供するのが、義務的ではありませんが。
Other image formats have usually addressed this problem by
specifying that the palette entries should appear in order of
frequency of use. That is an inferior solution, because it
doesn't give the viewer nearly as much information: the viewer
can't determine how much damage will be done by dropping the last
few colors. Nor does a sorted palette give enough information to
choose a target palette for dithering, in the case that the viewer
needs to reduce the number of colors substantially. A palette
histogram provides the information needed to choose such a target
palette without making a pass over the image data.
パレットエントリーが頻度の順に役に立つように見えるべきであると指定することによって、通常、他の画像形式はこのその問題を訴えました。 ほとんど同じくらい多くの情報をビューアーに教えないので、それは劣った解決策です: ビューアーは、どのくらいの損害が最後のわずかな色を落とすことによって与えられるかを決心できません。 また、ビューアーが、色数をかなり減少させる必要があるので、分類されたパレットはディザリングのために目標パレットを選ぶことができるくらいの情報を教えません。 パレットヒストグラムはイメージデータの上でパスを作らないでそのような目標パレットを選ぶのに必要である情報を提供します。
Boutell, et. al. Informational [Page 80] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[80ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
13. Appendix: Gamma Tutorial
13. 付録: ガンマチュートリアル
(This appendix is not part of the formal PNG specification.)
(この付録は正式なPNG仕様の一部ではありません。)
It would be convenient for graphics programmers if all of the components of an imaging system were linear. The voltage coming from an electronic camera would be directly proportional to the intensity (power) of light in the scene, the light emitted by a CRT would be directly proportional to its input voltage, and so on. However, real-world devices do not behave in this way. All CRT displays, almost all photographic film, and many electronic cameras have nonlinear signal-to-light-intensity or intensity-to-signal characteristics.
イメージシステムの部品のすべてが直線的であるなら、グラフィックスプログラマは都合がよいでしょうに。 デジタルカメラから来る電圧が場面の光の強度(パワー)に正比例しているだろう、CRTによって放たれた光は入力電圧などに正比例しているでしょう。 しかしながら、本当の世界装置はこのように反応しません。 すべてのCRTディスプレイ、ほとんどすべての写真用フィルム、および多くのデジタルカメラには、非線形の信号から光強度か合図する強度の特性があります。
Fortunately, all of these nonlinear devices have a transfer function that is approximated fairly well by a single type of mathematical function: a power function. This power function has the general equation
幸い、これらの非線形の装置のすべてには、単独のタイプの数学の関数によってかなりよく近似されている伝達関数があります: べき関数。 このべき関数に、一般方程式があります。
output = input ^ gamma
出力は入力^ガンマと等しいです。
where ^ denotes exponentiation, and "gamma" (often printed using the Greek letter gamma, thus the name) is simply the exponent of the power function.
^が羃法を指示して、「ガンマ」(ギリシアの手紙ガンマ、その結果名前を使用することでしばしば印刷される)が単にべき関数の解説者であるところ。
By convention, "input" and "output" are both scaled to the range 0..1, with 0 representing black and 1 representing maximum white (or red, etc). Normalized in this way, the power function is completely described by a single number, the exponent "gamma".
コンベンションで、「入力され」て、「出力」であることは、範囲0に合わせて調整された両方です。1 0が黒を表していて、1が最大の白(または、赤など)を表していて。 このように正常にされて、べき関数は1つの数、解説者「ガンマ」によって完全に説明されます。
So, given a particular device, we can measure its output as a function of its input, fit a power function to this measured transfer function, extract the exponent, and call it gamma. We often say "this device has a gamma of 2.5" as a shorthand for "this device has a power-law response with an exponent of 2.5". We can also talk about the gamma of a mathematical transform, or of a lookup table in a frame buffer, so long as the input and output of the thing are related by the power-law expression above.
特定の装置を考えて、私たちは、入力の機能として出力を測定して、解説者を抽出して、この測定伝達関数にべき関数に合うので、それをガンマと呼ぶことができます。 私たちがしばしば言う、「この装置には、「この装置では、2.5インチの解説者との指数法則応答がある」速記として2.5インチのガンマがあります。 また、私たちは数学の変換、またはフレームバッファのルックアップ表のガンマに関して話すことができます、ものの入出力が上の指数法則表現で関係づけられる限り。
How do gammas combine?
ガンマはどのように結合しますか?
Real imaging systems will have several components, and more than
one of these can be nonlinear. If all of the components have
transfer characteristics that are power functions, then the
transfer function of the entire system is also a power function.
The exponent (gamma) of the whole system's transfer function is
just the product of all of the individual exponents (gammas) of
the separate stages in the system.
実際のイメージシステムには、数個のコンポーネントがあるでしょう、そして、これらの1つ以上は非線形である場合があります。 コンポーネントのすべてにべき関数である転送の特性があるなら、また、全体のシステムの伝達関数はべき関数です。 全体のシステムの伝達関数の解説者(ガンマ)はただシステムの別々のステージの個々の解説者(ガンマ)のすべての製品です。
Boutell, et. al. Informational [Page 81] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[81ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
Also, stages that are linear pose no problem, since a power
function with an exponent of 1.0 is really a linear function. So
a linear transfer function is just a special case of a power
function, with a gamma of 1.0.
また、直線的なステージは問題を全く引き起こしません、1.0の解説者があるべき関数が本当に一次関数であるので。 それで、直線的な伝達関数はただ1.0のガンマがあるべき関数の特別なケースです。
Thus, as long as our imaging system contains only stages with
linear and power-law transfer functions, we can meaningfully talk
about the gamma of the entire system. This is indeed the case
with most real imaging systems.
したがって、私たちのイメージシステムが直線的、そして、指数法則伝達関数があるステージだけを含んでいる限り、私たちは全体のシステムのガンマに関して意味深長に話すことができます。 本当に、これはほとんどの実際のイメージシステムがあるそうです。
What should overall gamma be?
総合的なガンマは何であるべきですか?
If the overall gamma of an imaging system is 1.0, its output is
linearly proportional to its input. This means that the ratio
between the intensities of any two areas in the reproduced image
will be the same as it was in the original scene. It might seem
that this should always be the goal of an imaging system: to
accurately reproduce the tones of the original scene. Alas, that
is not the case.
イメージシステムの総合的なガンマが1.0であるなら、出力は入力に比例している直線的です。 それが元の場面にあったとき、これは、再生しているイメージによるどんな2つの領域の強度の間の比率が同じになることを意味します。 これがいつもイメージシステムの目標であるべきであるように思えるかもしれません: 元の場面のトーンを正確に再生させるために。 ああ、それはそうではありません。
When the reproduced image is to be viewed in "bright surround"
conditions, where other white objects nearby in the room have
about the same brightness as white in the image, then an overall
gamma of 1.0 does indeed give real-looking reproduction of a
natural scene. Photographic prints viewed under room light and
computer displays in bright room light are typical "bright
surround" viewing conditions.
再生しているイメージが「明るい取り囲むもの」状態(部屋の近くの他の白い物体で、ほぼ同じくらいの明るさはイメージで白くなる)で見られることであるなら、本当に、1.0の総合的なガンマは自然の情景の本当に見える再現を与えます。 明るい部屋光でルーム・ランプとコンピュータのディスプレイで見られた写真の印画は典型的な「明るい取り囲むもの」見る状態です。
However, sometimes images are intended to be viewed in "dark
surround" conditions, where the room is substantially black except
for the image. This is typical of the way movies and slides
(transparencies) are viewed by projection. Under these
circumstances, an accurate reproduction of the original scene
results in an image that human viewers judge as "flat" and lacking
in contrast. It turns out that the projected image needs to have
a gamma of about 1.5 relative to the original scene for viewers to
judge it "natural". Thus, slide film is designed to have a gamma
of about 1.5, not 1.0.
しかしながら、時々、「暗い取り囲むもの」状態でイメージは見られるつもりです。(そこでは、イメージを除いて、部屋が実質的に黒いです)。 これは映画とスライド(透明)が映像によって見られる方法の典型です。 こういう事情ですから、元の場面の正確な再現は対照的に、人間のビューアーが同じくらい「平坦で」同じくらい欠いていると判断するイメージをもたらします。 ビューアーが、それが「自然である」と判断するように映像が元の場面に比例しておよそ1.5のガンマを必要とすると判明します。 したがって、スライドフィルムは、1.0ではなくおよそ1.5のガンマを持つように設計されています。
There is also an intermediate condition called "dim surround",
where the rest of the room is still visible to the viewer, but is
noticeably darker than the reproduced image itself. This is
typical of television viewing, at least in the evening, as well as
subdued-light computer work areas. In dim surround conditions,
the reproduced image needs to have a gamma of about 1.25 relative
to the original scene in order to look natural.
また、「薄暗い取り囲むもの」と呼ばれる中間的状態があります。そこでは、部屋の残りは、ビューアーにとってまだ目に見えていますが、再生しているイメージ自体より顕著に暗いです。 これは少なくとも晩、および柔らかい光コンピュータ作業領域でテレビ鑑賞の典型です。 薄暗い取り囲むもの状態で、再生しているイメージは、自然に見えるために元の場面に比例しておよそ1.25のガンマを必要とします。
Boutell, et. al. Informational [Page 82] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[82ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
The requirement for boosted contrast (gamma) in dark surround
conditions is due to the way the human visual system works, and
applies equally well to computer monitors. Thus, a PNG viewer
trying to achieve the maximum realism for the images it displays
really needs to know what the room lighting conditions are, and
adjust the gamma of the displayed image accordingly.
暗い取り囲むもの状態の上げられたコントラスト(ガンマ)のための要件は人間の視覚体系が等しくよくコンピュータ用モニターに扱って、当てはまる道のためです。 したがって、それが表示するイメージのために最大のリアリズムを達成しようとするPNGビューアーは、本当に余地の照明状態が何であるかを知って、それに従って、表示されたイメージのガンマを調整する必要があります。
If asking the user about room lighting conditions is inappropriate
or too difficult, just assume that the overall gamma
(viewing_gamma as defined below) should be 1.0 or 1.25. That's
all that most systems that implement gamma correction do.
余地の照明状態に関してユーザに尋ねるのが不適当であるか、または難し過ぎるなら、総合的なガンマ(以下で定義されるように_ガンマを見る)が1.0か1.25であるべきであるとちょっと仮定してください。 それはガンマ修正を実行するほとんどのシステムがそうするすべてです。
What is a CRT's gamma?
CRTのガンマは何ですか?
All CRT displays have a power-law transfer characteristic with a
gamma of about 2.5. This is due to the physical processes
involved in controlling the electron beam in the electron gun, and
has nothing to do with the phosphor.
すべてのCRTディスプレイで、指数法則転送はおよそ2.5のガンマで独特になります。 これは、電子銃で電子ビームを制御するのにかかわる自然現象のためにあって、燐光体と関係ありません。
An exception to this rule is fancy "calibrated" CRTs that have
internal electronics to alter their transfer function. If you
have one of these, you probably should believe what the
manufacturer tells you its gamma is. But in all other cases,
assuming 2.5 is likely to be pretty accurate.
この規則への例外はそれらの伝達関数を変更する内部のエレクトロニクスがある高級「較正された」CRTです。 これらの1つがありましたらあなたはたぶんなにかを信じるべきであるか。メーカーは、ガンマがそうであるとあなたに言います。 しかし、他のすべての場合では、2.5を仮定するのはかなり正確である傾向があります。
There are various images around that purport to measure gamma,
usually by comparing the intensity of an area containing
alternating white and black with a series of areas of continuous
gray of different intensity. These are usually not reliable.
Test images that use a "checkerboard" pattern of black and white
are the worst, because a single white pixel will be reproduced
considerably darker than a large area of white. An image that
uses alternating black and white horizontal lines (such as the
"gamma.png" test image at
ftp://ftp.uu.net/graphics/png/images/suite/gamma.png) is much
better, but even it may be inaccurate at high "picture" settings
on some CRTs.
ガンマを測定するために、その趣旨の周りに様々なイメージがあります、通常、交互の白と黒を含む領域の強度を異なった強度の連続したグレーの一連の領域にたとえることによって。 通常、これらは信頼できません。 白黒の「チェッカー盤」パターンを使用するテストイメージは最も悪いです、1白い画素が白の広い地域よりかなり暗い状態で再生するので。 交互の白黒の水平な線( ftp://ftp.uu.net/graphics/png/images/suite/gamma.png の"gamma.png"テストイメージなどの)を使用するイメージははるかに良いのですが、それさえいくつかのCRTで高い「絵」設定で不正確であるかもしれません。
If you have a good photometer, you can measure the actual light
output of a CRT as a function of input voltage and fit a power
function to the measurements. However, note that this procedure
is very sensitive to the CRT's black level adjustment, somewhat
sensitive to its picture adjustment, and also affected by ambient
light. Furthermore, CRTs spread some light from bright areas of
an image into nearby darker areas; a single bright spot against a
black background may be seen to have a "halo". Your measuring
technique will need to minimize the effects of this.
良い露出計がありましたら、あなたは、入力電圧の関数としてCRTの実際の光熱出力を測定して、測定値にべき関数に合うことができます。 しかしながら、この手順がCRTの黒レベル調整に非常に敏感であって、絵の調整にいくらか敏感であり、また、周囲の光で影響を受けることに注意してください。 その上、CRTはいくらかの光をイメージの明るい領域から近いより暗い領域に広げます。 黒いバックグラウンドに対する単一の明るい場所は「光輪」を持っているのを見られるかもしれません。 あなたの測定のテクニックは、この効果を最小にする必要があるでしょう。
Boutell, et. al. Informational [Page 83] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[83ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
Because of the difficulty of measuring gamma, using either test
images or measuring equipment, you're usually better off just
assuming gamma is 2.5 rather than trying to measure it.
テストイメージか測定設備のどちらかを使用して、ガンマを測定するという困難のために、通常、あなたは、ガンマがそれを測定しようとするよりむしろ2.5であるとただ仮定しているほうがよいです。
What is gamma correction?
ガンマ修正は何ですか?
A CRT has a gamma of 2.5, and we can't change that. To get an
overall gamma of 1.0 (or somewhere near that) for an imaging
system, we need to have at least one other component of the "image
pipeline" that is nonlinear. If, in fact, there is only one
nonlinear stage in addition to the CRT, then it's traditional to
say that the CRT has a certain gamma, and that the other nonlinear
stage provides "gamma correction" to compensate for the CRT.
However, exactly where the "correction" is done depends on
circumstance.
CRTには、2.5のガンマがあります、そして、私たちがそれを変えることができません。 イメージシステムのために1.0(それの近くのどこか)の総合的なガンマを得るために、私たちは非線形の「イメージパイプライン」の他の少なくとも1つのコンポーネントを必要とします。 1つの非線形のステージしか事実上CRTに加えていなければ、CRTには、あるガンマがあって、もう片方の非線形のステージがCRTを補うために「ガンマ修正」を提供すると言うのが伝統的です。 しかしながら、ちょうどどこで「修正」をするかは状況に依存します。
In all broadcast video systems, gamma correction is done in the
camera. This choice was made in the days when television
electronics were all analog, and a good gamma-correction circuit
was expensive to build. The original NTSC video standard required
cameras to have a transfer function with a gamma of 1/2.2, or
about 0.45. Recently, a more complex two-part transfer function
has been adopted [SMPTE-170M], but its behavior can be well
approximated by a power function with a gamma of 0.5. When the
resulting image is displayed on a CRT with a gamma of 2.5, the
image on screen ends up with a gamma of about 1.25 relative to the
original scene, which is appropriate for "dim surround" viewing.
すべての放送ビデオシステムでは、カメラでガンマ修正をします。 この選択はテレビのエレクトロニクスであることの数日に作られているのが、すべて、アナログであり、良いガンマ補正回路が建てるために高価であったということでした。 元のNTSCビデオ規格は、カメラにはおよそ1/2.2、または0.45のガンマがある伝達関数があるのを必要としました。 最近、より複雑な2部分の伝達関数は採用されましたが[SMPTE-170M]、0.5のガンマがあるべき関数で振舞いによく近似できます。 2.5のガンマがあるCRTに結果として起こるイメージを表示するとき、イメージはスクリーンの上で元の場面に比例しておよそ1.25のガンマで終わります。「薄暗い取り囲むもの」の見るのに、場面は適切です。
These days, video signals are often digitized and stored in
computer frame buffers. This works fine, but remember that gamma
correction is "built into" the video signal, and so the digitized
video has a gamma of about 0.5 relative to the original scene.
最近、ビデオ信号は、コンピュータフレームバッファにしばしばデジタル化されて、収納されます。 ビデオ信号がガンマ修正に「組み込まれる」ので元の場面に比例してデジタル化しているビデオにはおよそ0.5のガンマがあるのを覚えているのを除いて、これはきめ細かに働いています。
Computer rendering programs often produce linear samples. To
display these correctly, intensity on the CRT needs to be directly
proportional to the sample values in the frame buffer. This can
be done with a special hardware lookup table between the frame
buffer and the CRT hardware. The lookup table (often called LUT)
is loaded with a mapping that implements a power function with a
gamma of 0.4, thus providing "gamma correction" for the CRT gamma.
コンピュータ表現プログラムはしばしば直線的なサンプルを作り出します。 正しくこれらを表示するために、CRTの強度は、フレームバッファの標本値に正比例している必要があります。 これは、フレームバッファの間には、特別なハードウェアルックアップ表がある状態でしていてCRTハードウェアであるかもしれません。 ルックアップ表(しばしばLUTと呼ばれる)を0.4のガンマでべき関数を実行するマッピングに積みます、その結果、CRTガンマのための「ガンマ修正」を提供します。
Thus, gamma correction sometimes happens before the frame buffer,
sometimes after. As long as images created in a particular
environment are always displayed in that environment, everything
is fine. But when people try to exchange images, differences in
gamma correction conventions often result in images that seem far
too bright and washed out, or far too dark and contrasty.
したがって、ガンマ修正はフレームバッファの前で時々時々後に起こります。 その環境で特定の環境で作成されたイメージをいつも表示する限り、すべてがすばらしいです。 しかし、人々がイメージを交換しようとするとき、ガンマ補正コンベンションの違いははるかに明るく見え過ぎて、洗い落とされたイメージ、または遠くにしばしば暗過ぎて、コントラストが強い状態で結果として生じます。
Boutell, et. al. Informational [Page 84] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[84ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
Gamma-encoded samples are good
ガンマでコード化されたサンプルは良いです。
So, is it better to do gamma correction before or after the frame
buffer?
それで、フレームバッファの前または後にガンマ修正をするのは、より良いですか?
In an ideal world, sample values would be stored in floating
point, there would be lots of precision, and it wouldn't really
matter much. But in reality, we're always trying to store images
in as few bits as we can.
理想の世界では、標本値が浮動小数点に格納されるでしょう、そして、多くの精度があるでしょう、そして、それが本当にあまり重要でないでしょう。 しかし、ほんとうは、私たちはできるだけ数ビットにイメージをいつも格納しようとしています。
If we decide to use samples that are linearly proportional to
intensity, and do the gamma correction in the frame buffer LUT, it
turns out that we need to use at least 12 bits for each of red,
green, and blue to have enough precision in intensity. With any
less than that, we will sometimes see "contour bands" or "Mach
bands" in the darker areas of the image, where two adjacent sample
values are still far enough apart in intensity for the difference
to be visible.
私たちが強度に比例している直線的であるサンプルを使用して、フレームバッファLUTのガンマ補正をすると決めるなら、私たちが、強度における十分な精度を持つのにそれぞれの赤、緑色、および青に少なくとも12ビットを使用する必要であると判明します。 それどんな以下でも、私たちは、違いが目に見えるように時々「バンドに輪郭を描かせてください」2つの隣接している標本値がまだはるかに十分であるイメージの、より暗い領域で強度で離れて「マッハは組になること」がわかるでしょう。
However, through an interesting coincidence, the human eye's
subjective perception of brightness is related to the physical
stimulation of light intensity in a manner that is very much like
the power function used for gamma correction. If we apply gamma
correction to measured (or calculated) light intensity before
quantizing to an integer for storage in a frame buffer, we can get
away with using many fewer bits to store the image. In fact, 8
bits per color is almost always sufficient to avoid contouring
artifacts. This is because, since gamma correction is so closely
related to human perception, we are assigning our 256 available
sample codes to intensity values in a manner that approximates how
visible those intensity changes are to the eye. Compared to a
linear-sample image, we allocate fewer sample values to brighter
parts of the tonal range and more sample values to the darker
portions of the tonal range.
しかしながら、おもしろい偶然の一致を通して、人の目の明るさの主観的な認知はガンマ修正に使用されるべき関数に似ている方法における、光強度の物理的な刺激に関連します。 整数への量子化する前に格納のためにフレームバッファで測定されて(計算される)の光強度にガンマ修正を適用するなら、私たちは、イメージを格納するのに多くの、より少ないビットを使用するのをうまくやることができます。 事実上、1色あたり8ビットは、人工物に輪郭を描かせるのを避けるためにほとんどいつも十分です。 目には強度が変える目に見えるものがどうあるかに近似する方法でガンマ修正が非常に密接に人間の知覚に関連するので私たちが256の利用可能なサンプルコードを強度値に割り当てるのが、これの理由です。 直線的なサンプルイメージと比べて、私たちは色調の範囲の、より明るい地域への、より少ない標本値と色調の範囲の、より暗い部分への、より多くの標本値を割り当てます。
Thus, for the same apparent image quality, images using gamma-
encoded sample values need only about two-thirds as many bits of
storage as images using linear samples.
したがって、同じ見かけの画質のために、ガンマのコード化された標本値を使用するイメージは、直線的なサンプルを使用することで格納のイメージとおよそ2/3だけ同じくらい多くのビットを必要とします。
Boutell, et. al. Informational [Page 85] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[85ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
General gamma handling
一般ガンマ取り扱い
When more than two nonlinear transfer functions are involved in
the image pipeline, the term "gamma correction" becomes too vague.
If we consider a pipeline that involves capturing (or calculating)
an image, storing it in an image file, reading the file, and
displaying the image on some sort of display screen, there are at
least 5 places in the pipeline that could have nonlinear transfer
functions. Let's give each a specific name for their
characteristic gamma:
2つ以上の非線形の伝達関数がイメージパイプラインにかかわるとき、「ガンマ補正」という用語はあいまいになり過ぎます。 私たちがパイプラインを考えるなら、それは、イメージを得ることを(または、計算します)伴います、イメージ・ファイルにそれを格納して、ある種のディスプレイの画面にファイルを読んで、イメージを表示して少なくとも5つの場所が非線形の伝達関数を持つことができたパイプラインにあります。 それらの独特のガンマのために種名をそれぞれに与えましょう:
camera_gamma
the characteristic of the image sensor
カメラ_ガンマはイメージセンサの特性です。
encoding_gamma
the gamma of any transformation performed by the software
writing the image file
_ガンマをコード化して、どんな変化のガンマも、イメージ・ファイルを書きながら、ソフトウェアで働きました。
decoding_gamma
the gamma of any transformation performed by the software
reading the image file
_ガンマを解読して、どんな変化のガンマも、イメージ・ファイルを読みながら、ソフトウェアで働きました。
LUT_gamma
the gamma of the frame buffer LUT, if present
LUT_ガンマ、存在しているなら、フレームのガンマはLUTをバッファリングします。
CRT_gamma
the gamma of the CRT, generally 2.5
CRT_ガンマはCRT、一般に2.5のガンマです。
In addition, let's add a few other names:
さらに、他のいくつかの名前を加えましょう:
file_gamma
the gamma of the image in the file, relative to the original
scene. This is
_ガンマをファイルしてください。元の場面に比例したファイルのイメージのガンマ。 これはそうです。
file_gamma = camera_gamma * encoding_gamma
_ガンマをコード化するファイル_ガンマ=カメラ_ガンマ*
display_gamma
the gamma of the "display system" downstream of the frame
buffer. This is
_フレームの「ディスプレイ・システム」川下のガンマがバッファリングするガンマを表示してください。 これはそうです。
display_gamma = LUT_gamma * CRT_gamma
表示_ガンマ=LUT_ガンマ*CRT_ガンマ
viewing_gamma
the overall gamma that we want to obtain to produce pleasing
images --- generally 1.0 to 1.5.
_ガンマを見て、そうしたいと思う総合的なガンマは微笑ましいイメージを生産物として得ます。--- 一般に1.0〜1.5。
Boutell, et. al. Informational [Page 86] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[86ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
The file_gamma value, as defined above, is what goes in the gAMA
chunk in a PNG file. If file_gamma is not 1.0, we know that gamma
correction has been done on the sample values in the file, and we
could call them "gamma corrected" samples. However, since there
can be so many different values of gamma in the image display
chain, and some of them are not known at the time the image is
written, the samples are not really being "corrected" for a
specific display condition. We are really using a power function
in the process of encoding an intensity range into a small integer
field, and so it is more correct to say "gamma encoded" samples
instead of "gamma corrected" samples.
上で定義されるファイル_ガンマ値はPNGファイルのgAMA塊に入ることです。 ファイル_ガンマが1.0でないなら、私たちは、ファイルの標本値でガンマ修正をしたのを知っています、そして、それらを「ガンマ直っている」サンプルと呼ぶことができました。 しかしながら、画像表示チェーンにおける、ガンマのとても多くの異価があることができて、イメージが書かれているときそれらのいくつかが知られていないので、サンプルは特定の表示状態のために本当に「修正されていません」。 小さい整数分野に強度範囲をコード化することの途中に私たちが本当にべき関数を使用しているので、「ガンマ直っている」サンプルの代わりに「コード化されたガンマ」サンプルを示すのは、より正しいです。
When displaying an image file, the image decoding program is
responsible for making the overall gamma of the system equal to
the desired viewing_gamma, by selecting the decoding_gamma
appropriately. When displaying a PNG file, the gAMA chunk
provides the file_gamma value. The display_gamma may be known for
this machine, or it might be obtained from the system software, or
the user might have to be asked what it is. The correct
viewing_gamma depends on lighting conditions, and that will
generally have to come from the user.
イメージ・ファイルを表示するとき、イメージ解読プログラムはシステムの総合的なガンマを必要な見る_ガンマと等しくするのに原因となります、適切に解読_ガンマを選択することによって。 PNGファイルを表示するとき、gAMA塊はファイル_ガンマ値を提供します。 このマシンで表示_ガンマを知っているかもしれませんか、システムソフトからそれを得るかもしれませんか、またはそれが何であるかをユーザを尋ねなければならないかもしれません。 正しい見る_ガンマは照明条件によります、そして、一般に、それはユーザから来なければならないでしょう。
Ultimately, you should have
結局、あなたはそうするべきでした。
file_gamma * decoding_gamma * display_gamma = viewing_gamma
_ガンマを見るファイル_ガンマ*解読_ガンマ*表示_ガンマ=
Some specific examples
いくつかの特定の例
In digital video systems, camera_gamma is about 0.5 by declaration
of the various video standards documents. CRT_gamma is 2.5 as
usual, while encoding_gamma, decoding_gamma, and LUT_gamma are all
1.0. As a result, viewing_gamma ends up being about 1.25.
デジタルビデオシステムでは、様々なビデオ規格文書の宣言によってカメラ_ガンマはおよそ0.5です。 _ガンマを解読して、_ガンマをコード化している間、CRT_ガンマはいつものように2.5です、そして、LUT_ガンマはすべて1.0です。 その結果、結局、_ガンマを見るのは、およそ1.25です。
On frame buffers that have hardware gamma correction tables, and
that are calibrated to display linear samples correctly,
display_gamma is 1.0.
ハードウェアガンマ補正テーブルを持って、正しく直線的なサンプルを表示するために較正されるフレームバッファの上では、表示_ガンマは1.0です。
Many workstations and X terminals and PC displays lack gamma
correction lookup tables. Here, LUT_gamma is always 1.0, so
display_gamma is 2.5.
多くのワークステーション、Xターミナル、およびPC表示はガンマ補正ルックアップ表を欠いています。 いつもLUT_ガンマがここの、1.0であるので、表示_ガンマは2.5です。
Boutell, et. al. Informational [Page 87] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[87ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
On the Macintosh, there is a LUT. By default, it is loaded with a
table whose gamma is about 0.72, giving a display_gamma (LUT and
CRT combined) of about 1.8. Some Macs have a "Gamma" control
panel that allows gamma to be changed to 1.0, 1.2, 1.4, 1.8, or
2.2. These settings load alternate LUTs that are designed to give
a display_gamma that is equal to the label on the selected button.
Thus, the "Gamma" control panel setting can be used directly as
display_gamma in decoder calculations.
マッキントッシュの上に、LUTがあります。 デフォルトで、ガンマがおよそ0.72であるテーブルにそれを積みます、およそ1.8の表示_ガンマ(結合されたLUTとCRT)を与えて。 いくつかのMacsがガンマが1.0、1.2、1.4、1.8、または2.2に変化する「ガンマ」コントロールパネルを持っています。 これらの設定は選択されたボタンの上のラベルと等しい表示_ガンマを与えるように設計されている交互のLUTsを積み込みます。 したがって、直接表示_ガンマとしてデコーダ計算に「ガンマ」コントロールパネル設定を使用できます。
On recent SGI systems, there is a hardware gamma-correction table
whose contents are controlled by the (privileged) "gamma" program.
The gamma of the table is actually the reciprocal of the number
that "gamma" prints, and it does not include the CRT gamma. To
obtain the display_gamma, you need to find the SGI system gamma
(either by looking in a file, or asking the user) and then
calculating
最近のSGIシステムの上に、コンテンツが(特権がある)の「ガンマ」プログラムで制御されるハードウェアガンマ補正テーブルがあります。 テーブルのガンマは実際に「ガンマ」が印刷する数の逆数です、そして、それはCRTガンマを含んでいません。 表示_ガンマを得るのに、あなたは、SGIシステムガンマ(ファイルの中を見るか、またはユーザに尋ねるのによる)を見つけて、次に、計算を見つける必要があります。
display_gamma = 2.5 / SGI_system_gamma
表示_ガンマ=2.5 / SGI_システム_ガンマ
You will find SGI systems with the system gamma set to 1.0 and 2.2
(or higher), but the default when machines are shipped is 1.7.
あなたは、システムガンマがあるSGIシステムが1.0と2.2(より高い)にセットしたのがわかるでしょうが、マシンを出荷するとき、デフォルトは1.7です。
A note about video gamma
ビデオガンマに関する注
The original NTSC video standards specified a simple power-law
camera transfer function with a gamma of 1/2.2 or 0.45. This is
not possible to implement exactly in analog hardware because the
function has infinite slope at x=0, so all cameras deviated to
some degree from this ideal. More recently, a new camera transfer
function that is physically realizable has been accepted as a
standard [SMPTE-170M]. It is
元のNTSCビデオ規格は1/2.2か0.45のガンマで簡単な指数法則カメラ伝達関数を指定しました。 機能がx=0に無限のスロープを持っているので、これがちょうどアナログのハードウェアで実行するのにおいて可能でないので、すべてのカメラがこの理想からある程度逸れました。 より最近、物理的に実現可能な新しいカメラ伝達関数は規格[SMPTE-170M]として認められました。 それはそうです。
Vout = 4.5 * Vin if Vin < 0.018
Vout = 1.099 * (Vin^0.45) - 0.099 if Vin >= 0.018
ヴィン>が0.018と等しいならヴィン<0.018Voutが*(ヴィン^0.45)--0.099に1.099と等しいなら、Voutは4.5*ヴィンと等しいです。
where Vin and Vout are measured on a scale of 0 to 1. Although
the exponent remains 0.45, the multiplication and subtraction
change the shape of the transfer function, so it is no longer a
pure power function. If you want to perform extremely precise
calculations on video signals, you should use the expression above
(or its inverse, as required).
ヴィンとVoutが0〜1のスケールで測定されるところ。 解説者が0.45のままで残っていますが、乗法と引き算が伝達関数の形を変えるので、それはもう純粋なべき関数ではありません。 非常に正確な計算をビデオ信号に実行したいなら、あなたが上の表現を使用するべきである、(または、逆、必要に応じて)
However, PNG does not provide a way to specify that an image uses
this exact transfer function; the gAMA chunk always assumes a pure
power-law function. If we plot the two-part transfer function
above along with the family of pure power functions, we find that
a power function with a gamma of about 0.5 to 0.52 (not 0.45) most
closely approximates the transfer function. Thus, when writing a
しかしながら、PNGはイメージがこの正確な伝達関数を使用すると指定する方法を提供しません。 gAMA塊はいつも純粋な指数法則機能を仮定します。 純粋なべき関数の家族に伴う上の2部分の伝達関数をプロットするなら、私たちは、およそ0.5〜0.52(0.45でない)のガンマがあるべき関数が最も密接に伝達関数に近似するのがわかりました。 その結果、いつがaを書くか。
Boutell, et. al. Informational [Page 88] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[88ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
PNG file with data obtained from digitizing the output of a modern
video camera, the gAMA chunk should contain 0.5 or 0.52, not 0.45.
The remaining difference between the true transfer function and
the power function is insignificant for almost all purposes. (In
fact, the alignment errors in most cameras are likely to be larger
than the difference between these functions.) The designers of
PNG deemed the simplicity and flexibility of a power-law
definition of gAMA to be more important than being able to
describe the SMPTE-170M transfer curve exactly.
近代的なビデオカメラの出力をデジタル化するのからデータを得ているPNGファイル、gAMA塊は0.5か0.52を含むべきです、0.45でない。 本当の伝達関数とべき関数の残っている違いはほとんどすべての目的のためにわずかです。 (事実上、ほとんどのカメラの整列誤りはこれらの機能の違いより大きい傾向があります。) PNGのデザイナーは、gAMAの指数法則定義の簡単さと柔軟性がまさにSMPTE-170Mの転送カーブについて説明できる存在より重要であると考えました。
The PAL and SECAM video standards specify a power-law camera
transfer function with a gamma of 1/2.8 or 0.36 --- not the 1/2.2
of NTSC. However, this is too low in practice, so real cameras
are likely to have their gamma set close to NTSC practice. Just
guessing 0.45 or 0.5 is likely to give you viewable results, but
if you want precise values you'll probably have to measure the
particular camera.
PALとSECAMビデオ規格は1/2.8か0.36のガンマで指数法則カメラ伝達関数を指定します。--- 1/2.2のNTSCでない。 しかしながら、これは実際には低過ぎます、非常に本当であるので、カメラはNTSC習慣の近くにそれらのガンマを設定させそうです。 0.45か0.5があなたを見えているのに与えそうであるとただ推測するのが結果として生じますが、正確な値が欲しいなら、あなたはたぶん特定のカメラを測定しなければならないでしょう。
Further reading
一層の読書
If you have access to the World Wide Web, read Charles Poynton's
excellent "Gamma FAQ" [GAMMA-FAQ] for more information about
gamma.
WWWに近づく手段を持っているなら、ガンマに関する詳しい情報のために、Poyntonの素晴らしい「ガンマFAQ」[GAMMA-FAQ]をチャールズに読み込んでください。
14. Appendix: Color Tutorial
14. 付録: 色のチュートリアル
(This appendix is not part of the formal PNG specification.)
(この付録は正式なPNG仕様の一部ではありません。)
About chromaticity
色度に関して
The cHRM chunk is used, together with the gAMA chunk, to convey
precise color information so that a PNG image can be displayed or
printed with better color fidelity than is possible without this
information. The preceding chapters state how this information is
encoded in a PNG image. This tutorial briefly outlines the
underlying color theory for those who might not be familiar with
it.
cHRM塊は、この情報なしで可能であるより良い色の信義でPNGイメージを表示するか、または印刷できるように正確な色彩の情報を運ぶのにgAMA塊と共に使用されます。 先の章はこの情報がPNGイメージでどうコード化されるかを述べます。 このチュートリアルはそれになじみ深くないかもしれないそれらのために簡潔に基本的な色の理論について概説します。
Note that displaying an image with incorrect gamma will produce
much larger color errors than failing to use the chromaticity
data. First be sure the monitor set-up and gamma correction are
right, then worry about chromaticity.
不正確なガンマがあるイメージを表示すると色度データを使用しないよりはるかに大きい色の誤りが起こされることに注意してください。 まず最初に、モニターセットアップとガンマ補正が正しいのを確認してください、そして、次に、色度に心配してください。
The problem
問題
The color of an object depends not only on the precise spectrum of
light emitted or reflected from it, but also on the observer ---
their species, what else they can see at the same time, even what
物の色はそれから放たれているか、または反射する光の正確なスペクトルに頼るだけではなく、観察者にも頼っています。--- それらの種、それらが見ることさえできる他の何、何
Boutell, et. al. Informational [Page 89] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[89ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
they have recently looked at! Furthermore, two very different
spectra can produce exactly the same color sensation. Color is
not an objective property of real-world objects; it is a
subjective, biological sensation. However, by making some
simplifying assumptions (such as: we are talking about human
vision) it is possible to produce a mathematical model of color
and thereby obtain good color accuracy.
見られて、それらは最近、そうしました! その上、2つの非常に異なったスペクトルがまさに同じ色感覚を発生させることができます。 色は本当の世界物の客観的な特性ではありません。 それは主観的で、生物学的な感覚です。 しかしながら、仮定を簡素化しながら(: 私たちはそのようですが)いくつかを作ることによって、色の数学的モデルを作成して、その結果、良い色の精度を得るのは可能です。
Device-dependent color
装置依存する色
Display the same RGB data on three different monitors, side by
side, and you will get a noticeably different color balance on
each display. This is because each monitor emits a slightly
different shade and intensity of red, green, and blue light. RGB
is an example of a device-dependent color model --- the color you
get depends on the device. This also means that a particular
color --- represented as say RGB 87, 146, 116 on one monitor ---
might have to be specified as RGB 98, 123, 104 on another to
produce the same color.
3つの異なったモニターに関する同じRGBデータを並んで表示してください。そうすれば、あなたは各表示の上の顕著に異なった色の残額を到着させるでしょう。 これは各モニターが赤くて、緑色の、そして、青い光のわずかに異なった日陰と強度を放つからです。 RGBは装置依存するカラーモデルに関する例です。--- あなたが得る色は装置に依存します。 また、これは、事項が着色することを意味します。--- 1つのモニターの上でRGB87、146、116を言うとき、表されます。--- 同じ色を発生させるようにRGB98、123、104として別のもので指定されるために持っているかもしれません。
Device-independent color
装置から独立している色
A full physical description of a color would require specifying
the exact spectral power distribution of the light source.
Fortunately, the human eye and brain are not so sensitive as to
require exact reproduction of a spectrum. Mathematical, device-
independent color models exist that describe fairly well how a
particular color will be seen by humans. The most important
device-independent color model, to which all others can be
related, was developed by the International Lighting Committee
(CIE, in French) and is called XYZ.
色の完全な物理的性質は、正確なスペクトル配電を指定するのを光源を要求するでしょう。 幸い、人の目と脳はスペクトルの正確な再現を必要とするくらいには敏感ではありません。 数学であり、特定の色が人間によってどのように見られるかをかなりよく説明する装置の独立しているカラーモデルが存在しています。 最も重要な装置から独立しているカラーモデル(すべての他のものを関係づけることができる)は、国際Lighting Committee(フランス語のCIE)によって開発されて、XYZと呼ばれます。
In XYZ, X is the sum of a weighted power distribution over the
whole visible spectrum. So are Y and Z, each with different
weights. Thus any arbitrary spectral power distribution is
condensed down to just three floating point numbers. The weights
were derived from color matching experiments done on human
subjects in the 1920s. CIE XYZ has been an International Standard
since 1931, and it has a number of useful properties:
XYZでは、Xは全体の可視スペクトルの上の荷重している配電の合計です。 それぞれ異なった重りがあるYとZもそうです。 したがって、どんな任意のスペクトル配電もちょうど3つの浮動小数点まで凝縮します。 1920年代に人間の問題に関して行われた実験に合っている色から重りを得ました。 1931年以来CIE XYZは国際規格です、そして、それには、多くの役に立つ特性があります:
* two colors with the same XYZ values will look the same to
humans
* two colors with different XYZ values will not look the same
* the Y value represents all the brightness information
(luminance)
* the XYZ color of any object can be objectively measured
* 同じくらいがある値が異なったXYZと共に同じように人間*2つの色まで見えるXYZがYが評価する同じ*に見えないのを評価する2つの色が*どんな物のXYZ色も客観的に測定できるというすべての明るさ情報(輝度)を表します。
Boutell, et. al. Informational [Page 90] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[90ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
Color models based on XYZ have been used for many years by people
who need accurate control of color --- lighting engineers for film
and TV, paint and dyestuffs manufacturers, and so on. They are
thus proven in industrial use. Accurate, device-independent color
started to spread from high-end, specialized areas into the
mainstream during the late 1980s and early 1990s, and PNG takes
notice of that trend.
XYZに基づくカラーモデルは何年間も色の正確なコントロールを必要とする人々によって使用されています。--- フィルム、テレビ、塗料、染料メーカーなどのために技術者を点灯します。 それらは工業用でこのようにして立証されます。 正確です、装置から独立している色は上位から広まり始めました、1980年代後半の間の主流と1990年代前半への専門化している領域、そして、PNGはその傾向に注意を払います。
Calibrated, device-dependent color
較正されて、装置依存する色
Traditionally, image file formats have used uncalibrated, device-
dependent color. If the precise details of the original display
device are known, it becomes possible to convert the device-
dependent colors of a particular image to device-independent ones.
Making simplifying assumptions, such as working with CRTs (which
are much easier than printers), all we need to know are the XYZ
values of each primary color and the CRT_gamma.
伝統的に、画像ファイル形式は非較正されて、装置に依存する色を使用しました。 オリジナルのディスプレイ装置の正確な細部が知られているなら、特定のイメージの装置に依存する色を装置から独立しているものに変換するのは可能になります。 作成がCRT(プリンタよりはるかに簡単である)で働くことなどの仮定を簡素化して、私たちが知るために必要とするのだけが、それぞれの原色のXYZ値とCRT_ガンマです。
So why does PNG not store images in XYZ instead of RGB? Well, two
reasons. First, storing images in XYZ would require more bits of
precision, which would make the files bigger. Second, all
programs would have to convert the image data before viewing it.
Whether calibrated or not, all variants of RGB are close enough
that undemanding viewers can get by with simply displaying the
data without color correction. By storing calibrated RGB, PNG
retains compatibility with existing programs that expect RGB data,
yet provides enough information for conversion to XYZ in
applications that need precise colors. Thus, we get the best of
both worlds.
それで、PNGはなぜRGBの代わりにXYZのイメージを格納しませんか? さて、2つの理由。 まず最初に、XYZのイメージを格納するのは精度の、より多くのビットを必要とするでしょう。(精度はファイルをより大きくするでしょう)。 2番目に、それを見る前に、すべてのプログラムがイメージデータを変換しなければならないでしょう。 較正されているか否かに関係なく、RGBのすべての異形がビューアーを非要求するのが色の修正なしでデータを単に表示すると共になんとかやっていくことができるくらい近くにあります。 較正されたRGBを格納することによって、PNGはRGBデータを予想する既存のプログラムで互換性を保有しますが、正確な色を必要とするアプリケーションで変換のための十分な情報をXYZに供給します。 したがって、私たちは両方の世界を打ち負かします。
What are chromaticity and luminance?
色度と輝度は何ですか?
Chromaticity is an objective measurement of the color of an
object, leaving aside the brightness information. Chromaticity
uses two parameters x and y, which are readily calculated from
XYZ:
色度は明るさ情報は別にした物の色の客観的計測値です。 色度は2つのパラメタxとyを使用します:(パラメタはXYZから容易に計算されます)。
x = X / (X + Y + Z)
y = Y / (X + Y + Z)
X/(X+Y+Z)x=yはY/と等しいです。(X+Y+Z)
XYZ colors having the same chromaticity values will appear to have
the same hue but can vary in absolute brightness. Notice that x,y
are dimensionless ratios, so they have the same values no matter
what units we've used for X,Y,Z.
同じ色度値を持っているXYZ色は、同じ色を持っているように見えますが、絶対明るさにおいて異なることができます。 Z、それらには同じ値が私たちがXに使用したユニット、Yが何であってもあるようにx、yが点の比率であるのに注意してください。
Boutell, et. al. Informational [Page 91] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[91ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
The Y value of an XYZ color is directly proportional to its
absolute brightness and is called the luminance of the color. We
can describe a color either by XYZ coordinates or by chromaticity
x,y plus luminance Y. The XYZ form has the advantage that it is
linearly related to (linear, gamma=1.0) RGB color spaces.
XYZ色のY値は、絶対明るさに正比例していて、色の輝度と呼ばれます。 XYZ座標か色度xに従って、私たちは色について説明できます、y、利点がXYZフォームで直線的である輝度Y.はRGB色の空間に関連しました(直線的です、ガンマは1.0と等しいです)。
How are computer monitor colors described?
コンピュータ用モニター色はどのように説明されますか?
The "white point" of a monitor is the chromaticity x,y of the
monitor's nominal white, that is, the color produced when
R=G=B=maximum.
モニターの「白いポイント」は色度xです、モニターの名目上の白のy、すなわち、R=G=Bが最大と等しいときに発生した色。
It's customary to specify monitor colors by giving the
chromaticities of the individual phosphors R, G, and B, plus the
white point. The white point allows one to infer the relative
brightnesses of the three phosphors, which isn't determined by
their chromaticities alone.
個々の燐光体R、G、およびBの色度、および白いポイントを与えることによってモニター色を指定するのは通例です。 1つは白いポイントで単独で3蛍光物質の相対的なブライトネスを推論できます。(それらの色度に従って、蛍光物質は決定していません)。
Note that the absolute brightness of the monitor is not specified.
For computer graphics work, we generally don't care very much
about absolute brightness levels. Instead of dealing with
absolute XYZ values (in which X,Y,Z are expressed in physical
units of radiated power, such as candelas per square meter), it is
convenient to work in "relative XYZ" units, where the monitor's
nominal white is taken to have a luminance (Y) of 1.0. Given this
assumption, it's simple to compute XYZ coordinates for the
monitor's white, red, green, and blue from their chromaticity
values.
モニターの絶対快活さが指定されないことに注意してください。 一般に、コンピュータグラフィックス仕事のために、私たちは絶対明るさレベルをあまり心配しません。 絶対XYZ値(Y、Zは広がっているパワーの物理装置でどのXで、言い表されるか、1平方メートルあたりのカンデラなどのように)に対処することの代わりに、「親類XYZ」ユニットで働いているのは便利です、1.0の輝度(Y)を持つためにモニターの名目上の白を取るところで。 この仮定を考えて、それは、モニターの白のためにXYZ座標を計算する簡単で、赤く、緑色で、それらの色度値から青いです。
Why does cHRM use x,y rather than XYZ? Simply because that is how
manufacturers print the information in their spec sheets!
Usually, the first thing a program will do is convert the cHRM
chromaticities into relative XYZ space.
cHRMはなぜx、XYZよりむしろyを使用しますか? 単にそれがメーカーがどう彼らの明細書に情報を印刷するかということであるので! 通常、プログラムがする最初のことは相対的なXYZスペースにcHRM色度を変換することです。
What can I do with it?
私はそれで何をしてもよいですか?
If a PNG file has the gAMA and cHRM chunks, the source_RGB values
can be converted to XYZ. This lets you:
PNGファイルにgAMAとcHRM塊があるなら、ソース_RGB値をXYZに変換できます。 これはあなたをさせます:
* do accurate grayscale conversion (just use the Y component)
* convert to RGB for your own monitor (to see the original
colors)
* print the image in Level 2 PostScript with better color
fidelity than a simple RGB to CMYK conversion could provide
* calculate an optimal color palette
* pass the image data to a color management system
* etc.
* CMYK変換への簡単なRGBより良い色の信義があるLevel2ポストスクリプトにおけるイメージが*を提供できたあなた自身のモニター(原色を見る)*印刷のためのRGBへの正確なグレースケール変換(ただ、Yコンポーネントを使用する)*転向者は、最適のカラーパレット*がカラーマネージメントシステム*などにイメージデータを通過すると見込みます。
Boutell, et. al. Informational [Page 92] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[92ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
How do I convert from source_RGB to XYZ?
私はソース_RGBからXYZまでどのように変換しますか?
Make a few simplifying assumptions first, like the monitor really
is jet black with no input and the guns don't interfere with one
another. Then, given that you know the CIE XYZ values for each of
red, green, and blue for a particular monitor, you put them into a
matrix m:
最初に入力のない漆黒と銃がモニターと異なってお互いを妨げないという仮定を簡素化して、いくつかを作ってください。 次に、あなたがそれぞれの赤でCIE XYZ値を知っているなら緑色であって、特定のモニターに青いです、あなたはマトリクスmにそれらを入れます:
Xr Xg Xb
m = Yr Yg Yb
Zr Zg Zb
Xr Xg Xb m=年のYg Yb Zr Zg Zb
Here we assume we are working with linear RGB floating point data
in the range 0..1. If the gamma is not 1.0, make it so on the
floating point data. Then convert source_RGB to XYZ by matrix
multiplication:
ここで、私たちは、範囲0で直線的なRGB浮動小数点データで働いていると思います。1. したがって、ガンマが1.0でないなら、浮動小数点データでそれを作ってください。 次に、マトリクス乗法でソース_RGBをXYZに変換してください:
X R
Y = m G
Z B
m G X R Y=Z B
In other words, X = Xr*R + Xg*G + Xb*B, and similarly for Y and Z.
You can go the other way too:
言い換えれば、XはXr*R+Xg*G+Xb*Bと等しいです、そして、同様に、YとZ.に関して、あなたはもう片方の方向にも行くことができます:
R X
G = im Y
B Z
R X Gは不-Y B Zと等しいです。
where im is the inverse of the matrix m.
どこに、マトリクスmが不-逆ありますか?
What is a gamut?
全域は何ですか?
The gamut of a device is the subset of visible colors which that
device can display. (It has nothing to do with gamma.) The gamut
of an RGB device can be visualized as a polyhedron in XYZ space;
the vertices correspond to the device's black, blue, red, green,
magenta, cyan, yellow and white.
装置の全域はその装置が表示できる目に見える色の部分集合です。 (それはガンマと関係ありません。) 多面体としてXYZスペースでRGB装置の全域を想像できます。 頭頂は装置の黒、青くて、赤くて、緑色のマゼンタ、シアン、黄色、および白に対応します。
Different devices have different gamuts, in other words one device
will be able to display certain colors (usually highly saturated
ones) that another device cannot. The gamut of a particular RGB
device can be determined from its R, G, and B chromaticities and
white point (the same values given in the cHRM chunk). The gamut
of a color printer is more complex and can only be determined by
measurement. However, printer gamuts are typically smaller than
monitor gamuts, meaning that there can be many colors in a
displayable image that cannot physically be printed.
異なった装置には、異なった全域があります、言い換えれば、1台の装置が別の装置が表示できないある色(通常、ものを非常に飽和状態にする)を表示できるでしょう。 特定のRGB装置の全域はR、G、B色度、および白いポイント(cHRM塊で与えられた同じ値)から決定できます。 カラープリンタの全域は、より複雑であり、測定で決定できるだけです。 しかしながら、プリンタ全域はモニター全域より通常小さいです、物理的に印刷できない表示可能イメージには多くの色があることができることを意味して。
Boutell, et. al. Informational [Page 93] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[93ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
Converting image data from one device to another generally results
in gamut mismatches --- colors that cannot be represented exactly
on the destination device. The process of making the colors fit,
which can range from a simple clip to elaborate nonlinear scaling
transformations, is termed gamut mapping. The aim is to produce a
reasonable visual representation of the original image.
1台の装置から別の装置までイメージデータを変換すると、一般に、全域ミスマッチはもたらされます。--- ちょうど目的地装置に表すことができない色。 色を合わせる過程(非線形のスケーリング変化について詳しく説明するために簡単なクリップから変化できる)は全域マッピングと呼ばれます。 目的はオリジナルのイメージの合理的な視覚表現を作成することです。
Further reading
一層の読書
References [COLOR-1] through [COLOR-5] provide more detail about
color theory.
[COLOR-5]を通した参照[COLOR-1]は色の理論に関するその他の詳細を提供します。
15. Appendix: Sample CRC Code
15. 付録: サンプルCRCコード
The following sample code represents a practical implementation of the CRC (Cyclic Redundancy Check) employed in PNG chunks. (See also ISO 3309 [ISO-3309] or ITU-T V.42 [ITU-V42] for a formal specification.)
以下のサンプルコードはPNG塊で使われたCRC(周期的なRedundancy Check)の実用的な実現を表します。 (また、形式仕様に関してISO3309[ISO-3309]かITU-T V.42[ITU-V42]を見てください。)
The sample code is in the ANSI C programming language. Non C users may find it easier to read with these hints:
ANSI Cプログラミング言語にはサンプルコードがあります。 非Cユーザは、これらのヒントで読書するのが、より簡単であることがわかるかもしれません:
&
Bitwise AND operator.
ANDオペレータをBitwiseします。
^
Bitwise exclusive-OR operator. (Caution: elsewhere in this
document, ^ represents exponentiation.)
^は排他的論理和オペレータをBitwiseします。 (警告: このドキュメントのほかの場所では、^が羃法を表します。)
>>
Bitwise right shift operator. When applied to an unsigned
quantity, as here, right shift inserts zeroes at the left.
>>は正しいシフトオペレータをBitwiseします。 正しいシフトが左でゼロをここに挿入するので無記名の量に適用されると。
!
Logical NOT operator.
オペレータではなく、Logical。
++
"n++" increments the variable n.
+ +、「n++」は可変nを増加します。
0xNNN
0x introduces a hexadecimal (base 16) constant. Suffix L
indicates a long value (at least 32 bits).
0xNNN 0xは16進(ベース16)定数を導入します。 接尾語Lは長い値(少なくとも32ビット)を示します。
/* Table of CRCs of all 8-bit messages. */
unsigned long crc_table[256];
すべての8ビットのメッセージのCRCsの/*テーブル。 */無記名の長いcrc_テーブル[256]。
/* Flag: has the table been computed? Initially false. */
int crc_table_computed = 0;
/*旗: テーブルを計算してありますか? 初めは、誤っています。 */int crc_テーブル_は=0を計算しました。
Boutell, et. al. Informational [Page 94] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[94ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
/* Make the table for a fast CRC. */
void make_crc_table(void)
{
unsigned long c;
int n, k;
for (n = 0; n < 256; n++) {
c = (unsigned long) n;
for (k = 0; k < 8; k++) {
if (c & 1)
c = 0xedb88320L ^ (c >> 1);
else
c = c >> 1;
}
crc_table[n] = c;
}
crc_table_computed = 1;
}
/*は速いCRCのためにテーブルを作ります。 */空間は_crc_テーブル(空間)を作ります。無記名の長いc; int n、(k=0; k<8; k++)に関してcrc_テーブル[n]が(cと1)cは0xedb88320L^(c>>1)と等しいです; c>ほかのc=>1ならcと等しいという(n=0; n<256;n++)c=(無記名の長さ)nに関して、crc_テーブル_が=1を計算したというk
/* Update a running CRC with the bytes buf[0..len-1]--the CRC
should be initialized to all 1's, and the transmitted value
is the 1's complement of the final running CRC (see the
crc() routine below)). */
/*はバイトbuf[0..len-1]で走行CRCをアップデートします--CRCはすべての1に初期化されるべきであり、伝えられた値は最終的な走行CRCの1の補数(以下でのcrc()ルーチンを見る)です。 */
unsigned long update_crc(unsigned long crc, unsigned char *buf,
int len)
{
unsigned long c = crc;
int n;
無記名の長いアップデート_crc(無記名の長いcrc、無記名の炭の*buf、int len)、無記名の長いcはcrcと等しいです; int n
if (!crc_table_computed)
make_crc_table();
for (n = 0; n < len; n++) {
c = crc_table[(c ^ buf[n]) & 0xff] ^ (c >> 8);
}
return c;
}
_(計算されたcrc_テーブル_)が_crcを作るなら、()をテーブルの上に置いてください。 (n=0; n<len; n++) crc_テーブル(c^buf[n])と0xff]c=^(c>>8); リターンc。 }
/* Return the CRC of the bytes buf[0..len-1]. */
unsigned long crc(unsigned char *buf, int len)
{
return update_crc(0xffffffffL, buf, len) ^ 0xffffffffL;
}
/*はバイトbuf[0..len-1]のCRCを返します。 */無記名の長いcrc(無記名の炭*buf、int len)リターンアップデート_crc(0xffffffffL、buf、len)^0xffffffffL。
Boutell, et. al. Informational [Page 95] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[95ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
16. Appendix: Online Resources
16. 付録: オンライン情報源
(This appendix is not part of the formal PNG specification.)
(この付録は正式なPNG仕様の一部ではありません。)
This appendix gives the locations of some Internet resources for PNG software developers. By the nature of the Internet, the list is incomplete and subject to change.
この付録はPNGソフトウェア開発者のためにいくつかのインターネット資料の位置を与えます。 インターネットの性質で、リストは、変化を不完全であって、被りやすいです。
Archive sites
アーカイブサイト
The latest released versions of this document and related
information can always be found at the PNG FTP archive site,
ftp://ftp.uu.net/graphics/png/. The PNG specification is
available in several formats, including HTML, plain text, and
PostScript.
PNG FTPアーカイブサイトでいつもこのドキュメントと関連情報の最新のリリースされたバージョンを見つけることができます、 ftp://ftp.uu.net/graphics/png/ 。PNG仕様はいくつかの形式で利用可能です、HTML、プレーンテキスト、およびポストスクリプトを含んでいて。
Reference implementation and test images
参照実現とテストイメージ
A reference implementation in portable C is available from the PNG
FTP archive site, ftp://ftp.uu.net/graphics/png/src/. The
reference implementation is freely usable in all applications,
including commercial applications.
携帯用のCでの参照実現はPNG FTPアーカイブサイトから利用可能です、 ftp://ftp.uu.net/graphics/png/src/ 。参照実現はすべてのアプリケーションで自由に使用可能です、市販のアプリケーションを含んでいて。
Test images are available from
ftp://ftp.uu.net/graphics/png/images/.
テストイメージは ftp://ftp.uu.net/graphics/png/images/ から利用可能です。
Electronic mail
電子メール
The maintainers of the PNG specification can be contacted by e-
mail at png-info@uunet.uu.net or at png-group@w3.org.
電子メールは png-info@uunet.uu.net において、または、pngグループ@w3.orgにおいてPNG仕様の維持装置に連絡できます。
PNG home page
PNGホームページ
There is a World Wide Web home page for PNG at
http://quest.jpl.nasa.gov/PNG/. This page is a central location
for current information about PNG and PNG-related tools.
PNGのためのWWWホームページが http://quest.jpl.nasa.gov/PNG/ にあります。このページはPNGに関する現行情報とPNG関連のツールのための中心の位置です。
17. Appendix: Revision History
17. 付録: 改訂履歴
(This appendix is not part of the formal PNG specification.)
(この付録は正式なPNG仕様の一部ではありません。)
The PNG format has been frozen since the Ninth Draft of March 7, 1995, and all future changes are intended to be backwards compatible. The revisions since the Ninth Draft are simply clarifications, improvements in presentation, and additions of supporting material.
1995年3月7日のNinth Draft、およびすべての将来の変化が後方にである意図するので、PNG形式は凍っています。互換性がある。 Ninth Draft以来の改正は単に明確化、プレゼンテーション、およびサポートの材料の追加で改良です。
On 1 October 1996, the PNG specification was approved as a W3C (World Wide Web Consortium) Recommendation.
1996年10月1日に、PNG仕様はW3C(ワールドワイドウェブコンソーシアム)推薦として承認されました。
Boutell, et. al. Informational [Page 96] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[96ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
Changes since the Tenth Draft of 5 May, 1995
1995年5月5日の第10草稿以来の変化
* Clarified meaning of a suggested-palette PLTE chunk in a
truecolor image that uses transparency
* Clarified exact semantics of sBIT and allowed sample depth
scaling procedures
* Clarified status of spaces in tEXt chunk keywords
* Distinguished private and public extension values in type
and method fields
* Added a "Creation Time" tEXt keyword
* Macintosh representation of PNG specified
* Added discussion of security issues
* Added more extensive discussion of gamma and chromaticity
handling, including tutorial appendixes
* Clarified terminology, notably sample depth vs. bit depth
* Added a glossary
* Editing and reformatting
* 透明*を使用するtruecolorイメージによる提案されたパレットPLTE塊のはっきりさせられた意味はsBITの正確な意味論をはっきりさせました、そして、許容サンプル深さスケーリング手順*は個人的に区別されたtEXt塊キーワード*で空間の状態をはっきりさせました、そして、タイプによる公共の拡大値とPNGのtEXtキーワード*マッキントッシュ表現が*を指定した「創造時間」のときに加えられた方法分野*は安全保障問題*の議論がガンマと色度取り扱いの、より大規模な議論を加えたと言い足しました; *が用語、著しくサンプルの深さをはっきりさせた家庭教師の付属物を含んでいます; 噛み付いている深さ*は用語集*編集と再フォーマットを加えました。
18. References
18. 参照
[COLOR-1]
Hall, Roy, Illumination and Color in Computer Generated Imagery.
Springer-Verlag, New York, 1989. ISBN 0-387-96774-5.
CGIの[色-1]のホール、ロイ、イルミネーション、および色。 追出石-Verlag、ニューヨーク1989。 ISBN0-387-96774-5。
[COLOR-2]
Kasson, J., and W. Plouffe, "An Analysis of Selected Computer
Interchange Color Spaces", ACM Transactions on Graphics, vol 11 no
4 (1992), pp 373-405.
[COLOR-2] キャソン、J.、およびW.Plouffe、「選択されたコンピュータ置き換え色の空間の分析」、Graphics、vol11 4がない(1992)、pp373-405のACM Transactions。
[COLOR-3]
Lilley, C., F. Lin, W.T. Hewitt, and T.L.J. Howard, Colour in
Computer Graphics. CVCP, Sheffield, 1993. ISBN 1-85889-022-5.
Also available from
<URL:http://info.mcc.ac.uk/CGU/ITTI/Col/colour_announce.html>
[色-3] リリー、C.、F.リン、W.T.ヒューイット、およびT.L.J.ハワードはコンピュータグラフィックスを染めます。 CVCP、シェフィールド1993。 ISBN1-85889-022-5。 また、<URL: http://info.mcc.ac.uk/CGU/ITTI/Col/colour_announce.html >から、利用可能です。
[COLOR-4]
Stone, M.C., W.B. Cowan, and J.C. Beatty, "Color gamut mapping and
the printing of digital images", ACM Transactions on Graphics, vol
7 no 3 (1988), pp 249-292.
[COLOR-4]ストーン、M.C.(W.B.カウァン)、およびJ.C.ビーティは「ディジタル画像のマッピングと印刷に全域を着色します」、Graphicsの上のACM Transactions、vol7ノー3(1988)、pp249-292。
[COLOR-5]
Travis, David, Effective Color Displays --- Theory and Practice.
Academic Press, London, 1991. ISBN 0-12-697690-2.
[色-5] トラヴィス、デヴィッド、有効なカラーディスプレイ--- 理論と習慣。 アカデミックプレス社、ロンドン、1991。 ISBN0-12-697690-2。
[GAMMA-FAQ]
Poynton, C., "Gamma FAQ".
<URL:http://www.inforamp.net/%7Epoynton/Poynton-colour.html>
[ガンマFAQ] Poynton、C.、「ガンマFAQ。」 <URL: http://www.inforamp.net/%7Epoynton/Poynton-colour.html >。
Boutell, et. al. Informational [Page 97] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[97ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
[ISO-3309]
International Organization for Standardization, "Information
Processing Systems --- Data Communication High-Level Data Link
Control Procedure --- Frame Structure", IS 3309, October 1984, 3rd
Edition.
[ISO-3309]国際標準化機構、「情報処理システム」--- データ通信ハイレベル・データリンク制御手順--- 「枠組構造」は3309、1984年10月、第3版です。
[ISO-8859]
International Organization for Standardization, "Information
Processing --- 8-bit Single-Byte Coded Graphic Character Sets ---
Part 1: Latin Alphabet No. 1", IS 8859-1, 1987.
Also see sample files at
ftp://ftp.uu.net/graphics/png/documents/iso_8859-1.*
[ISO-8859]国際標準化機構、「情報処理」--- 8ビットの単一のバイトは図形文字セットをコード化しました。--- 第1部: 8859-1、1987はローマ字No.1インチ、そうですか? また、 ftp://ftp.uu.net/graphics/png/documents/iso_8859-1.* でサンプルファイルを見てください。
[ITU-BT709]
International Telecommunications Union, "Basic Parameter Values
for the HDTV Standard for the Studio and for International
Programme Exchange", ITU-R Recommendation BT.709 (formerly CCIR
Rec. 709), 1990.
[ITU-BT709] 国際電気通信組合、「スタジオのHDTV規格と国際プログラム交換のための基本的なパラメタ値」、ITU-R推薦BT.709(以前CCIR Rec。 709), 1990.
[ITU-V42]
International Telecommunications Union, "Error-correcting
Procedures for DCEs Using Asynchronous-to-Synchronous Conversion",
ITU-T Recommendation V.42, 1994, Rev. 1.
[ITU-V42] 国際電気通信組合、「DCEsのための同期に非同期な変換を使用するエラー修正手順」、ITU-T推薦V.42、1994、師1。
[PAETH]
Paeth, A.W., "Image File Compression Made Easy", in Graphics Gems
II, James Arvo, editor. Academic Press, San Diego, 1991. ISBN
0-12-064480-0.
[PAETH]Paeth、Graphics Gems II、ジェームスArvo、エディタの「イメージ・ファイル圧縮はたやすく作った」A.W.。 アカデミックプレス社、サンディエゴ、1991。 ISBN0-12-064480-0。
[POSTSCRIPT]
Adobe Systems Incorporated, PostScript Language Reference Manual,
2nd edition. Addison-Wesley, Reading, 1990. ISBN 0-201-18127-4.
[POSTSCRIPT] アドビ・システムズ株式会社、ポストスクリプトLanguage Reference Manual、2番目の版。 アディソン-ウエスリー、読書、1990。 ISBN0-201-18127-4。
[PNG-EXTENSIONS]
PNG Group, "PNG Special-Purpose Public Chunks". Available in
several formats from
ftp://ftp.uu.net/graphics/png/documents/pngextensions.*
[PNG-拡大。]PNGグループ、「PNGの専用公共の塊」 いくつかの形式では、 ftp://ftp.uu.net/graphics/png/documents/pngextensions.* から、利用可能です。
[RFC-1123]
Braden, R., Editor, "Requirements for Internet Hosts ---
Application and Support", STD 3, RFC 1123, USC/Information
Sciences Institute, October 1989.
<URL:ftp://ds.internic.net/rfc/rfc1123.txt>
[RFC-1123] ブレーデン、R.、エディタ、「インターネットホストのための要件」--- 「アプリケーションとサポート」、STD3、RFC1123、科学が設けるUSC/情報、10月1989日 <URL: ftp://ds.internic.net/rfc/rfc1123.txt >。
Boutell, et. al. Informational [Page 98] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[98ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
[RFC-2045]
Freed, N., and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, Innosoft, First Virtual, November 1996.
<URL:ftp://ds.internic.net/rfc/rfc2045.txt>
解放された[RFC-2045]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、Innosoft、ファースト・バーチャル方式、1996年11月。 <URL: ftp://ds.internic.net/rfc/rfc2045.txt >。
[RFC-2048]
Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet Mail
Extensions (MIME) Part Four: Registration Procedures", RFC 2048,
Innosoft, MCI, USC/Information Sciences Institute, November 1996.
<URL:ftp://ds.internic.net/rfc/rfc2048.txt>
解放された[RFC-2048]、N.、Klensin、J.、およびJ.ポステル、「マルチパーパスインターネットメールエクステンション(MIME)は4を分けます」。 「登録手順」、RFC2048、Innosoft、USC/情報科学が1996年11月に設けるMCI。 <URL: ftp://ds.internic.net/rfc/rfc2048.txt >。
[RFC-1950]
Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format
Specification version 3.3", RFC 1950, Aladdin Enterprises, May
1996.
<URL:ftp://ds.internic.net/rfc/rfc1950.txt>
[RFC-1950] ドイツ語、P.、およびJ-L。 ゲイル、「ZLIB Compressed Data Format Specification、バージョン3.3インチ、RFC1950、アラジンエンタープライズ、1996インチ年5月。 <URL: ftp://ds.internic.net/rfc/rfc1950.txt >。
[RFC-1951]
Deutsch, P., "DEFLATE Compressed Data Format Specification version
1.3", RFC 1951, Aladdin Enterprises, May 1996.
<URL:ftp://ds.internic.net/rfc/rfc1951.txt>
ドイツ語、[RFC-1951]P.、「DEFLATE Compressed Data Format Specification、バージョン1.3インチ、RFC1951、アラジンエンタープライズ、1996インチ年5月。 <URL: ftp://ds.internic.net/rfc/rfc1951.txt >。
[SMPTE-170M]
Society of Motion Picture and Television Engineers, "Television
--- Composite Analog Video Signal --- NTSC for Studio
Applications", SMPTE-170M, 1994.
[SMPTE-170M]の映画テレビ技術者協会、「テレビ」--- 合成アナログのビデオ信号--- 「スタジオアプリケーションのためのNTSC」、SMPTE-170M、1994。
Boutell, et. al. Informational [Page 99] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[99ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
19. Credits
19. クレジット
Editor
エディタ
Thomas Boutell, boutell@boutell.com
トーマスBoutell、 boutell@boutell.com
Contributing Editor
補助編集員
Tom Lane, tgl@sss.pgh.pa.us
トム・レイン、 tgl@sss.pgh.pa.us
Authors
作者
Authors' names are presented in alphabetical order.
作者の名前はアルファベット順に提示されます。
* Mark Adler, madler@alumni.caltech.edu
* Thomas Boutell, boutell@boutell.com
* Christian Brunschen, cb@df.lth.se
* Adam M. Costello, amc@cs.berkeley.edu
* Lee Daniel Crocker, lee@piclab.com
* Andreas Dilger, adilger@enel.ucalgary.ca
* Oliver Fromme, fromme@rz.tu-clausthal.de
* Jean-loup Gailly, gzip@prep.ai.mit.edu
* Chris Herborth, chrish@qnx.com
* Alex Jakulin, Aleks.Jakulin@snet.fri.uni-lj.si
* Neal Kettler, kettler@cs.colostate.edu
* Tom Lane, tgl@sss.pgh.pa.us
* Alexander Lehmann, alex@hal.rhein-main.de
* Chris Lilley, chris@w3.org
* Dave Martindale, davem@cs.ubc.ca
* Owen Mortensen, 104707.650@compuserve.com
* Keith S. Pickens, ksp@swri.edu
* Robert P. Poole, lionboy@primenet.com
* Glenn Randers-Pehrson, glennrp@arl.mil or
randeg@alumni.rpi.edu
* Greg Roelofs, newt@pobox.com
* Willem van Schaik, willem@gintic.gov.sg
* Guy Schalnat
* Paul Schmidt, pschmidt@photodex.com
* Tim Wegner, 71320.675@compuserve.com
* Jeremy Wohl, jeremyw@anders.com
* アドラーをマークしてください、 madler@alumni.caltech.edu *トーマスBoutell、 boutell@boutell.com *クリスチャンのBrunschen、 cb@df.lth.se *アダム・M.コステロ、 amc@cs.berkeley.edu *リー・ダニエル・クロッカー、 lee@piclab.com *アンドレアスDilger、 adilger@enel.ucalgary.ca *オリバーFromme、 fromme@rz.tu-clausthal.de *ジャンルー・ゲイル、 gzip@prep.ai.mit.edu *クリスHerborth、 chrish@qnx.com *アレックスJakulin、 Aleks.Jakulin@snet.fri.uni-lj.si *ニール・ケットラー、 kettler@cs.colostate.edu *トムLane、 tgl@sss.pgh.pa 私たち*アレクサンダー・レーマン、 alex@hal.rhein-main.de *クリス・リリー、 chris@w3.org *デーヴ・マーティンデール、 davem@cs.ubc.ca *オーエン・モーテンセン、 104707.650@compuserve.com *キース・S.ピケンズ、 ksp@swri.edu *ロバート・P.プール、 lionboy@primenet.com *グレン・ラナース-パーソン、 glennrp@arl.mil またはrandeg@alumni.rpi.edu*グレッグRoelofs、 newt@pobox.com *ウィレムはSchaikをバンに積みます、 willem@gintic.gov.sg *ガイ・Schalnat*ポール・シュミット、 pschmidt@photodex.com *ティム・ウェーグナー、 71320.675@compuserve.com *ジェレミー・ボール、 jeremyw@anders.com
The authors wish to acknowledge the contributions of the Portable
Network Graphics mailing list, the readers of comp.graphics, and
the members of the World Wide Web Consortium (W3C).
作者はPortable Network Graphicsメーリングリストの貢献、comp.graphicsの読者、およびワールドワイドウェブコンソーシアムのメンバー(W3C)を承諾したがっています。
Boutell, et. al. Informational [Page 100] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[100ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
The Adam7 interlacing scheme is not patented and it is not the
intention of the originator of that scheme to patent it. The
scheme may be freely used by all PNG implementations. The name
"Adam7" may be freely used to describe interlace method 1 of the
PNG specification.
Adam7交錯計画は特許をとられません、そして、それはその計画の創始者がそれの特許をとるという意志ではありません。 計画はすべてのPNG実現で自由に使用されるかもしれません。 「Adam7"はPNGのインターレース方法を説明するのが自由に使用された1つが仕様であったならそうするかもしれません」名前。
Trademarks
商標
GIF is a service mark of CompuServe Incorporated. IBM PC is a
trademark of International Business Machines Corporation.
Macintosh is a trademark of Apple Computer, Inc. Microsoft and
MS-DOS are trademarks of Microsoft Corporation. PhotoCD is a
trademark of Eastman Kodak Company. PostScript and TIFF are
trademarks of Adobe Systems Incorporated. SGI is a trademark of
Silicon Graphics, Inc. X Window System is a trademark of the
Massachusetts Institute of Technology.
GIFはコンピュサーブIncorporatedのサービスマークです。 IBM PCはIBM社の商標です。 マッキントッシュはアップル・コンピューターInc.の商標です。マイクロソフトとMS-DOSはマイクロソフト社の商標です。 フォトCDはイーストマン・コダック社の商標です。 ポストスクリプトとTIFFはアドビ・システムズ株式会社の商標です。 SGIによるシリコングラフィックスXウィンドウシステムの商標がマサチューセッツ工科大学の商標であるということです。
COPYRIGHT NOTICE
版権情報
Copyright (c) 1996 by: Massachusetts Institute of Technology (MIT)
以下によるCopyright(c)1996 マサチューセッツ工科大学(MIT)
This W3C specification is being provided by the copyright holders under the following license. By obtaining, using and/or copying this specification, you agree that you have read, understood, and will comply with the following terms and conditions:
このW3C仕様は以下のライセンスの下で著作権保有者によって提供することにされます。 この仕様を得て、使用する、そして/または、コピーすることによって、あなたは読んで、分かって、以下の条件に従うのに同意します:
Permission to use, copy, and distribute this specification for any purpose and without fee or royalty is hereby granted, provided that the full text of this NOTICE appears on ALL copies of the specification or portions thereof, including modifications, that you make.
これによりどんな目的と料金もロイヤリティなしでもこの仕様を使用して、コピーして、分配する許可を与えます、このNOTICEの全文がそれの変更を含むあなたが作る仕様か部分のすべてのコピーの上に現れれば。
THIS SPECIFICATION IS PROVIDED "AS IS," AND COPYRIGHT HOLDERS MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED. BY WAY OF EXAMPLE, BUT NOT LIMITATION, COPYRIGHT HOLDERS MAKE NO REPRESENTATIONS OR WARRANTIES OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE OR THAT THE USE OF THE SPECIFICATION WILL NOT INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS. COPYRIGHT HOLDERS WILL BEAR NO LIABILITY FOR ANY USE OF THIS SPECIFICATION.
この仕様は、著作権保有者がそして、「そのままで」表現を全くしないか、そして、速達の、または、暗示している保証です。 制限ではなく、例として、著作権保有者が市場性か特定用途への適合性のどんな表現も保証も作らないか、またはSPECIFICATIONウィルの使用がどんな第三者特許、著作権、何らかの商標も侵害しないのはまっすぐになります。 著作権保有者はこの仕様のどんな使用のためにも責任に全く堪えないでしょう。
Boutell, et. al. Informational [Page 101] RFC 2083 PNG: Portable Network Graphics March 1997
et Boutell、アル。 情報[101ページ]のRFC2083PNG: 1997年の携帯用のネットワークグラフィックス行進
The name and trademarks of copyright holders may NOT be used in advertising or publicity pertaining to the specification without specific, written prior permission. Title to copyright in this specification and any associated documentation will at all times remain with copyright holders.
著作権保有者の名前と商標は特定の、そして、書かれた先の許可なしで仕様に関係する広告か宣伝に使用されないかもしれません。 この仕様とどんな関連ドキュメンテーションの著作権へのタイトルも著作権保有者と共にいつも残るでしょう。
Security Considerations
セキュリティ問題
Security issues are discussed in Security considerations (Section 8.5).
Security問題(セクション8.5)で安全保障問題について議論します。
Author's Address
作者のアドレス
Thomas Boutell PO Box 20837 Seattle, WA 98102
トーマスBoutell PO Box20837シアトル、ワシントン 98102
Phone: (206) 329-4969 EMail: boutell@boutell.com
以下に電話をしてください。 (206) 329-4969 メールしてください: boutell@boutell.com
Boutell, et. al. Informational [Page 102]
et Boutell、アル。 情報[102ページ]
一覧
スポンサーリンク
