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にあるサンプルだを活用すればそれほどむずかしくはないと思います(たぶん……私がひっかかったような点をあらかじめ回避できれば……)。私もシェーダー利用で表現の幅を広げたいところです……えーと、その、広げられる表現なるものが私にあったとしての話ですが……