TEOの普及に向けて

TEOプロジェクトとは，画像処理研究用の画像フォーマット， および，その画像フォーマットをC言語で扱うためのライブラリを 作成することを目的として発足したプロジェクトです． 本ページは，TEOが今後も普及していくことを願って， TEOに関するいくつかの誤解を解いた上で， TEOは安心して使うことができるということを紹介します．

目次：

(1) TEOプロジェクトの概観
(2) TEOに関する誤解
(3) 安心して使えるTEO

■ 卒業してからも使う可能性があるのでライブラリには依存したくありません

以下，「(3) 安心して使えるTEO」 でも詳しく説明しますが， ソースは完全にオープンであり，業務用にも使えるライセンスとなっています． 将来的にも安心して使い続けることができます．

■ PPM画像で十分なので，独自フォーマットには興味ありません

画像処理を目的とした場合には， 不可逆圧縮フォーマットは適切ではありませんので， ベタ画像であるPNMフォーマット(2値画像：PBM，濃淡画像：PGM，カラー画像：PPM) のような表現方法が好まれます． しかし，画像処理においては， 8bit(0〜255)，3プレーン(R,G,B)に収まらないことが多いのです． 例えば，画像の微分やSobelオペレータを適用しただけで， 画素値が負の値となってしまいます． フーリエ変換すると，浮動小数点として画素値を表現しなくてはなりません． TEO画像フォーマットは，負の値や浮動小数点など， 用途に応じて様々な型の画素値を格納できるように設計されています． また，可逆圧縮により，画像データサイズを小さくすることが可能です． それでいて，ほぼPNMと同じようなシンプルな構造になっています．

確かに，8bit, 3planeに収まる場合は，PPM画像フォーマットで十分でしょう． そのような場合でも，PPM画像をTEOライブラリで扱う， PPM画像をTEOToolsなどの周辺ツール群で処理するなど， TEO環境を利用することも可能です． gzipで圧縮したPPM画像も，TEOライブラリならそのまま読み込むことができるなど， 様々なメリットがあります．

■ ベタ画像の入出力ぐらい自分でできますが...

確かに，ベタ画像の入出力は，それほど難しい処理ではありません． しかし，TEOライブラリを使えば，様々なメリットがあります． 前述したように，圧縮したファイルがそのまま読み込めるのも大きな特徴ですが， デバッグモードは実に便利な機能です． デバッグモードによって，生産性は大幅に向上します．
デバッグモードでコンパイルされたプログラムは， 実行時にさまざまなチェックを行い， 怪しい動作があれば直ちに詳細な原因を表示してくれます． 例えば，画像をX方向に微分するために，以下のようなコードを書いたとします．

  for (y=TeoYstart(In); y<=TeoYend(In); y++)
    for (x=TeoXstart(In); x<=TeoXend(In); x++)
      pixel = TeoGetPixel(In,x+1,y,0,TEO_UINT8)-TeoGetPixel(In,x,y,0,TEO_UINT8);
        :

このプログラムは，残念ながらセグメントエラーとなります． しかし，デバッグモードでコンパイルし，実行すると，

[TEO WARN(main.c:38)] Out of x range. (x = 640 [0 <= x <= 639])

と警告されます．このメッセージから， ソースmain.cの38行目で，X座標は0〜639の範囲内でないといけないのに， 範囲外の640という値になっていることがわかります． 通常のデバッガでは，ここまではわかりません． この他にも， 画像処理にありがちなミスをいろいろ見つけてくれます． バグがなくなったことを確認してから， デバッグモードをはずしてコンパイルすることで， 高速な実行バイナリを得ることができます． つまり，同じソースから， 安全なバイナリと高速なバイナリの両方をコンパイルできるわけです． このデバッグモードを使うと，くだらないバグに悩まされることが少なくなり， 生産性が向上します．

以上ように，基幹ライブラリには， 単なるベタ画像の入出力を越えた機能が実装されています．

■ オープンソースである

当然ながら，ソースは完全にオープンです． しかも，ソースはコンパクトにまとめられていますので， 何か気になることがあればソースを読んで確かめることも容易です．

■ 特定のOSやアーキテクチャに依存していない

特定のOSやアーキテクチャに依存する部分は， 周辺ライブラリとして整備し，基幹ライブラリ libteoとは完全に分離しています． そのため，libteo自体は，今後登場するであろうOSやアーキテクチャでも， 引き続き使用することができるはずです． intは32bitであるとか，Intel系MPUではメモリ上のバイトオーダが逆になるとか， そのような迷信には一切依存していません． 実際に，Pentium*/Athlon/Sparc/MIPS等の32bitマシンだけではなく， 64bitマシンであるDEC Alphaでも問題なく動作しています． また，Solaris/Linux/FreeBSD では相当の実績がありますが， Windows/MacOS/IRIXでも動作実績があります．
libteo自体は，一部の機能を除いては， ANSI C準拠で書かれているため， ANSI Cコンパイラがある限りは(滅多なことではなくなるとは思えません)， 将来的にも安心して利用し続けることができます． また，ANSI Cに準拠していない部分も，コンパイル時に切り放すことができます．

■ 枯れている

1997年に初期バージョンが完成し， 1998年にデバッグモード機能を追加して以来は， 基本的に新たな機能は追加していません． 今後はバグフィックスだけに限定する予定です． また，1997年以来， 複数の機関でコンピュータビジョン研究のために酷使されていますが， 大きな問題もなく利用されています． 完全に枯れてしまったと言えるでしょう．

■ 将来性がある

前述の通り，libteoの自体の開発は止まっていますが， TEOプロジェクトの活動は今でも盛んです． X Window System上のTEO画像ビューアである teoeyes, C++でTEOを使う libteopp, TEOをより使いやすくするユーティリティライブラリ libteoutil, RubyからTEOを使う RubyTEO, PerlからTEOを使う PerlTEO, OpenCVとTEOを両立させる変換ライブラリ libteo2iplなどなど， 現在ではTEOをより使いやすくするための周辺ツール群の整備が盛んです． 将来的にも安心して使い続けることができると思います．

■ 研究だけではなく業務にも使える

libteoはGPLではなく， The FreeBSDライセンスになっています． これは，特に業務で使う場合に重要な特徴です． つまり，libteoに何らかの修正を加えて利用し，商品として販売する場合にも， ソースを非公開にできます． 一方，GPLでは必ずソースを公開しなければいけませんので，大きな特徴でしょう． もちろん，libteo自体もGPLの制限に引っ掛からないように， GPL由来のコードは一切使っていません．