boost.GILは凄い！開発者の頭の良さがビシビシと伝わってくる！
ということで、今回はGILに関しての紹介記事を書こうと思います。
概要
あなたは画像処理のエキスパート。顧客の依頼で、8bitのRGB画像を処理するアルゴリズムを記述していたとします。ところが対象となるデバイスの仕様を調べていた際に、実はRGBA画像にも対応させなければいけないことが分かりました。面倒だと思いながら書いていた矢先、さらにBGRやABGR,さらには16や24bitにも対応したアルゴリズムを記述しなければならないことが判明しました。なんということでしょう…これらの画像すべてに対してアルゴリズムを書くなんて、とてもじゃないですがやってられない。やめてくれ！って感じです。
boostに付いてくるGILを用いることで、画像に対する操作をよりジェネリックに行うことが出来ます。具体的に言うと、あなたはGILの作法に従ってアルゴリズムを書き下すだけで、メモリに展開されている画像データの色空間、色深度、レイアウト、配置順に『関わらず』、任意のデータ配置に対して適用できるアルゴリズムを作ることができるのです。最初に提示した問題が一気に解決しちゃいました。
長所と短所
長所
- 画像処理に対してジェネリックなアルゴリズムを記述でき、少ない記述量で全てをカバーできる。処理速度も普通に書き下した場合と同等(静的なポリモーフィズムしか使っていないので、コンパイル時に必要な計算はすべて終わっている)。
- 様々なアダプタが存在している(e.g. subimage_view, rotated180_view)ので、ばんばん遅延評価して一気に処理を行うことが可能。
- 普通の人が普通に書くよりも、GILのアルゴリズムに従って書いたほうが大抵の場合早い
- ソースコードが比較的読みやすい。コード量も短くなる。
- 誰が作ったかわかんないもの利用したくねーという方も安心のAdobe製。画像処理の専門家が作ってるのでとても合理的。
短所
- テンプレートを多用しており『非常に難解』。
- 全てを抽象化しているために『非常に難解』。
- C++と画像処理の両方に秀でていなければ記述できないので、使っている人が殆どいない。
- 英語のサイトですら文献が殆どない
Viewの概要
GILでは、画像に対する操作はすべて『View』を起点にして行われます。Viewは以下のような構造を持ち、ジェネリックな操作を行えるよう工夫してあります。
View
|-- Locator
| `-- Pixel
| |-- Channel
| `-- Layout
| |-- Color Space
| `-- Channel Mapping
`-- dimensions
(上図はMemory basedで、画素のメモリ配置がInterleavedな場合のView構造)
以下のリストで、それぞれの名称がどのような役割を持っているのか説明します。
- View: (x, y)座標における画素値の他、特定のX、Y方向におけるイテレータや全ピクセルにわたって捜査できるxyイテレータなど、「様々な手法によって画素にアクセスできる手段」を提供する、一種の抽象的なクラスを表しています。画像の幅、高さを表すdimensionsと、後述するLocatorを持ちます。(注: 画像のデータを実際に保持している『わけではありません』。Viewはあくまで、対象の画素値へとアクセスするための『手段』を提供しているだけに過ぎないのです)
- Locator: 画像の2次元的な『位置』を表します。ランダムアクセスイテレータの2次元版のようなものと考えれば理解が早いと思います。具体的に言いますと、 *loc あるいは *(loc + point2(dx, dy)) などで現在の画素値や(dx, dy)だけ離れた位置の画素値を取得することは出来ますが、Locatorの現在地(xy座標)や画像の大きさ(width, height)を取得することはできません。
- Pixel: Locatorによって返される画素値を表します。後述するChannelとLayoutを持ちます。
- Channel: 画素の色深度を表します(8bit, 16bit, etc…)。各型の取りうる最大値、最小値も取得できます。
- Layout: 色空間のレイアウトを表します。ちょっと分かりにくいので、下の2つを読んだほうが早いでしょう。
- Color Space: 色空間を表します(e.g. RGB, CMYK, HSV, Gray, etc…)。
- Channel Mapping: 実メモリ上での配置順を表します(e.g. RGB, BGR, etc…)。ただし、この情報はInterleave画像のみ用います(Planar画像だと配置順は関係ないため)。
アルゴリズムを用いて書いてみる
それでは実際にGILに付属しているアルゴリズムを用いて実際に書き下してみます。以下の2つのアルゴリズムを用いてみましょう。
boost::gil::transform_pixel(const View& src, const View& dst, F functor)
対象のピクセルを受け取って別のピクセルを返す関数を、全ピクセルに対して適用します。この関数は、画素値と出力値が1対1対応である場合に用います(e.g. 明度、コントラスト, レベル補正, トーンカーブ, etc...)。
boost::gil::transform_pixel_positions(const View& src, const View& dst, F functor)
周囲のピクセルの値を元に結果となるピクセルを返す関数を、全ピクセルに対して適用します。transform_pixelとは、受け取る引数がロケータであるという点が異なっており、周囲の画素値を元に実際の出力値を求める場合に有効です(e.g. Blur, Sovel, Laplacian, etc...)。
実際にやってみれば、どんな感じか分かるでしょう:
#include <boost/gil/gil_all.hpp>
#include <boost/gil/extension/io/jpeg_io.hpp>
#include <opencv2/imgproc/imgproc.hpp>
using namespace boost::gil;
struct change_brightness {
public:
change_brightness(): weight_(1.0) {};
explicit change_brightness(float weight): weight_(weight) {};
template<typename Pixel>
Pixel operator()(Pixel src) {
typedef typename channel_type<Pixel>::type channel_type;
Pixel dst;
for(int c=0; c<num_channels<Pixel>::value; ++c) {
dst[c] = cv::saturate_cast<channel_type>(
static_cast<float>(src[c] * weight_));
}
return dst;
}
private:
float weight_;
};
struct change_brightness_locator {
public:
change_brightness_locator(): weight_(1.0) {};
explicit change_brightness_locator(float weight): weight_(weight) {};
template<typename Locator>
typename Locator::value_type operator()(Locator loc) {
typedef typename Locator::value_type pixel_type;
typedef typename channel_type<Locator>::type channel_type;
pixel_type src = loc(0, 0);
pixel_type dst;
for(int c=0; c<num_channels<Locator>::value; ++c) {
dst[c] = cv::saturate_cast<channel_type>(
static_cast<float>(src[c]) * weight_);
}
return dst;
}
private:
float weight_;
};
template<typename Locator>
struct x_gradient_functor {
public:
explicit x_gradient_functor(Locator loc)
: left_(loc.cache_location(-1, 0)),
right_(loc.cache_location(1, 0)) {};
typename Locator::value_type operator()(Locator loc) {
typedef typename Locator::value_type pixel_type;
typedef typename channel_type<Locator>::type channel_type;
pixel_type src_left = loc[left_];
pixel_type src_right = loc[right_];
pixel_type dst;
for(int c=0; c<num_channels<Locator>::value; ++c)
dst[c] = (src_left[c] - src_right[c])/2;
return dst;
}
private:
typename Locator::cached_location_t left_;
typename Locator::cached_location_t right_;
};
template <typename SrcView, typename DstView>
void x_gradient(const SrcView& src, const DstView& dst) {
assert(src.dimensions() == dst.dimensions());
transform_pixel_positions(
subimage_view(src, 1, 0, src.width()-2, src.height()),
subimage_view(dst, 1, 0, src.width()-2, src.height()),
x_gradient_functor<typename SrcView::locator>(src.xy_at(0, 0)));
}
int main() {
const char* filename = "lena.jpg";
rgb8_image_t src_image;
jpeg_read_image(filename, src_image);
rgb8_image_t dst_image(src_image.dimensions());
transform_pixels(
const_view(src_image),
view(dst_image),
change_brightness(1.5));
jpeg_write_view("result_normal.jpg", view(dst_image));
transform_pixel_positions(
const_view(src_image),
view(dst_image),
change_brightness_locator(2.0));
jpeg_write_view("result_locator.jpg", view(dst_image));
x_gradient(const_view(src_image), view(dst_image));
jpeg_write_view("result_gradient.jpg", view(dst_image));
return 0;
}
また、画像の出力例を下記に示します:
 |
| 左から、元画像, change_brightness, change_brightness_locator, x_gradientの結果 |
main()についてはどんなことをやってるのか大体感覚的に理解できるはずですので、とりあえず3つのファンクタに関して説明を加えていきます。
typedef typename channel_type<Pixel>::type channel_type;channel_type<T>::typeで実際に使われているチャネルの型を取得できます。Tにはピクセル、ロケータ、ビューのどれを指定しても構いません。今回の場合ですと8bitのチャネルを指定しているので、型にはunsigned charが入ります。
num_channels<Pixel>::valueピクセルを構成しているチャネルの数を取得できます。この場合ですと色空間がRGBなので値には3が入ります。この値はコンパイル時に決定されるので、最適化を用いることでループ展開が行われ、速度的なオーバーヘッドはありません。
typedef typename Locator::value_type pixel_type;ロケータが返すピクセルの型を取得できます。この場合ですとrgb8_pixel_tが入ります。
pixel_type src = loc(0, 0);()演算子によって現在のピクセル値を取得しています。他にも*演算子でイテレータっぽくアクセスすることもできます。
explicit x_gradient_functor(Locator loc)
: left_(loc.cache_location(-1, 0)),
right_(loc.cache_location(1, 0)) {};ロケータの変動値をキャッシュしておくことで、高速化を図ります。Locator::cached_location_tによってロケータのキャッシュ型を取得します。キャッシュを使ったアクセスには[]演算子を用います。仰々しく言っていますが、要はstd::ptrdiff_tみたいなものです。移動する値は同じなんだから記憶しておきましょうということです。
subimage_view(src, 1, 0, src.width()-2, src.height())subimage_view()によって画像の領域を切り出しています。これはアダプタで、実際の評価は遅延的に行われます。
まとめ
大体こんな感じでアルゴリズムを組んでいくのがGIL流です。遅延評価とアルゴリズムを武器に、ジェネリックなアルゴリズムを作っていきましょう。
余談
C++に関しての記事を投稿するのは正直に言って『少々怖い』です。大筋では合っていると思いますが、完全に合っているという自信があまりないからです。ですが、GILに関しては本当に、本当に参考となる文献が少ない。サンプルコードも多くない。こういった中でこの記事が少しでも参考程度になっていただければ幸いです。
それと、ざっくり組んでしまったのでこうしたほうがいいよとか、間違い等あれば遠慮なく言ってもらえると助かります。
(2/16) 追記: ソースコード若干の修正、説明や画像例の追加。
(3/31) typo: e.q. -> e.g.
0 件のコメント:
コメントを投稿