xcf.txtの日本語訳 7. TILE DATA ORGANIZATION

This post is a personal translation of Henning Makholm's xcf.txt to Japanese. : Index here
アプリを作る際に作成した、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バイト目のデータ列の終了」は上で述べた４つのいずれか終わらなければなりません。異なるデータ列をまたいで圧縮をすることは認められていません。

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.

[未訳:原文を見てください]