hirax.net::Keywords::「画像処理」のブログ

■ニッチなニッチな個人サーバ構成を図解する　

　下の図は、「ニッチなニッチな個人サーバ」の構成を図解になります。何が「ニッチなニッチ」かというと、個人でサーバを動かしていて・ソフトウェアやネットワークとはほぼ無縁の生活をしていて(何しろApacheの綴りをすべてApachと間違えて書いているくらいです)・それでいて、コンテンツ提供のサーバソフトを自分でいじったりしている・・・という状況を、とりあえず「ニッチ」としてみたのです。

　hirax.netはそんな「ニッチなニッチな個人サーバ」であるわけですが、そのサーバ構成をふと図解してみました。というのは、あまりにサーバ構成がツギハギだらけになってきて、自サーバを整理するために、サーバ間の繋がり・関係を（自分のために）図解してみたのです。

　hirax.netは現状4台のサーバで動いています。「大容量ファイル配信」「小さな静的ファイル配信」「メインコンテンツ配信用のRailsアプリを動かす mongrelクラスタ」「いくつかの実験サービスを動かすRails アプリを動かすmongrelクラスタ」「SQLサーバ」「各種数値演算用サーバ」「画像処理サーバ」といったもを、それぞれのPCに役割分散することで動いています。役割分散させると管理が面倒なので、いずれは、まったく同じ機能・同じ構成の仮想サーバにでも処理を分散させるようにしたいのですが、なかなか、そんな再構築作業ができないでいます。

　そもそも、「ニッチなニッチな個人サーバ」ですから、そんな増改築は本来必要でないように思いますが、遊びがてら色々増改築を繰り返してきた結果、こんな古い温泉街の老舗ホテルのような、あるいは、四国かどこかにあるという「軍艦島マンション」のような入り組んだ手作りサーバ構成になってしまいました。

　「Rails入門書を読んだ勢いで、個人サーバ用のアプリをRailsで書いて、自アプリでサーバ運用する人」も少なくないだろう、と思います。便利なブログツールやサーバもたくさんあるわけですが、（素人ながらも）自分で何か作ってみたくなり、適当に動かしている人もチラホラいるだろう、と思います。そんな「素人が手軽に動かすことができるお手軽・気軽なサーバ構成」は、一体どういうものなんでしょうか。他の方々のサーバは「軍艦島マンション」構成にはなってはいないものなのでしょうか……。

■画像処理WEBアプリを簡単作成用「ビジュアル言語」を作る　

　「ビジュアル言語」風の画像処理WEBアプリの叩き台を作ってみました。 いえ、正確に言えば、そんな「ビジュアル言語」環境を作ってみました。つまり、画像処理WEBアプリを簡単に作れる!?「ビジュアル言語」を作ってみた、ということになります。

　ここで言う「ビジュアル言語」という言葉には、３つの意味合い・特徴があります。

1. 処理構造をグラフィカルな部品・ワイヤーで表現・作成すること
2. 各場所で処理されている「データが見える」こと
3. 部品・ワイヤーを並べ終わった画面そのものが「アプリケーション」のGUI画面となっていること

　1,2番目の項目だけでなく、この3番目の点を意識しながら作ってみました。といっても、「叩き台」なので、デザインはいかにも開発時用（デバッグ用のデータ構造が見えたりする）など、イマイチな部分はありますが、イメージを掴むことはできるだろう、と思います。

　ブラウザ上の操作感は（UI周りはWireItライブラリを使っていて）YahooPipesを模範にしています。また、処理データ構造は（YahooPipesを意識した）ImagePipesに準拠するようになっていて（つまりある程度緩い規約にもとづいたJSONになっていて）、 「オブジェクト」に対してユーザが何かしたり、あるいは、入力部に他の部品からメッセージを受けた時に、Javascriptでクライアント内部で処理をしたり、あるいは、サーバに対して同期リクエストを送ることで、出力結果を生成し、そして出力ポートの先にある他部品に結果メッセージを送信する、という作りになっています。

　下の動画がその「叩き台」アプリケーションの動作動画です(高解像度画像もここに置いておきます)。この動画が「何をしているか」を箇条書きすると、

1. 「画像をアップロードするフォームパーツ」を作り（出力はアップロードされた画像情報を示すJSON）
2. 入力を２出力に分岐する（JavaScriptで書いた）部品を配置し
3. 入力された(JSONで表現されている)画像を表示する部品を置いて
4. 部品間をワイヤーをつなぐ

これで、「画像アップロード＋いくつかの処理＋画像表示」WEBアプリケーションのコード実装や画面設計が終了した……ということになります。というわけで、画像処理WEBアプリを簡単に作れる!?「ビジュアル言語」を作ってみたのです。「画像処理ジェネレータを作るジェネレータ」みたいなものの高機能版を、「ビジュアル言語」で作ってみたわけです。

　WireItがYahooUIライブラリに実装された折にでも、適当にサービスを立ち上げてみたいな、と思っています。

■続 WEBベース「ビジュアル言語」を作る　

　『画像処理WEBアプリを簡単作成用「ビジュアル言語」を作る』で作成した叩き台のイメージは、「データ処理フローを並べ終わった瞬間に、基本的にはアプリケーション作成（と簡単なテスト）が終わっている」というものです。「並べること」が「 プログラミング」「画面デザイン」「初期テスト」のすべてを兼ねていること、が大切で、そういう「ビジュアル言語」を作ってみたかったのです。「アイコンを並べたあとに "RUN" ボタンを押してプログラムを走らせる」とか「アイコンを並べコーディングをした後に、今度は画面デザインを別画面で設定する」なんて面倒なことはしたくない、と思ったのです。

　そういう作りをイメージした理由の一つは、画像処理アプリケーション（おそらく多くのデータ処理アプリケーション）は、「画像アップロード（データ入力）部」「スライダーやテキスト入力による数値入力部」「データ選択」「フィルタ（演算）処理」「種々の特性の表示部」といったせいぜい数種の比較的限られた機能を並べることで作られていることが多い、ということです。その並べ方にアプリケーションの特徴があったりするわけです。

　また、それぞれの基本パーツはどれもJavaScriptで覆われていることで機能拡張を楽にしたい、という構想設計ならぬ妄想設計に基づいています。5,6種類の数少ない機能を持つ基本パーツを作ってしまえば、あとはいかようにでもできるだろう、というイメージです。

　たとえば、「フィルタ（演算）処理」なんかは、JavaScript中のSJAX先アドレスを変えるだけで（それらアドレスに応じたサーバ側コードは当然用意するとして）、色んな画像処理フィルタを自由に作ることができるわけです。そういう風に基本パーツを継承した派生パーツを作っても良いし、あるいはパーツの組み合わせでさらに新しいパーツ（関数）を作っても良いわけです。以前 Imagenerator でもやったように、いくつかの簡単な機能を組み合わせたものを、さらに一個のパーツ（関数）として保存できるようにしておけば、機能を増やすことも簡単にできるだろう、ということになります。

　……と書くより、ひとことで言ってしまえば「何だかそれって面白いな」と自分で思えるものを作って遊んでみたかった、ということですね。
　データの送受信が、(下の動画（高解像度版）のように)グニュグニュと揺れ動く振動や画像の変化で実感・体感できたり、それがJavaScriptでラップされている設計構造とか「何だかそれって面白い・楽しいかも」と遊んでみたかっただけ、なんですよね。ひとことで書いてしまえば。

■コミック調動画処理ソフトを作る　

　以前作ったコミック調動画処理ソフトを少し手直ししたものを、ここ (comicmovie.20090921.lzh) に置いておきます。たとえば、下の動画はラトルバック動画にコミック調動画処理をかけてみたものです。"Video"ボタンを押してAVIファイルを開くと自動的に処理が始まり、元AVIファイルと同じ場所に"hoge.avi.result.avi"という処理結果動画を出力します。

"Open"ボタンを押すとJPEGファイルを開くことができて、"Save"ボタンで処理後ファイルを保存することができます。つまり、静止画に対するコミック調処理も行うことができます。

■近いうちに公開したいAPI2つ　

　空き時間に2つのサイトのソースを見直してみた。一つは"Imagination you make"で、もう一つは「雑誌DE流行マップ」だ。どちらもRuby on Railsで作っていて、"Imagination you make"の方がRuby on Railsで最初に作ってみたWEBアプリで、「雑誌DE流行マップ」の方がつい最近作ってみたものだ。そして、どちらも、近いうちにそれぞれのAPIを作ってみたいと思っている。"Imagination you make"の方は画像処理APIとして、そして、「雑誌DE流行マップ」の方はキーワード→ポジショニングマップAPIとして。

　「雑誌DE流行マップ」には、"Make up Awards!"という腕試しプログラムを作った時に作ったコードの一部を、機能としては公開しないままに入れている。どういうことかと言えば、"Make up Awards!"で作ったFaceモデルを公開しない前提で使っている。つまり、雑誌の表紙に登場する人たちの顔の特徴・化粧の特徴・髪の色・唇の色・頬の色・・・そんな特徴を「雑誌DE流行マップ」は保存し続けている。今思い出してみれば、"Make up Awards!"でも、そんな特徴量を結局のところ使わないままに保存していたのだけれど、「雑誌DE流行マップ」もやはりそんな特徴量を集め続けている。

　いつか、「ファッション＝流行」というものを眺め直してみたいと思う。データソースがずっとあるのなら、10年も20年もクローラを動かし続けて、女性や男性たちの顔や、その装いがどのように変わっていくかを記録してみたい、とふと思う。