PhotoshopとPaint Shop Pro の画像形式

Photoshopや、Paint Shop Proは、レイヤーごとに画像、マスク画像、合成方法などの情報を持ちます。 画像ファイルはこれら編集用の情報も保持しているため、他の画像形式と比べファイルサイズは大きくなります。

Photoshop の画像形式 (.PSD/.PDD)

Adobe Systems社の画像編集ソフトPhotoshopの画像形式。 TIFFにも使われているPackBitsアルゴリズムを使用。 バイトオーダーは、もともとMacintosh用に開発されたソフトウェアのためビッグエンディアン。

psd.txt(英語)
Photoshopのバージョン2.5の仕様書です。 レイヤーについての説明はありません。 （Photoshopでレイヤー機能がサポートされたのは、バージョン3.0からだと思いました。）

psd_jp.txt(日本語)
上のpsd.txtを邦訳したもの。

ps6ffspecsv2.pdf (英語)
Photoshopバージョン6の仕様書です。 バージョン3,4向けのものは、wotsitから入手できます。 この新しい仕様書を見ると圧縮方式にZIPが加えられています。

メモ
・ビッグエンディアン
・プレーン順（レイヤー）: RGB, ARGB順
・プレーン順（コンポジット）: RGB, RGBA順
・RLE展開データは、ラインを跨がないことが約束されている
・コンポジットイメージは編集時の画像サイズで得られる

FineViewでの対応
対応済み。

PSDのデコーダーは、レイヤーレベルでのデコードもできるように作ってあります。 （ラスターレイヤーのみ。） FineViewではレイヤーレベルのデコードを予定していません。

Paint Shop Pro の画像形式 (.PSP)

Jasc Software社が開発した画像編集ソフトPaint Shop Proの画像形式。 エンコードに使用している圧縮法は、LZ77, RLE。 PSP6で仕様が少し変わり、PSP5とPSP6以降ではデコード手順が少し異なります。 リトルエンディアン。（2005年Jasc SoftwareはCorelに買収された。）

LZ77のデコード処理は、奥村晴彦さんのzlib 入門を参考にさせてもらいました。 zlib入門のホームページには、デコード/エンコード用のサンプルソースが用意されています。

Paint Shop Pro (PSP) File Format Specification ← リンク切れ
各バージョンの仕様書（ワード文書）が入手できます。 ワード文書を見るためのWord Viewer 97はこちら

メモ
・リトルエンディアン
・プレーン順: RGB, RGBA順
・ラインごとの展開はできない（プレーンごと）
・データ圧縮: LZ77, RLE, RAW
・コンポジットイメージはJPEG, LZ77, RLE, RAW
・コンポジットイメージは編集時の画像サイズで得られるとは限らない
・コンポジットイメージは0〜複数
・仕様: (5),(6,7),(8,9,X,XI),(X2,X3) ← 同じカッコ内のverは大きな変更なし。

FineViewでの対応
Paint Shop Pro ver5〜7 に対応。
ver5のコンポジット画像は未対応。→ 1stレイヤー（背景）を表示

FilterGearでの対応
Paint Shop Pro ver5〜X3 に対応。

PSPのデコーダーは、レイヤーレベルでデコードができるように作ってあります。 （ラスターレイヤーのみ。） FineViewでは、レイヤーレベルのデコードを予定していません。

Fireworksの画像形式 (.PNG)

Macromedia社が開発した画像編集ソフトFireworksの画像形式。 オリジナルのPNGをベースに独自のチャンクを追加した構造だと思いますが・・詳細は不明。 （2005年MacromediaはAdobe Systemsに買収された。）

FineViewでの対応
未対応。

TIFFファイル形式 (.TIF/.TIFF)

Aldus社が開発した高い柔軟性をもつ画像形式。（1994年AldusはAdobe Systemsと合併。）

TIFF 6.0 Specification ( Adobe Systems )
TIFF6の仕様書です。
121ページもあります。ページ数からもTIFF形式の複雑さを窺い知ることができます。

□□ TIFFヘッダー □□ TIFFヘッダーは8バイト固定 type TTIFFHeader = record // バイトオーダー // 'MM'のときビッグエンディアン (Motorola Motorola) // 'II'のときリトルエンディアン (Intel Intel) ByteOrder: WORD; // 'MM' or 'II' // バージョン Version: WORD; // 0x2A(42) ←常に42 // IFD (ImageFileDirectory) へのポインタ IFDPointer: Cardinal; // end; □□ IFD □□ IFDには符号化された画像の様々な情報が格納されています。Exifと非常によく似ています。 IFDの構成 IFDエントリーの数 // 2バイト IFDエントリー // 12バイト固定のデータ 　　・ 　　・ IFDエントリー // 12バイト固定のデータ 次の画像へのIFDポインタ // 4バイト（画像が一つだけのときは0） □ IFDエントリー □ type TIFDEntry = record Tag: WORD; // タグ。どういったデータが入っているかを示す識別子 DataType: WORD; Count: Cardinal; Data: Cardinal; // データ or 実データへのポインタ end; IFDエントリーではタグごとに扱う情報が異なります。 基本的なタグのみ抜粋（タグは無数に存在します。公開タグ:0xFE〜0x214。非公開タグも存在。） 0x100: ImageWidth // 画像の幅 0x101: ImageLength // 画像の高さ 0x102: BitsPerSample // 色深度 0x103: Compression // 符号化方法 0x111: StripOffsets // 画像データへのポインタ 0x115: SamplesPerPixel // カラープレーン数 0x117: StripByteCounts // 画像データサイズ 0x140: ColorMap // パレットデータへのポインタ 0x106: PhotometricInterpretation // 画像識別コード 0x103: Compression（符号化方法） 1: 圧縮なし 2: CCITT Group 3 変形ハフマンRLE 3: CCITT Group 3 Fax 4: CCITT Group 4 Fax 5: LZW 6,7: JPEG 32773: PackBits etc 0x106: PhotometricInterpretation（画像識別コード） 0,1: モノクロ or グレイスケール(パレットの構築 0:最小値白, 1:最小値黒) 2: RGBカラー 3: パレットカラー etc 0x140: ColorMap パレットデータは1バイトではなく2バイト(0〜65535）で与えられます。 8bitパレットカラー（256カラー）のとき256*3(RGB)*2=1536バイト分のデータが存在します。 パレットのデータはRGB順と記されていますが、これは RGBRGBRGB...ということではなく はじめにRのパレットデータ全てが存在し、次にGのパレットデータがというように並んでいます。 ※ ColorMapに関する情報は調べた画像に対するものであって、必ずしもここで紹介したとおりとは限りません。

符号化方法の選択肢が多いことがデコーダーの開発を難しくしています。 ひとつの符号化に限っても仕様の異なるものが複数存在し、開発者泣かせの画像形式と言えます。 （JPEGで符号化されたTIFFで仕様の異なるものを３種類確認しています。）

FineViewでの対応
IFDを解析し、LibTiffでデコードできる形式はLibTiffで、 そうでない形式は独自デコーダーでデコードしています。 一部対応していない色深度がありますが、一般に広く使われているTIFF形式に関してはサポートしています。

独自デコーダーでは、Compression=6で符号化されたTIFF形式をデコードしています。

補足）TIFFのライブラリーであるLibTiffは全てのTIFF形式をサポートしているわけではありません。
→ http://www.asmail.be/msg0055440587.html

SGIファイル形式 (.RGB/.RGBA/.SGI)

シリコングラフィクスのマシンで使われているファイル形式。 バイトオーダーがビッグエンディアンなのでWindowsでプログラミングするときはスワップ処理が必要。

SGIのファイル形式は無圧縮（生データ）かランレングスでエンコードされたデータのどちらかです。

rgb.txt(英文)

全体的な構成

VERBATIM(生データ)	RLE
ヘッダ	ヘッダ
画像データ	オフセットテーブル
	画像データ

SGIのヘッダ
ヘッダの構成は、以下のようになっています。

Size | Type | Name | Description 2 bytes | short | MAGIC | IRIS image file magic number 1 byte | char | STORAGE | Storage format 1 byte | char | BPC | Number of bytes per pixel channel 2 bytes | ushort | DIMENSION | Number of dimensions 2 bytes | ushort | XSIZE | X size in pixels 2 bytes | ushort | YSIZE | Y size in pixels 2 bytes | ushort | ZSIZE | Number of channels 4 bytes | long | PIXMIN | Minimum pixel value 4 bytes | long | PIXMAX | Maximum pixel value 4 bytes | char | DUMMY | Ignored 80 bytes | char | IMAGENAME | Image name 4 bytes | long | COLORMAP | Colormap ID 404 bytes | char | DUMMY | Ignored MAGIC SGI形式のシグネチャです。474(10進数)が格納されています。 STORAGE この値は0か1のいずれかです。ランレングスでエンコードされてるときは、1となります。 BPC この値が1のときは、R/G/Bそれぞれ1バイト(256レベル）として扱います。 2のときは2バイトで扱います。 この値は1と2のいずれかです。 DIMENSION この値は1,2,3のいずれかです。 1のとき1行のラインを示します。2のときWidthxHeightの単一のチャネルを持ちます。 3のときWidthxHeightで、複数のチャネルを持ちます。 チャネル数はZSIZEで与えられる数値です。 XSIZE 画像の横幅(Width or COLS)です。 YSIZE 画像の縦幅(Height or ROWS)です。 ZSIZE 画像のチャネル数です。 IMAGENAME 79キャラクタ+NULLです。 COLORMAP ピクセルをどうのようにデコードするかを示します。 0から3のいずれかの値を持ちます。 0: NORMAL SGIファイル形式の多くはこのタイプです。 B/Wは1チャネルで扱います。RGBは3チャネル、RGBAは4チャネルで扱います。 1: DITHRED このファイル形式は既に陳腐化したものです。 1チャネルで画像を構成します。 RGBのデータは、8bitの中に収められています。 赤:bits[2..0], 緑:bits[5..3], 青:bits[7..6] 2: SCREEN このファイル形式は既に陳腐化したものです。 インデックスカラーを使用して画像を展開します。 1チャネルで画像を構成します。 3: COLORMAP SGIマシンのカラーマップを使用して画像を表示する方法です。

画像のデコード（RLE版）
※RLEでない画像データは省略

RLEで圧縮されてる場合、RLEのオフセットテーブルが与えられます。 オフセットテーブルには、画像データへのポインタとそのデータレングスが格納されています。 オフセットデータのテーブル情報 Size | Type | Name | Description tablen longs | long | STARTTAB | Start table tablen longs | long | LENGTHTAB | Length table オフセットテーブルを取得(IDE:C++Builder) typedef struct { unsigned long *Start; unsigned long *Size; } TOffsetTable; TOffsetTable *offTable = new TOffsetTable; // オフセットデータ取得 int tablen = SGIHeader.YSize*SGIHeader.ZSize; offTable->Start = new unsigned long[tablen]; offTable->Size = new unsigned long[tablen]; TFileStream *fs = new TFileStream(FileName,fmOpenRead); fs->Seek(512, soFromBeginning); fs->Read(offTable->Start, tablen*sizeof(long)); fs->Read(offTable->Size, tablen*sizeof(long)); delete fs; // ※オフセットデータを使い終わったらフリー スキャンラインへのアクセス方法 unsigned long rleoffset, rlelength; rleoffset = image->rowStart[y+z*bmp->Height]; rlelength = image->rowSize[y+z*bmp->Height]; // RLE情報の場所へ TFileStream *fs = new TFileStream(FileName,fmOpenRead); fs->Seek(rleoffset, soFromBeginning); // ※yはスキャンするライン、zはスキャンするチャネル // ※Windows系ではオフセットデータを予めスワップする必要があります。

補足
COLORMAPは4タイプあります。Windows環境でサポートできるものは3つです。
内2つは、現在使われていない形式です。

COLORMAP種別	対応
NORMAL	○
DITHRED	×(obsolete)
SCREEN	×(obsolete)
COLORMAP	×(SGI マシン)

メモ
・ビッグエンディアン
・RGB24bit, グレイスケール, RGB with Alpha, グレイスケール with Alpha が存在
・各チャネルは、8 or 16ビット
・RAWデータのプレーン順: RGB, RGBA順
（RLEデータのオフセットテーブルもRGBA順。画像データのメモリ順は任意。）
・他形式と違い、任意のプレーン、任意のラインからデコード可能
・RLE展開データは、ラインを跨がないことが約束されている
・ボトムスキャン
・ヘッダ情報512バイト固定（内ダミー404バイト）

FineViewでの対応
デコード、エンコードともに対応。（但し、グレイスケール with Alpha には未対応。）

FilterGearでの対応
グレイスケール with Alpha に対応。グレイスケールのデコードバグ修正。

TGAファイル形式 (.TGA/.VST/.ICB/.VDA)

RLEを用いた画像形式。

デコードの資料（簡易テキスト文書）
tga.txt

PDF文書による詳説
Truevision TGA FILE FORMAT SPECIFICATION Version 2.0
targa.pdf

メモ
・RLE展開データは、ラインを跨ぐことがある

PCXファイル形式 (.PCX)

RLEを用いた画像形式。

特徴など・・
・リトルエンディアン
・ヘッダ情報128バイト固定
・制御ビットが上位2ビット
・リテラルデータがブロックされてない。
・画像データはラインごとにRプレーンGプレーンBプレーンの順で格納されている。
・ファイルのケツのマイナス769byte目が0xCのときは、256パレット。次いでパレットデータが格納されている。

デコードの資料（簡易テキスト文書）
pcx.txt
コード付き。

コダック Photo-CD形式 (.PCD)

１つのファイルに５つの解像度の画像情報を保持します。

pcd.rtf(英語)
（Pascalのソース付き。）

Kodak PhotoYCC colour space for PhotoCD images

PNM (.PPM, .PGM, .PBM)

圧縮を用いない画像形式。学術用途などで広く使われている。

PPM: Portable PixMap (24bit color)
PGM: Portable GrayMap (8bit grayscale)
PBM: Portable BitMap (1bit monochrome)
これら3つを総称して、PNM (Portable aNyMap) と呼ばれる。

マジックナンバー (P1〜P6)
P1: PBM (ASCII)
P2: PGM (ASCII)
P3: PPM (ASCII)
P4: PBM (BINARY)
P5: PGM (BINARY)
P6: PPM (BINARY)

ホワイトスペース (blanks, TABs, CRs, LFs)
$20, $09, $0D, $0A
（Carriage Return / 行頭復帰、Line Feed / 改行）

画像データ
PPM, PGM
マジックナンバー + WS + 幅 + WS + 高さ + WS + 輝度 + WS + 画素データ
PBM
マジックナンバー + WS + 幅 + WS + 高さ + WS + 画素データ
（WSはホワイトスペース）

ノート
BINARY(RAWBITS)のときのホワイトスペースの数に注意！！
PPM,PGM: 輝度の後のホワイトスペースは１バイトのみ許される。
PBM: 高さの後のホワイトスペースは１バイトのみ許される。

デコードのテスト用に作成した画像（画素値が$20といったホワイトスペースの値のみで構成されたPGM） 黒い10x10の画像をデコードできればOK。
p5_pix_digit_all_whitespace.zip

FineViewでの対応
デコードはP1〜P6の全てに対応。エンコードは全てバイナリー出力P4〜P6。

IFF(ILBM)ファイル形式 (.IFF/.LBM)

コモドール社製のAMIGAというコンピュータで使われていた画像形式。 AMIGAは、モトローラ社製のCPU(68000)を使用してるためビッグエンディアン。

IFFという名前は、チャンク構造を意味しているようなので、インターリーブビットマップ呼んだほうが 適切かもしれません。 輝度の低いデータから順に格納されるという独特の画像形式です。LightWaveでも使用されてます。 （LightWaveは、AMIGA出身のソフトウェア。）

チャンク構造

最初の4バイトはチャンクID、続く4バイトはチャンクサイズ、そしてチャンクサイズ分のチャンクデータ。 チャンクサイズは、チャンクID部とチャンクサイズ部のサイズを含みません。 IFFのチャンクは入れ子にすることができます。 typedef struct { unsigned long ckID; unsigned long ckSize; unsigned char ckData[n]; // nは、ckSize } TChunk; BMHDチャンク 画像サイズや、コンプレッションの情報が格納されています。 // （インターリーブ）ビットマップヘッダ構造 typedef struct { unsigned long ID; unsigned long Size; unsigned short Width; unsigned short Height; unsigned short Xorg; unsigned short Yorg; unsigned char Planes; unsigned char Masking; unsigned char Compression; unsigned char Pad; unsigned short Trclr; unsigned char AspectX; unsigned char AspectY; unsigned short pWidth; unsigned short pHeight; } TILBMHeader; CMAPチャンク カラーマップのチャンクです。 typedef struct { unsigned char red, green, blue; // R/G/Bの輝度情報(0..255) } ColorRegister; typedef ColorRegister ColorMap[n]; // size = 3 x n bytes BODYチャンク 画像データが格納されているチャンクです。BMHDのCompressionが1のとき画像データはRLEでエンコードされています。 nプレーンを持つIFF/ILBM形式で、1stプレーンには各rowの最下位ビットが2ndプレーンには 次のビットが・・・といったように配列で格納されてます。

ラスタイメージの展開（24bppの場合）

画像データは、横1ライン分ごとにRed成分、Green成分、Blue成分の順に並んでいます。 Red成分は、0bit目の情報全て、次いで1bit目の情報全てといったように輝度の低い順で並んでいます。 Green成分、Blue成分も同様です。 Red Plane r00 r01 r02 ... r10 r11 r12 ... r20 r21 r22 ... r30 r31 r32 ... r40 r41 r42 ... r50 r51 r52 ... r60 r61 r62 ... r70 r71 r72 ... Green Plane g00 g01 g02 ... g10 g11 g12 ... g20 g21 g22 ... g30 g31 g32 ... g40 g41 g42 ... g50 g51 g52 ... g60 g61 g62 ... g70 g71 g72 ... Blue Plane b00 b01 b02 ... b10 b11 b12 ... b20 b21 b22 ... b30 b31 b32 ... b40 b41 b42 ... b50 b51 b52 ... b60 b61 b62 ... b70 b71 b72 ... 各プレーンのバイト数は、(w+15)/16 wordsなので、((w+15)/16)*2 Bytesとなります。 Red成分の0bit目の情報 Red成分の1bit目の情報 Red成分の2bit目の情報 Red成分の3bit目の情報 Red成分の4bit目の情報 Red成分の5bit目の情報 Red成分の6bit目の情報 Red成分の7bit目の情報 Green成分の0bit目の情報 Green成分の1bit目の情報 ・ ・ ・ ・ Blue成分の7bit目の情報 Redプレーンの展開のサンプル Red Plane r00 r01 r02 ... r10 r11 r12 ... r20 r21 r22 ... r30 r31 r32 ... r40 r41 r42 ... r50 r51 r52 ... r60 r61 r62 ... r70 r71 r72 ... R00 & 0x80 -> row[2] |= 00000001 R10 & 0x80 -> row[2] |= 00000010 R20 & 0x80 -> row[2] |= 00000100 R30 & 0x80 -> row[2] |= 00001000 R40 & 0x80 -> row[2] |= 00010000 R50 & 0x80 -> row[2] |= 00100000 R60 & 0x80 -> row[2] |= 01000000 R70 & 0x80 -> row[2] |= 10000000 R00 & 0x40 -> row[5] |= 00000001 R10 & 0x40 -> row[5] |= 00000010 R20 & 0x40 -> row[5] |= 00000100 R30 & 0x40 -> row[5] |= 00001000 R40 & 0x40 -> row[5] |= 00010000 R50 & 0x40 -> row[5] |= 00100000 R60 & 0x40 -> row[5] |= 01000000 R70 & 0x40 -> row[5] |= 10000000 ※ 左の式が真のとき、ビットを立てていきます。 ※ unsigned char *row = (unsigned char *)Bitmap->ScanLine[0];

ラスタイメージの展開（4bppの場合）

buf[]にはRLEを展開したデータが入ってるものとします。row[]は出力先です。 buf[]に1stプレーンのデータを取得したときのデコード buf[0] & 1000 0000 (0x80) -> row[0] |= 00010000 buf[0] & 0100 0000 (0x40) -> row[0] |= 00000001 buf[0] & 0010 0000 (0x20) -> row[1] |= 00010000 buf[0] & 0001 0000 (0x10) -> row[1] |= 00000001 buf[0] & 0000 1000 (0x08) -> row[2] |= 00010000 buf[0] & 0000 0100 (0x04) -> row[2] |= 00000001 buf[0] & 0000 0010 (0x02) -> row[3] |= 00010000 buf[0] & 0000 0001 (0x01) -> row[3] |= 00000001 buf[1] & 1000 0000 (0x80) -> row[4] |= 00010000 buf[1] & 0100 0000 (0x40) -> row[4] |= 00000001 buf[]に2ndプレーンのデータを取得したときのデコード buf[0] & 1000 0000 (0x80) -> row[0] |= 00100000 buf[0] & 0100 0000 (0x40) -> row[0] |= 00000010 buf[0] & 0010 0000 (0x20) -> row[1] |= 00100000 buf[0] & 0001 0000 (0x10) -> row[1] |= 00000010 buf[0] & 0000 1000 (0x08) -> row[2] |= 00100000 buf[0] & 0000 0100 (0x04) -> row[2] |= 00000010 buf[0] & 0000 0010 (0x02) -> row[3] |= 00100000 buf[0] & 0000 0001 (0x01) -> row[3] |= 00000010 buf[1] & 1000 0000 (0x80) -> row[4] |= 00100000 buf[1] & 0100 0000 (0x40) -> row[4] |= 00000010 ※ 左の式が真のとき、ビットを立てていきます。 1stプレーン：横1ラインの0bit目の情報（最下位ビット） 2ndプレーン：横1ラインの1bit目の情報 3rdプレーン：横1ラインの2bit目の情報 4thプレーン：横1ラインの3bit目の情報 ※Bit0を最下位ビット（bit[7..0]） 参考：buf[0]が、仮に0xFF(1111 1111)のとき次のようにデコードする。 row[0] = 0001 0001 row[1] = 0001 0001 row[2] = 0001 0001 row[3] = 0001 0001

参考リンク
iff.txt(英文)
dstormと、NEWTEKのサイトによるILBMの解説
"ILBM" IFF Interleaved Bitmap(インターリーブ・ビットマップ)
"ILBM" IFF Interleaved Bitmap
ilbm.txt（Jerry Morrison氏によるILBMのテキスト文書） (入手先wotsit)
Intro to IFF Amiga ILBM（dc.eeより入手のテキスト文書/iffspecs.lzhの中の文書） (入手先dc.ee)
確認用の画像ファイルはCommodore 65から入手できます。

FineViewでの対応
デコードのみ対応。 スキルが未熟なときに作ったものなので、デコード処理が遅いです。

ホームページで使用できる画像形式

JPEG, PNG, GIFといった画像形式はホームページでも良く使われる形式です。 JPEGは自然画像、PNGやGIFはセル画や図形、文字を含んだ画像に適しています。

リンク： WEB画像について

JPEGファイル形式 (.JPEG/.JPG/.JPE) Joint Photographic Experts Group

非可逆圧縮の画像形式。 人間が鈍感な「色差成分」と「高周波成分」を切り捨てることにより高い圧縮率を実現。 ホームページ、デジカメなど広く使われている。 ブロックノイズ。モスキートノイズといったデメリットもあり。

JPEG関連のリンク
JPEGのホームページ
JPEGに関するFAQ
JPEG - Wikipedia

ライブラリIJG関連のリンク
IJGのホームぺージ
ソースとドキュメントが置いてあるとこ

JPEG(CMYK)のテスト用画像
（IE6では表示できないのでダウンロードしてから試してみてください。）

IJGをパスカルで実装したもの（作者：Nomssiさん）
PasJPEG

FineViewでの対応
JPEGを表示するプログラムの多くは、IJGというライブラリを使用しています。 C++Builderで開発していたころは、IJGのライブラリを使用していましたが、 現在はPasJpegに少しだけ手を加えたものを使っています。

IJG以外では、インテルが作ったIJLというライブラリがあります。 FineViewはこちらを使用したデコードにも対応しています。 （現在IJLはインテルの別ライブラリに吸収され、単体では配布されていません。）

-------------------------------------------------- sample1.rc START
DIGIT_SMALL BITMAP digit_5x7_lot.bmp
DIGIT_MIDDLE BITMAP digit_6x7_lot.bmp
DIGIT_LARGE BITMAP digit_6x8_lot.bmp
-------------------------------------------------- sample1.rc END

ex)
--------------------------------------------------
unit sample;

interface
	（省略)
implementation

{$R *.dfm}
{$R sample1.res} // こんな感じでココに追加します。
--------------------------------------------------

ex)
--------------------------------------------------
  SrcBmp := TBitmap.Create;
  SrcBmp.LoadFromResourceName(HInstance, 'DIGIT_SMALL');
--------------------------------------------------