SoundPotentialFrameの開発で簡単にできそうだったのでOpenGLシェーダーのフィルター利用機能実装を試みてみました。しかし Web で簡単に入手できる情報には古いものも多く、見よう見まねで適用するだけでは使えなかったりで動くようになるまで四苦八苦。Processing で OpenGL シェーダーが利用可能になったのはバージョン 2.0 で、その後 Processing も OpenGL も(シェーダ記述言語GLSLも)バージョンアップを重ねているため、いろいろ情報に齟齬が生じている模様です。いや、Processing 公式の説明をちゃんと読めって話なわけですが。
具体的には次のあたりで引っかかっりました:
- Processing からの入力を受け取る uniform 変数の名前を
textureSamplerとしているものがありますが、2018 年現在はtextureになっています。 - Processing の入力からピクセルの値を抽出する関数を
texture2Dとしているものがありますが、GLSL の最新版ではtextureになっています(texture2Dでも動きます)。 texture関数の第二引数に与える値の計算を、gl_FragCoordを vec2 型の変数で割っているものがありますが、非除数の側にgl_FragCoord.xyとメンバーを明示する必要があります。明示しないとコンパイルエラーになります。- 出力用 out 変数は、かつては
gl_FragColor固定だったそうですが、現在は任意の名前を利用できます。
これらの苦難を乗り越えて作成したはじめてのシェーダーが次になります。グレースケール変換。
変換式は C マガジン 1998 年 10 月号の特集「アルゴリズム大全」、「第 4 章 画像のためのアルゴリズム」(昌達 K'z(末次和孝))に掲載されたものです。これで白黒テレビ相当になるのだとか。
Processing のシェーダーを使わないfilter メソッドはピクセルを愚直にひとつひとつ処理しているので速くなりようがありません。OpenGL シェーダーのフィルター利用はその欠点を解消します。GLSL でフィルターを記述する手間はかかりますが、Processing が標準で用意する程度のものなら Web にあるサンプルだを活用すればそれほどむずかしくはないと思います(たぶん……私がひっかかったような点をあらかじめ回避できれば……)。私もシェーダー利用で表現の幅を広げたいところです……えーと、その、広げられる表現なるものが私にあったとしての話ですが……