Blan'Fo Straight

BACKxFOREのt-dashさんが開発、公開した2D画像に対するDOF*1フィルタ。
Terminalで操作するため、シェルスクリプトを使って連番画像を扱うことができる。
面白いのは口径触*2をサポートしていることだ。レンズは感光剤の中央から見ると円形だが、画像の端部には前玉と後玉が重なって見える部分のアーモンド形を通して光がやってくる。このため、ボケの形がアーモンド型になったり、光量が低下したりする。LOMOなどのトイカメラでは光学系のコストダウンが激しく、後玉のサイズが小さかったりするため、口径触が強く発生する。
ところで、このソフトウェアの前のバージョンにはIrisFilterの開発者から特許侵害の申し立て(のようなもの)がついていた[Blan'Fo Straight開発者のBBS no83を参照]。このような申し立ては特許が成立してからでないとやっちゃいけないんじゃないのかな?

ここで挙げられている請求項の式自体、申し立て(のようなもの)があった時点で使っていなかったとのことだが、一度公開を停止して、指数対数変換ルーチンとアイリスマスクを用いない新しいバージョンを再公開した、とのことである。

素晴らしいソフトウェアを作ったt-dashさん。ありがとう。
しかし、一足先に行かれたらしい(勝手にライバル視)。

類似品も禁止できるの?

特許の請求項に抵触しない、同様の機能を持ったものに対して、特許が及ぶのであろうか?

IrisFilterは、日本やアメリカなどで特許を申請しています。 類似品の開発にはご注意下さい。フリーウェアでも特許侵害となります。

たとえば、LZW圧縮特許はUNISYSの物だが、同様の機能を持つランレングス圧縮全てに対して、UNISYSが特許権を主張できるのであろうか。IrisFilterが、ユーザーフレンドリーで、プロシューマに対して素晴らしいサポートを行うソフトウェアであることは聞き及んでいるのだが、このような姿勢は損だよね。

otsuneさんの反応

「評判」大事ですね。この件だけではなく、他の開発者に対しても似たような圧力をかけていたりして…
例えば、圧力を掛けられて開発を止めたソフトのユーザーが、潰した側のツールを使うのか?というのもあるんですよね。業務以外の場合。
で、ちょっと技術的な話です。

SSE2だとかAltiVecをゴリゴリつかって実用的な速度で動作するようになれば、

Iris Filterと似たようなPhotoボケフィルタを作りました(特許の絡みがあるので回避しつつクォリティアップする方法を思いつくまで公開しません。そゆ意味で先を越されたなぁ)が、計算そのものよりもメモリ転送のロスタイムが大きいように思いました。このようなボケフィルタの場合、ボケ範囲全てに対して、ある画素が持つエネルギー値を書き込む必要があるのですが、その範囲が円状に広がっていますので、計算そのものよりもメモリ転送を以下に効率よくやるか、というアルゴリズムをしっかり作る方が高速化に効くように思います。
こういうことを考えると、64bit化(halfならRGBAがメモリブロックに入っちゃう)というのは早く到来して欲しい技術だなぁ、とも。

*1:DOF【Depth Of Field】:被写界深度

*2:口径触【こうけいしょく】:ビグネッティングとも言うことがある。