おまえらボロノイ図好きだよな？！　私も大好きです。 そんなワケで、fumix さんが「超速ボロノイ図（Fortune's algorithm）」で、alumican_net さんが「Sketch of Voronoi」でワンダフってたボロノイ図を高速に描画するアルゴリズム Fortune's algorithm を使って、私もボロノイってみましたよ。 Fortune's algorithm の原理はまったく分かりませんが、alumican_net さんのブログに書いてあるとおり、knd さんの「Fortuneのアルゴリズムの可視化」「forked from: Fortuneのアルゴリズムの可視化」を拝見すると何が起きているのかは、とてもよく分かりますね。 原理はよー分からんくても、成果はいただいちゃうオレ様ちゃんといたしましては、Speedy Voronoi diagrams in as3

前回は、 Cocoa 風のコーディング手法を発見し、今まで組んできた Mediator パターンに方向修正が発生した、という話でした。 で、再掲ですが、実装としての変更点は以下のとおりでしょう。 Colleague としては、自分が呼び出す Mediator のメソッドへの参照を、パブリックな変数として追加する Mediator としては、自分の内部で Colleague を生成したときに、Colleague に呼び出してもらいたい notify 相当メソッドを割り当てる 以下は、各クラスの変更のうち、それに部分だけを掲示したものです。 IColleague セッター notify を新たに付け加えます。 package { public interface IColleague { // Mediator の参照 function set mediator(value:Mediator)

Mediator パターンでプログラムを組んでみて、こんな感じになるのかなぁ、と思っていたら、新たな情報を見つけてしまった！　というのが前回までのあらすじ。 その情報はこちらに書かれていました。 デザインパターンをObjective-Cで - Mediator (2) それによると iPhone アプリのプログラミングには以下のような作法があるとのこと（以下「Cocoa 作法」と呼ぶ）。 Colleague（= View）から Mediator（= Controller） へのアクセスを弱める（Mediator と Colleague 結びつきを弱める）ため、（中略）Controller があらかじめ View に対して、実行してほしいメソッドを登録しておく、というスタイルを採用している。 前回組んだ Mediator パターンでは、Colleague からのイベント呼び出し処理は Med

前々回は Colleague、前回は Mediator と各クラスのコード実装を見てみましたが、それらを組み合わせて実際に組んだものは↓ 今回は Mediator パターンを使って、そこそこ複雑なプログラムを組んでみた雑感をば、つらつらと書き綴ってみたいと思います。 MVC の分割に悩まずに済む プログラムの機能ごとにクラスをけっこう細分化するので、どの機能は Model 組み込むか、どの機能は Controller に組み込むか……　と迷わずに済むなぁ、って感じ。 特に、ユーザ入力のために使用される表示物が、View なのかそれとも Controller なのか、未だに迷い続けている私としては、そういうことに悩まされずに済むというのは非常にありがたい。 ところで前々回 Colleague のコードを組んだとき、Mediator との通信パターンで以下の三つに分類できそうだ、ということを見

今回は Mediator クラスを組んでみます。 以下に Mediator パターンの本質に関わるコード部分を抜書きします。 このプログラムに登場する構成員の複数が使用するデータは、共用データとして Mediator で保持するようにしました。 // BitmapData public function get bitmapData():BitmapData { return _bitmapData; } public function set bitmapData(value:BitmapData):void { _bitmapData = value; } private var _bitmapData:BitmapData; // スライダーの値 public function get value():Number { return _value; } public function

今回は Colleague に属するクラスのコードを組んでみます。 まず Colleague の interface 全文は以下のようになります。 Colleague から Mediator 、Colleague から Mediator。 この二つの情報の流れのために必要なものをそれぞれ一つずつ定義します。 package { public interface IColleague { // Mediator の参照 function set mediator(value:Mediator):void; // Mediator が呼び出すこの Colleague のメソッド function update():void; } } クラス 複数ある Colleague に属するクラスの一部について、Class 文内のコードを示します。 示すのはボタンクラス、ビューアクラス、画像処理クラスの三

今回、Mediator 学習用に作成するプログラムの仕様は以下のようにしたいと思います。 プログラム起動時、ステージ上に以下のものが配置される 画像をロードするためのボタン（以下「ロードボタン」と呼ぶ） 画像をセーブするためにセーブボタン（以下「セーブボタン」と呼ぶ） コントラスト調整用スライダー（以下「スライダー」と呼ぶ） 画像を表示するための表示物（以下「ビューア」と呼ぶ） 上記要素のうち、プログラム起動時ユーザが操作できるのはロードボタンのみとする ロードボタンを押すと FileReference によって画像ファイルが読み込まれ、ビューアに表示される。同時にロードボタンは操作不能になり、スライダーとロードボタンが操作可能になる スライダーを動かすことで画像データのコントラストが変更される。その状況はビューアにリアルタイム表示される セーブボタンを押すと FileReference

前回、Mediator パターンを調べたときは Obsever パターンとの違いがよく分からなかったんですが、それは複数の Colleague が単一クラスの事例だったせい。 Mediator パターンが本来の力量を発揮するのは、Colleague がいろいろなクラスの混成部隊のときなんですね。 ってなわけで、再履修を始めるにあたって、本来の Mediator パターンの使われ方について、ちゃんと見てみますよ。 参考書は← 「Head Firstデザインパターン ―頭とからだで覚えるデザインパターンの基本」では、Mediator パターンは『その他まとめて』の扱いだったので、いまいちでした。 Madiator パターンは以下の2種類のクラスによって構成されるパターンです。 周囲に影響される有象無象（Colleague） その有象無象に指示を与える司令官（Mediator） Colleagu

効率的なプログラミングを求めて、デザインパターンを学び、MVC に辿り着きました。 で、私流のコーディングですが、ドキュメントクラス直下のクラスは Model、View、Controller 各1個ずつ計3個に限定してるんです。 Controller クラス内で minimalComps の何らかのクラスを複数生成する、というような感じで M、V、C 以外の何らかのクラスを生成することはありますが、ドキュメントクラスで生成するクラスはあくまで MVC を各1個ずつ置く、という書き方をしていて、結果、必要とする機能を MVC いずれかに収めようとして、ムリな設計をしてるんじゃないか、という疑念に苛まれています。 要求される機能を MVC のどれに書けばいいのか、ってことでよく悩むんですよねー。 例えば WebCam を使ったプログラムの場合、Camera や Video に関わるコードは M

実はこれがやりたくて、平面分割アルゴリズムを捻くり回していたのです。 元ネタは言わんでも分かりますね？　ってゆーかタイトルでバレてますね！ そう、tha の THINK ART です。 Wonderwall に続いてまたしても tha のパチモン。 でもパクるつもりが、ヘボ過ぎて、泣ける。 ロー・スキル者による目コピーは限界がありますな。 ところで、いつかは MUG SHOOTER を組んでみたいと思ってるんですよねー。 でも何となくですが、道具を ActionScript から openFrameworks に切り替えないと作れないような予感がする。 ここで技術的なコメントをちょっとばかり。 今までの二作品、Manic Monday と BallMan は、二値化した BitmapData に対して平面分割アルゴリズムを適用していました。 今回は二値化ではなく三値化しています。 以前クラ

一度取得した知識は何度も何度も使い回すよ、その2。 今回の細工どころは分割された矩形部分を正方形ではなくて、円で描くという部分。 ところでこういう黒い円で構成される人物ってビジュアルイメージ、割と最近、音楽系の場所で見た覚えがあるんだけど、何処だったっけかなー。 ブックマークしてないから探せないや……　まぁいいか。で、第2弾は↓ [WebCam] BallMan - wonderfl build flash online

一度取得した知識は何度も何度も使い回しますよ。 先般から何度もこのブログの話題に乗せた平面分割（Subdivision）の話です。 他人様のコードを fork したり、そのまま WebCam に適用したり、読み込んだ画像に適用したりと、いくつか wonderfl に投稿してきました。 それらはいずれも研究成果的な意味合いのものばかりだったので、ここらでちょっくら画像を単に分割するんじゃなくて、より応用作品っぽいものを作ってみたんですわ。 まず一つ目は↓ [WebCam] Manic Monday - wonderfl build flash online タイトルに意味はありません。何となく頭に浮かんだんです。イッジャアナ、マーニックマンデー、オーオゥオー。 見てのとおり、矩形の塗りつぶし色に細工を施しています。 この平面分割のアルゴリズムは4分木再帰処理です。 今回、塗りつぶし色を HS

こないだ、新宿紀伊國屋書店で「ディジタル画像処理」という本を見つけました。 この本は（財）画像情報教育振興協会（CG-ARTS協会）によるCG検定の公式書籍で、その名のとおりコンピュータによる画像処理を網羅的に扱った、つまりは教科書ですねー。 フルカラーかつ画像が豊富。何か面白げ＆分かりやすそうだったんで、思わず衝動買いしちゃいました。 今回はその本から仕入れた知識で「疑似カラー」なるものについての話。 疑似カラーというのは、グレイスケール画像をフルカラー画像にするものだそうです。 といっても色を復元するものではない。 RGB 各チャンネルごとに、グレイスケールの濃度値に対応したトーンカーブを用意する。 そのトーンカーブは任意に異なるものとし、そのようなトーンカーブを適用することで、モノクロ画像に色がつく。 それを疑似カラーと呼ぶとのこと。 具体的な事例として、以下のような図がP98に掲載

先般、「Beyond Interaction ―メディアアートのためのopenFrameworksプログラミング入門」に掲載されていたサンプルに触発されたコードが紆余曲折を経て「誰でもスーラ」というウェブカム作品になりました。 今回のはその変奏曲とでも呼ぶべき作品。題して「ジャギ男」。 センスないにもほどがあるので誰か良い名前つけてください。 単に wonderfl 貼りつけるだけなのもアレなので若干の技術論なんぞ。 「誰でもスーラ」は一定領域のカラーチャンネルを分解し、各チャンネルの濃度に応じたサイズの正方形を3つ作り、それを BlendMode.ADD で合成するということをしていました。 今回のはカラーではなく、グレイスケール情報から一定領域の濃度を取得し、それに応じたサイズの正方形を作る、ということをしています。 まぁつまりは「誰でもスーラ」は「ジャギ男」の発展版って位置づけなわけ

ウチにいらっしゃっる皆さんは実際に参加なさったことと拝察しますが、私はと言えば、公式サイトの動画で見たんです Adobe FLASH PLATFORM CAMP Tokyo。 で、Mario Klingemann 先生ですよ！ 私も実際に参加した FITC Tokyo 2009 における発表内容と割と被る部分が多かったんですが、新しい知見も得られました。 その一つが、以前 fladdict さん発信で wonderfl 内でもちょこっと盛り上がった画像の平面分割。 それの Mario さんによるロジックを、今回の発表で見ることができたのは収穫ですね（この絵が出てきたところです）。 fladdict さんのエントリー「コンピューターに絵画を描かせる」に以下の記述がありました。 ちなみにQuasimondoの人は、ConvolutionFilterを使ってエッジ検出して分割をしようと試みていま

先日「Beyond Interaction ―メディアアートのためのopenFrameworksプログラミング入門」に掲載されていたサンプルに触発されて、FileReference で読み込んだ画像ファイルを網点風に変換する作品を wonderfl に投稿しました。 今回は、それをウェブカムに適用したものを wonderfl に投稿しましたよ。 題して「誰でもスーラ」。 コンセプトは同じでも、静止画像とウェブカメラではまったくアルゴリズムが変わってしまったという話。 [WebCam] 誰でもスーラ -Anyone Seurat- - wonderfl build flash online ウェブカム仕様となるとけっこうな処理速度が求められるわけですが、「何でもスーラ」のアルゴリズムでは遅くて遅くてお話しにならん状態でした。 BitmapData のメソッドの速度とか、あまりシビアに考えたこ

ウチで扱うネタだから「そうめん」ってのはもちろん ActionScript Thread Library のことでありんす。 発表当初、多くの Flash 使いの方々が、このライブラリについてブログに書いてらっしゃいました。 でもその内容は「何かスゴそう」「何か便利そう」「ドキュメントはここ（とリンク提示）」「イベントリスナー地獄から抜け出すにはこれを使おう」等々、非常に漠然としたものか、もしくは公式の記載そのままなものばかりで、いまいち心ときめく情報に触れることができませんでした。 発表されて4ヶ月にもなることだし、そろそろ「そうめん」に関する具体的な記述をどなたかがお書きになったかしらと、Google やテクノラティで検索をしてみたものの、今もってめぼしいエントリーをゲットすることができませぬ。 頼りは公式ばかり也な状態が絶賛継続中でした。 やっぱ他力本願はイカンね。 ってなワケで公式

2012/01/20 追記 再び、判別分析法による閾値の自動計算について(1) 再び、判別分析法による閾値の自動計算について(2) この記事に興味を持たれた方は、より進化した↑をご参考ください。 －－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－ 前回はBitmapData#threshold を使っておこなう二値化の概要を見ました。 Threshold メソッドというのは、引数として指定した閾値に基づいて処理をおこなうわけですが、その閾値は処理対象の画像によって当然変わってくることが考えられます。 ではその閾値は如何に設定したらよろしかろう、というのが今回のテーマです。 一番確実なのは、ヒストグラムを表示して、閾値を目視で調整する方法らしい。 でもオートマチックを目指す処理工程で、そんなステップは踏めん。 そこで計算に頼る方法の模索になる

画像処理シリーズ、今回から二値化についての話。 今更いうまでもないでしょうが、二値化というのは、以下のように定義できます。 このシリーズを学ぶにあたって参考にしている画像処理本を見ると、もっぱら1ピクセルずつ走査するアルゴリズムが記載されています。 「C言語で学ぶ実践画像処理」では、閾値を場所によって変えるというヘビーな解説（P26）もあったりします。 でも、当ブログで扱う言語は ActionScript 3.0。 ActionScript 3.0 で二値化ならそんな面倒なことしないでオッケー。 BitmapData#threshold というメソッドを使うことで、簡単に二値化が実現できるのは皆さま先刻ご承知のとおりです。 しかし「簡単に」というのはあくまでコーディング記述が簡潔におこなえるという意味であり、使いこなすという意味では、むしろ難しいメソッドと言ってよろしい。 "Foundat

昨日レポった『セシル・バルモンドの世界』で受けたインスピレーションを形にしてみましたよ。 っても、自然界に潜む美のパターンとしては一番ありきたりなヤツだがな。 葉序の開度によるパターン描画です。 フィボナッチ数の話が出ると必ず取り上げられるアレですね。 マニュアル、オート、プリセットの3モードで、それぞれパターンを描画します。 マニュアル操作は、最上部のスライダーのつまみを左右に動かすことでおこないます。 その下には現在の開度を度数で表示しています。 その下にはラジオボタンが17個並んでいますが、一番下以外の16個では、プリセットされた開度によるパターンを描画します。 一番下のラジオボタンを選択するとオートモードになります。 現在パターンを描いている開度から、0.1をインクリメントし続けます。 他のラジオボタンを選ぶか、スライダーのつまみを動かすと、オートモードは終了します。 以下、プリセ