AlxisDataBlog-プログラミング


MathJax = {
  chtml: {
    matchFontHeight: false
  },
  tex: {
    inlineMath: [['$', '$']]
  }
};






TIFF 画像のファイル構造は意外と複雑です。TIFF は IDF(ImageFileDirectory) エントリータグという識別子を用いることにより様々な仕様の画像を複数枚スタックできる構造になっています。openCV などの汎用的なライブラリでは正確なデータを読み取ることが難しいことがあります。そこで登場するのが libTIFF というライブラリです。


libTIFF のインストールは、バイナリではなくソースコードを使いましょう。cmake で makefile を生成して、make, make install すれば OK です。zlib 関連のエラーが出て make できない場合は、cmake で zlib のチェックボックスを外して再チャレンジしましょう。


インストールできたら早速 API を叩いてみましょう。


libTIFF は動作中に WARNING を吐き出す恐れがあります。このコンソールによる遅延を回避するためには


TIFFSetWarningHandler(NULL);


としておくと良いです。tif ファイルを読み込むためには


TIFF *pTif;
pTif=TIFFOpen("ファイル名","r");


とします。幅や高さなどの基本的な情報を読むためには


TIFFGetField(pTif,タグの種類,値を受け取るアドレス);


という風に書きます。良く使うであろうタグを紹介しておくと、


TIFFTAG_IMAGELENGTH = 高さ情報
TIFFTAG_IMAGEWIDTH = 幅情報
TIFFTAG_SAMPLESPERPIXEL = チャンネル数
TIFFTAG_BITSPERSAMPLE = チャンネル当たりのビット深度
TIFFTAG_PAGENUMBER = スタックするページ数
TIFFTAG_COMPRESSION = 圧縮方法
TIFFTAG_SAMPLEFORMAT = 画素値の型


ディレクトリ数を取得するには


int wDircoun;
wDircount=TIFFNumberOfDirectories(pTif);


とします。TIFF 画像のデータ部の読み込みはラインごとに実行します。ラインサイズは


int nScanlineSize;
nScanlineSize=TIFFScanlineSize(pTif);


で取得します。


unsigned char *lpszBuf;
lpszBuf=_TIFFmalloc(nScanlineSize);


で、ヒープ領域を確保して


int dir;
TIFFSetDirectory(pTif,dir);


でスコープしたディレクトリに対して


TIFFReadScanline(pTif,lpszBuf,j,0);


j ライン目を読み込みます。ビット深度 8 のときは unsigned char で、16 のときは unsigned short でキャストすれば良いです。カラーのときの lpszBuf の構造は RGB の順序になっています。


8,16 bit であれば以上の手順で読み込めるのですが、32bit(float 型)の場合は若干やり方が違いますのでご注意を。(written by J.Nishigata)


Copy Right 2020-現在 ALXIS DATA, Inc. All Right Reserved.

libTIFF を使ってみた

AlxisDataBlog-画像処理


MathJax = {
  chtml: {
    matchFontHeight: false
  },
  tex: {
    inlineMath: [['$', '$']]
  }
};






画像の情報量というと、1 フレーム当たりの情報量と捉えがちですが、現実的に重要なものは 1 フレーム当たりではなく単位時間当たりの情報量(ビットレート)です。現実社会では、情報の価値は時間とともに低下します。


処理速度が重要であるからといっても、高スペックのマシンを高負荷で稼働させれば良いわけではありません。この点にも留意すれば、単位電力量当たりの情報量と考えた方が、より現実的かもしれません。


人間が目視で情報を得る場合には「1 フレーム当たりの情報量」を上げれば良いのですが、画像利用の自動化が進むこれからの時代では、「単位電力量当たりの情報量」という形で、システムとしてのパフォーマンスが重視されます。


単位電力量当たりの情報量を大きくするためには、画像処理アルゴリズムの計算量を圧縮しなければなりません。特に外部ライブラリを参照する場合、そのライブラリで何ができるのかということも重要ですが、計算量が充分に圧縮されているかも同様に重要です。


入力データ量に対する処理時間をプロットすれば、計算量を知ることは容易です。イニシャルの処理が入っているかもしれませんが、重要な部分は大きいデータ量に対する応答でしょう。漸近的な振舞いがわかれば充分です。


入力データ量に対して線型な処理時間の応答をするアルゴリズムは優秀です。パフォーマンスを阻害することはないので、積極的に利用しましょう。一方、入力データ量に対して2乗の処理時間応答をするアルゴリズムは避けた方が良いでしょう。


一般的には、線型よりも log(入力データ量) 分だけ大きい応答をするアルゴリズムが多いように感じます。


付け焼刃ですが、負荷の大きいアルゴリズムは、高負荷であることを隠蔽するように非同期で走らせると、欠点をごまかすことができます。


アルゴリズムを開発される場合には、目的の出力を得ることと同時に計算量の圧縮も実行されることをお勧めします。正しい出力が得られるかプロトタイピングを行なってから、次に計算量を圧縮するという、2 ステップに分けて開発を進める考え方もありますが、多くの場合作成するプログラムは全く違ったものとなり 2 重開発の無駄が生じます。正しい結果が出るか否かをリスクヘッジするためだけにプロトタイピングを行なうことはお勧めしません。(written by J.Nishigata)


Copy Right 2020-現在 ALXIS DATA, Inc. All Right Reserved.

Sentinel EMS サーバの環境構築