アプリを作る際に作成した、xcf.txtの日本語訳です。目次及び使用上の注意はこちら
7. TILE DATA ORGANIZATION =========================
6章におけるlevel structureのtile pointerによって指し示されるデータブロックのフォーマットは、master image structureのPROP_COMPRESSIONプロパティの値によって異なります。現行のGIMPは常にRLE圧縮を用いますが、XCF readerは古い非圧縮のファイルにも対応できるようにしておくべきです。
The format of the data blocks pointed to by the tile pointers in the level structure of the previous section differs according to the value of the PROP_COMPRESSION property of the main image structure. Current Gimps always use RLE compression, but readers should nevertheless be prepared to meet the older uncompressed format.
どのフォーマットも、状況から判断される [つまり、ヒエラルキー構造体に格納された値] 幅、高さ、ビット深度を利用します。どの圧縮方法も、連続した幅x高さのピクセル数を保持し、行ごとに、上から下へ、左から右へという順番で展開されます。
Both formats assume the width, height and byte depth of the tile are known from the context (namely, they are stored explicitly in the hierarchy structure). Both encodings store a linear sequence of with*height pixels, extracted from the tile in row-major, top-to-bottom, left-to-right order (the same as the reading direction of multi-line English text).
アルファ値をもったカラーモードにおいては、アルファ値はピクセルごとの2バイトまたは4バイトのデータのうちの最後に収められます。RGBカラーモードでは、最初の3バイトが順にR,G,Bに対応します。
In color modes with alpha information, the alpha value is the last of the 2 or 4 bytes for each pixel. In RGB color modes, the 3 (first) bytes for each pixel is the red intensity, the green intensity, and This post is a personal translation of Henning Makholm's xcf.txt to Japanese. : Index here
アプリを作る際に作成した、xcf.txtの日本語訳です。目次及び使用上の注意はこちら
the blue intensity, in that order.
Uncompressed tile data ----------------------
>非圧縮のタイルデータ
In the uncompressed format, the file first contains all the bytes for the first pixel, then all the bytes for the second pixel, and so on.
非圧縮のタイルデータでは、最初のピクセルの全データ、次のピクセルの全データというように収められています。
RLE compressed tile data ------------------------
>RLE圧縮されたタイルデータ
In the Run-Length Encoded format, each tile consists of a run-length encoded stream of the first byte of each pixel, then a stream of the second byte of each pixel, and so forth. In each of the streams, multiple occurrences of the same byte value are represented in compressed form. The representation of a stream is a series of operations; the first byte of each operation determines the format and meaning of the operation:
ランレングス法で圧縮されたフォーマットでは、それぞれのtileのデータは、[tile中の]全てのピクセルの1バイト目のデータ列、全ピクセルの2バイト目のデータ列、3バイト目の...4バイト目の...というように並んでいます。 それぞれのデータ列において、同じ値が連続する場合は、圧縮されて書くのされています。
byte n For 0 <= n <= 126: a short run of identical bytes byte v Repeat this value n+1 times or byte 127 A long run of identical bytes byte p byte q byte v Repeat this value p*256 + q times or byte 128 A long run of different bytes byte p byte q byte[p*256+q] data Copy these verbatim to the output stream or byte n For 129 <= n <= 255: a short run of different bytes byte[256-n] data Copy these verbatim to the output stream
The end of the stream for "the first byte of all pixels" (and the following similar streams) must occur at the end of one of these operations; it is not permitted to have one operation span the boundary between streams.
「全ピクセルのNバイト目のデータ列の終了」は上で述べた4つのいずれか終わらなければなりません。異なるデータ列をまたいで圧縮をすることは認められていません。
The RLE encoding allows "degenerate" encodings in which the original data stream may double in size (or grow to arbitrarily large sizes if (128,0,0) operations are inserted). Such encodings must be avoided, as GIMP's XCF reader expects that the size of an encoded tile is never more than 24 KB, which is only 1.5 times the unencoded size of a 64x64 RGBA tile.
RLEの圧縮方法(古い方法)によっては、元データの2倍になることがあります。が、このような圧縮は避けねばなりません。なぜなら、GIMP のXCFリーダーは、各タイルの圧縮後のデータは最大でも24KBであると見積もるからです。これは、64x64 pixのRGBAタイルのサイズの1.5倍に過ぎません。
A simple way for an XCF creator to avoid overflow is
GIMPのメモリオーバーフローを引き起こすようなXCFファイルを生成しないための単純な方法としては、
a) never using opcode 0 (but instead opcode 255) b) using opcodes 127 and 128 only for lengths larger than 127 c) never emitting two "different bytes" opcodes next to each other in the encoding of a single stream.
[未訳:原文を見てください]
0 件のコメント:
コメントを投稿