ラボラトリ - FineView Software Labs

画像形式

画像編集ソフトウェアで使われている画像形式
PSD	Photoshop
PSP	Paint Shop Pro
汎用的に使われている画像形式
TIFF	Tag Image File Format
SGI	SGI
IFF	IFF ILBM
TGA	Targa
PCX	PCX
PCD	コダック PhotoCD
PPM/PGM/PBM	Portable Pixelmap/Portable Graymap/Portable Bitmap (or 全てまとめてPortable aNymap)
ホームページで使うことができる画像形式
JPEG	Joint Photographic Experts Group
PNG	Portable Network Graphics
GIF	Graphics Interchange Format
日本の画像形式
MAG	MAG 4bit/8bit用画像形式
PIC	PIC 8bit用画像形式
ERI	Entis Rasterized Image format

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が加えられています。

FineViewでの対応
対応済み。
PSDのデコーダは、レイヤーレベルでのデコードもできるように作ってあります。ただ、FineViewではレイヤーレベルのデコードを予定していません。

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

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

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

FineViewでの対応
対応済み。
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
ヘッダヘッダ

画像データオフセットテーブル

画像データ

画像のデコード（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 マシン)

FineViewでの対応
デコード、エンコードともに対応。

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: 高さの後のホワイトスペースは１バイトのみ許される。

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

IFF(ILBM)ファイル形式 (.IFF/.LBM)
コモドール社製のAMIGAというコンピュータで使われていた画像形式です。 AMIGAは、モトローラ社製のCPU(68000)を使用してるためビッグエンディアンです。
IFFという名前は、チャンク構造を意味しているようなので、インターリーブビットマップ呼んだほうが適切かもしれません。輝度の低いデータから順に格納されるという独特の画像形式です。LightWaveでも使用されてます。

チャンク構造

最初の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を表示するプログラムの多くは、IJGというライブラリを使用しています。マイクロソフトのインターネットエクスプローラや、ボーランドのVCLもIJGのライブラリを使用しています。
IJGのライブラリ以外で有名なものに、インテルが作ったIJLというものがあります。現在IJLはインテルの別ライブラリに吸収され、単体では配布されていません。

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

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

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

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

FineViewでの対応
以前はIJGライブラリを直接叩いてましたが、現在はPasJpegに少しだけコードを加えたものを使ってます。（機能的には、Borland標準添付のTJPEGImageに、CMYKとMachintoshのリソースフォークへの対応を加えたような感じです。） IJLにも対応しています。

Exif
EXIF.org
Exif file format
Martin Djernaes Web / Jpeg Info
TIFF Tag Reference, EXIF Tags

PNGファイル形式 (.PNG) Portable Network Graphics
GIF形式の特許が問題となるなか、新たに登場した画像形式。圧縮率やフルカラーサポートなどGIFより優秀だが後発のせいかあまり普及していない。

PNGを実装するには、LIBPNGというライブラリを使用します。 Delphiで実装するには、tarquinさん作のGLDPNGが有名です。

PNG,libpngに関する情報
PNG Home Site (PNGの公式ホームページ)
PNG Specification, Version 1.2 (ドキュメント)
libpng Home Page (libpng)
Test Suite of PNG Icons (テスト画像を入手できるとこ)

GLDPNGの開発者、tarquinさんのホームページ（開発終了？）

Delphiで使えるその他のPNGライブラリ
いろいろ lpng-px

PNGライブラリで必要となるZLIBのホームページ（Paint Shop Proでも必用です。）
zlib Home Site

Delphiで使えるZLIB
delphi zlib

FineViewでの対応
0.53まではlibpngを。0.55からGLDPNGを使わせてもらってます。

GIFファイル形式 (.GIF)
JPEGやPNGと同様ホームページで使うことのできる画像形式。アニメーションGIFといった他の画像形式にはない特徴を持つ。特許問題になったことでも有名。

デコード、エンコードにはLZWというUnisys社の特許技術が使用されてます。

HIROPONさんのホームページでは、ＧＩＦの特許問題についてわかりやすく書かれています。

ViXでは、ユニシス特許に抵触しないGIF画像のデコードを使っているようです。

仕様書
http://www.w3.org/Graphics/GIF/spec-gif87.txt

FineViewでの対応
Anders MelanderさんのTGIFImage(v2.2)を使用してGIFの符号化/復号化を実現しています。
TGIFImage for Delphi | MelanderBlog

このコンポーネントは、Delphi 2007から標準のコンポーネントとして正式に採用されています。

日本人の作者による画像形式
日本人の作者によって作成され国内で広く使われていた画像形式。MAG/PI/PIC/PIC2/Q0などがあります。

MAGファイル形式 (.MAG)
お絵かきソフト「まるちぺいんと」で使われていた画像形式。

MAG形式の生みの親、Woody-Rinnさんのホームページ

TMAGImageの開発者、masさんのホームページ

TMAGImageは、DelphiでMAGを実装するためのコンポーネントです。Delphian Worldからも入手できます。

Cベースの開発環境で簡単に実装するには、道上氏によるM2BCがあります。

FineViewでの対応
対応済み。v0.53までは、道上さんのM2BC ver1.07を使用させて頂きました。 Delphiへの移植にともないv.55から、masさんのTMAGImageを使用させて頂いてます。

PICファイル形式 (.PIC)
ここでのPICは、やなぎさわさん作のPIC形式です。以前、DoGAでも使われていました。

PICの仕様書
 Piの仕様書

試しに作ってみたPIC用デコーダ。デコード時に稲妻が走ります。

FineViewでの対応
PIC形式には対応済み。Pi形式は未対応。

ERIファイル形式 (.ERI)
Entis氏による画像形式。MAGやPICと比べて新しい画像形式です。

FineViewでの対応
0.53までは対応。 ERI形式は今後Entis氏作のERINAライブラリーもしくはERISAライブラリーでサポートされる模様です。 Delphiへの移植に伴い、現バージョンのFineViewでは対応してませんが、Susieプラグインを使うことで表示可能です。

Delphi リソース形式 (.DCR/.RES)
DCRファイルは拡張子こそ違うものの、RESファイルと同じ構造をしてると思われます。

参考にしたドキュメント
32bitリソースファイルのドキュメント（英語 HTML文書 wotsitから入手可）
↑を部分訳したもの主に表の部分だけを訳してあります。緑色の部分は勝手に書き加えました。（汗；

FineViewでの対応
DCRファイルのリソース（カーソル、ビットマップ、アイコン）を表示します。画像以外のリソースタイプには対応していません。リソースが複数個登録されてる場合は、一番最初に検出したリソース（= RCスクリプトで一番上に定義されたリソース）を表示します。

DCR(RES)をDelphiで使う方法
まず、作り方
1) 最初に、拡張子RCのテキストファイルを作成します。 ex) sample1.rc
2) 続いて、テキストを開いてリソースを定義します。

-------------------------------------------------- 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

3) リソースコンパイラでコンパイルします。
> BRCC32 sample1.rc

RESファイルの作り方はこんな感じです。コンパイルするとsample1.rcと同じフォルダ内にsample1.resというファイルができているハズです。ちなみに、BRCC32は、Delphiのbinフォルダにあります。コマンドラインツールなのでDOSプロンプトから実行します。

次に使い方
DelphiのIDEに移ります。メインフォームのimplementationのあたりのコードを示します。 RESファイルはちゃんとパスのとおったところに用意しておいてください。（RESファイルをDCRにリネームしても同じように使うことができます。）

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

interface
	（省略)
implementation

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

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

最後に
RESファイルに、定義されてないリソースタイプのリソースを格納することができます。格納したリソースを使うにはその形式の展開コードが必用になります。展開用コードがストリームに対応していれば、簡単にリソースを扱うことができます。

問題になるのは、その形式の展開コードがストリームに対応していない場合です。ファイルに落として読み込むということもできますが、とてもスマートな方法とは言えません。ただ妥協できるならこの方法が楽です。残念なことに、TMediaPlayerはストリームに対応していません・・・（涙。

画像形式のリンク集が得られるＨＰ
各画像形式の仕様書は、Wotsitから得ることができます。

Wotsit
画像形式に限らず、いろいろなファイル形式の仕様書が入手できます。

Programmers Heaven
画像をデコードするためのサンプルコードなどを入手できます。

The Graphics File-Format Page
画像形式や、3D形式の仕様書が入手できます。

tnt
3D形式の仕様書が入手できます。→リンク切れ

AVALON
FTPサイト。3DSや、OBJのリソースが落ちています。→現在アクセス制限あり

デコードの補足
マッキントッシュやアミガといったマシンは、エンディアンがインテルのマシンとは異なります。これらのマシンで生まれた画像形式をデコードするには、スワップ処理が必要です。
→ エンディアンとスワップ処理。

TIFF, TGA, IFF, SGI, BMP, PSD などの画像形式では、RLEというエンコードが使われてます。ちなみに、エンコード＝圧縮＝符号化。デコード＝展開＝復号化です。 RLEは、画像以外の分野でも広く使われています。
→ エンコーディング RLE。