hirax.net::Keywords::「対数変換」のブログ



2001-08-07[n年前へ]

「ボケ」た背景で包み込め 

デジカメ画像をキレイにボカそう アルゴリズム編

 最近、新しいデジカメを物色中である。私はこれまではFinePix4700zを使っていたのだけど、そのFinePixが半年程度で壊れてしまった。というわけで、C-4040ZOOMがどんなものか期待しているところである。

 壊れたFinePixと言えば、そもそも壊れたFinePixは一台ではなかった。私はすでにFinePixを二台も買っているのだ。そして、もうすでに二台とも壊れてしまっているのである。連続殺人事件ならぬ、連続カメラ自殺事件なのである。

 まず、一台目に買ったFinePix700ははメキシコのティファナでポケットから落としたら、バッテリーから電源が供給されなくなった。もちろん、ACアダプターを使えば立派に動くのだけれど、それでは少しばかり機動性に欠けてしまう。まさか発電機を持ち歩くわけにはいかないし、コンセントの近くでしか撮影することができないとなると、それは非常に困ってしまう。そこで、すかさず二代目としてFinePix4700zを私は買った。ところが、買ってから半年位たったある日、今度は勤務先の駐車場でポケットから落としてしまった。すると、今度はファインダー視野がズームに連動しなくなって、なおかつレンズがまるでジョイスティックのようにあらゆる方向に曲がるようになってしまった。

 こんな風にデジカメはとっても壊れやすくて、半年毎にデジカメ出費を強いられる私に周囲は「落としたオマエが悪い」と非常に冷たいのである。残念なのだ。「そういうのは壊れたんじゃなくて、壊したんだ」と被害者である私をまるで加害者のように告発する人さえいるのである。連続カメラ自殺事件は実は他殺で、しかも犯人は私だと告発する輩さえいるのだ。ひどい話である。
 

 ところで、C-4040に期待しているのは、コンパクトで、レンズアダプターが使えて、レンズがF1.8と明るいことなのである。コンパクトなのは持ち歩くために必要だし、私はなんと言っても超広角デジカメが欲しいのだが、そんなデジカメはないので、ワイドコンバーターを付けたいのでレンズアダプターが必要なのである。明るいレンズの方は、うす暗い中でも撮影する時に重宝しそうなので、少し期待しているのである。
 

 ところで、この位明るいレンズであれば、もう少しぼかすことができるものだろうか?デジカメで写真を撮ってもどうしてもボケない。35mmフィルムを使っているカメラなどと比べるともう全然ボケない。もうほんとにボケない。

 例えば、35mmカメラで135mm F4.5開放のレンズなら、ピントの合ってない背景はこの位はボケる。これは京都の哲学の道近くにある吉田山で撮った写真だ。
 

35mmカメラで撮影した例 135mm F4.5?

 

 ピントが合っている位置以外は光がボケて、キレイなボケが発生する。どちらの写真も絞りは開放で撮影しているので、後ろの風景はほぼ丸くボケている。ぼかせばキレイというわけではないけれど、背景などがごちゃごちゃしている中で対象物だけを浮き上がらせたい場合には、「ボケ」させるととても良い感じになる。
 

 しかし、デジカメではそうそう簡単にボケた画像を撮影することはできない。35mmフィルムに比べて、CCDサイズが小さいからである。35mmカメラよりAPSカメラはもっとぼけなくて、それよりデジカメはさらにボケないのである。そんな様子を見るために、二台目として買ったFinePix4700zで「ボケ」を意識して撮影してみたものが下の写真である。手前の植物にピントが合って、奥の道の先はボケてはいるのだけれど、それでも先程の写真などとは比べものにならないほどわずかしかボケていない。
 

在りし日のFinePix4700zで「ボケ」を意識して撮影してみた写真
(昼過ぎの箱根山中で)

 ところで、このような画像の「ボケ」を考えるとき、「ボケ」た画像をシャープに復元しようという話は非常にポピュラーな話題である。例えば、本「できるかな?」でもこれまでに

といった感じで遊んできた。また、さらには「恋の形」を復元しようとしたとか、このようなアプローチを遥か昔に考えていた漱石の「文学論」を振り返ってみたりしたきたのである。しかし、これらはいずれも「ボケたデータを復元する」という問題であった。

 一方、この逆のアプローチである「シャープなデータをボケたデータにする」という問題も結構ポピュラーである。例えば、音楽をホールやライブハウス風にボケた音にするDSPはかなりの数のオーディオ装置に付けられている。これも、もともとはシャープな音声データが部屋の中でボケていく様子をシミュレートする回路である。また、画像に関する話題でも、ピント位置をずらした複数の画像から任意の「ボケ」画像を作成するといった話題もたまに見かける。

 そこで、「できるかな?」でもデジカメ画像を35mmカメラ風にキレイにぼかすことに挑戦してみることにした。今回は、まずはアルゴリズムを確認して、次回以降で簡単プログラムを作成してみることにしたい。

 まずは、似たようなソフトウェアがあるかどうか、Googleで適当なキーワードを使って検索をかけてみると、IrisFilter(http://www.reiji.net/iris/)というソフトウェアがあった。これは、「写真のぴんぼけを再現する」というフィルターだった。サンプル写真などを見てみると、これがなかなかきれいだった。例えば、早朝の御殿場の路上を「在りし日のFinePix4700z」で撮影した写真にこのフィルタをかけて、「ボケ」を加えてみたのが下の画像である。
 

Iris Filterでデジカメ画像を「ボケ」させたもの
オリジナル画像
Iris Filterで処理したもの

 ここではこんな六角形の絞り形状をを用いてみた。右の処理画像中の、車のテールランプや車の下部を眺めてみると、鋭いハイライト部が六角形に光っているのがわかだろう。確かに、「ボケ」がカメラの絞り形状になっていて、良い感じである。

 WEBページの記載によれば、このIris Filterは「フィルム特性曲線を利用し、レンズから通った光がフィルムを感光させる様子を再現しています」ということである。なんでも、特許も国内・USP共に出願済みということだが、特願2000-100042もU.S.PTO 09/772532も未だ公開にはなっていないようで、残念ながら特許の内容を読むことはできなない。

 このWEBページの記述の中で面白いのは、「データ上の数値をそのまま拡散させる従来のPhotoshopをはじめとした画像処理ソフトと違い、実際のフィルムに当たる光の量(露光量)を逆算し、その露光量をもってピントがずれている様子を再現します」という歌い文句でPhotoshopの「ガウスぼかし」と比較広告してある部分である。

 試しに、先の画像をIris Filterで「ボケ」を加えた画像と、Photoshopの「ガウスぼかし」とで「ボケ」を加えた画像を比較してみると、下の二枚の画像のようになる。確かにIrisFilterの売り文句通り、こうして比較してみるとPhotoshopガウスぼかしが写真の「ボケ」っぽくないのに対して、IrisFilterの「ボケ」が写真のそれっぽいことが良くわかる。
 

Iris Filterの処理画像(左)とPhotoshop ガウスぼかしで処理した画像(右)の比較
Iris Filterで処理したもの
Photoshop ガウスぼかしで処理したもの

 さて、お仕着せのソフトを使ってみるだけではなくて、自分でデジカメ画像をキレイに「ボケ」させてみることにしたい。というわけで、hirax.net風「ボケ」フィルターの動作を考えてみる。

 まずは、毎度のことだがオリジナル画像が「ボケ」る様子を計算する式は

逆フーリエ変換(  フーリエ変換( オリジナル画像 ) x フーリエ変換(ボケ具合 ) )
と表すことができる。詳しくは、「宇宙人はどこにいる?」の回でも読んでもらうことにして、簡単に言えば周波数領域でオリジナル画像とボケ具合を掛け算をしさえすれば良いのである。つまり、今回のデジカメ画像をぼかす場合だったら、
  1. デジカメ画像と「ボケ」具合をそれぞれフーリエ変換し周波数空間に変換
  2. 周波数空間で乗算を行う
  3. 逆フーリエ変換して実空間に戻す
とハイ!「ボケ」画像の出来上がり、というわけである。ボケ具合が小さい場合などは、このやり方よりもずっと計算量の小さいやり方はあるわけだけれど、とりあえずこのやり方はとても単純明解なので今回のように試しでやってみるにはとっても楽な方法なのである。また、ここでいうボケ具合というのは、こんな形状の「ボケ」具合のことである。
 

 じゃぁ、早速やってみようとなるわけだが、その前にもう一つ注意することがある。それは、RGB画像の数値というものは実は元々「明るさを対数変換した値」であるということなのである。人間の目も含めて世の中の大抵の材料は対数的な感度を持っている。例えば、人間の目に「2倍明るい」という場合に、光は「2倍明るい」というわけではない。その場合には指数的にX^2倍明るいのである(ここで、xの値はそれぞれのデバイスによって色々と違う)。その明るさをRGB画像の数値データにする時に、明るさの対数をとってLog[x,X^2]で2という数値として表しているわけだ。

 RGB画像の数値が「明るさを対数変換した値」だというようすの一例を示すと下の図のようになる。
 

RGB画像の数値というものは実は元々「明るさを対数変換した値」である
片対数軸で表した
横軸 = 0〜255の数値データ
縦軸 = エネルギー
線形軸で表した
横軸 = 0〜255の数値データ
縦軸 = エネルギー

 逆に明るさからRGB画像の数値データへの変換グラフは例えばこんな感じである。RGB数値で200と255と言っても実はその明るさは大違いであることがわかると思う。
 

 

 だから、この手の処理を行う際には、まずは指数変換してから処理を行い、そしてその後対数変換してやらなければならないわけだ。もちろん、今回のデジカメ画像をぼかす場合にも、RGB画像の数値をまずは指数変換した後、「ボケ」演算を行って、その演算結果を対数変換でRGB画像の数値に戻してやらなければならないのである。といっても、別に難しい話ではなくて画像を扱う装置だとごく当り前の話だ。

 そう、「ボケ」演算のhirax.net風レシピはたったこれだけ〜というわけで、早速このレシピに従ってhirax.net風デジカメ「ボケ」フィルターをかけてみたのが下の画像である。キレイな「ボケ」画像ができあがっていることが判ると思う。
 

hirax.net風デジカメ「ボケ」フィルター
キレイな「ボケ」画像のできあがり〜

 ところで、デジカメ画像のRGB画像の数値を指数変換したものに「ボケ」演算を行ったわけだけれど、もしRGB画像の数値そのものに対して「ボケ」演算を行ったら、どんな結果になるだろうか?つまり、「データ上の数値をそのまま拡散させる」やり方をしたら、どうなるのだろうか?そこで、試しにRGB画像の数値そのものに対して「ボケ」演算を行ってみるとこんな結果になる。
 

RGB画像の数値そのものに対して「ボケ」演算を行ってみた結果
キレイじゃない…

 何だかボンヤリとにじんだだけの「キレイじゃない」写真になってしまっている。それは、当り前である。本来2倍明るいものはX^2倍明るいわけで、すごく光の量は2倍どころでなく多いわけだ。それが広がる量を仮にRGB数値そのまま2倍として扱ってしまうと、その光の部分は薄暗くなってしまう。コントラストのはっきりしない、ぼんやりとした写真になってしまうわけだ。ちゃんと、X^2倍のデータとして扱ってやらなければならないわけである。

試しに、指数処理したものと線形処理をしたものとを並べてみるとその画像の違いがよくわかるだろう。
 

指数処理した画像(左)と線形処理をした画像(右)の比較
hirax.netレシピの
キレイなボケ画像(指数処理)
 

キレイじゃないボケ画像(線形処理)

 さて、今回はデジカメ画像の「ボケ」フィルターのhirax.net風レシピを確認してみた。次回(と言ってもいつになるか…)以降に、このレシピに従って実際にソフトを作成していこうと思う。
 

 ところで、「文学論」の中で漱石は「ボケ」は焦点的印象又は観念に付随する情緒を意味する、と言っている。それは、言い換えれば「何かの出来事をきっかけとして感じた怒り・悲しみ・喜びなどの感情がボケである」ということだ。そして、さらに言えば、写真で背景をぼかすということは、つまり「背景にある出来事が生みだした怒り・悲しみ・喜びを広く混ぜて包み込む」ということなのである。

 だから、何かを撮影する時に対象物の背景をぼかすということは、「背景にある出来事が生みだした怒り・悲しみ・喜びを広く混ぜて対象物を包み込んで、そして対象物を浮き上がらせる」ということなのかなぁ、とぼんやりと考えてみたりする。そんな写真は対象物を写しこんでいるのと同時に、それを包みこむ背景も写しこんでいるンだろうなぁ、と考えてみたりする。
 

2002-02-18[n年前へ]

「非線形処理+畳み込み処理」の公知資料 

 特開2001-216513を出願した方からメールをもらった。「自然対数を使う数式自体は昔からあるとは思いますが、画像処理ソフトで、この計算を使ってピンボケを作り出すソフトまたはそのアルゴリズムが存在したのかご存じないでしょうか。」ということだった。
 「非線形処理+畳み込み処理」はおそらく公知資料があるのではないか、ただし、非線形処理と畳み込み処理のいずれもが実装されたソフトは昔から多々あるが、それをワンアクションで実装したソフトは無いかもしれない、と返事を出した。また、「ところで、私自身は特許はあまり好きではないです。といっても、個人としてはですけど。それに、特許を申請するXXさんの考えも良く理解できます。」と書いた。で、メールの最後に
 「それで、少し知りたいのですが、私は自分で作ったプラグインなどもいつもそうしているように何かの話のネタを作って、ソフト自体はフリーで配布すると思います。で、私以外にも自分で画像処理やプログラミングをしている人は多いので、そんなこともあるだろう、と思いますが、そういうときにXXさんはどうされるつもりでしょうか?」
 と書いた。それへの返事は来ていないが、もう少し調べてみた。構成としては、特開平08-241407や特開平09-130609が近いか。で、昔に遡れば公知資料もあるかしらん。しかし、特許調査で公知資料探しなんてまるで仕事みたいでイヤだな。
SUB 画像ボケが「非線形変換→畳み込み→非線形」で表されるとの記述は昔の教科書に載ってた。SUB 特開平09-181966畳み込みでボケ味を出す、複数画像を撮影することで任意の距離のボケを実現。 by オリンパスSUB 特開平09-130609等LUT→ローパスフィルター→LUTで画像ボケ信号を作成 by 富士写真フィルムSUB 特開平07-200817フィルタリングによりボケ画像を作成する ダイキン工業SUB 特願平09-542474対数変換をした上で畳み込みを行う画像変換 サイエンスアンドテクノロジーSUB 特開平08-285726畳込みによるカメラなどの光学系シミュレーション ホーヤSUB 特開平08-241407非線形変換→畳み込み→非線形変換の画像変換 IBMSUB 特開2000-20691非線形変換+デコンボリューションによるぼけ復元、背景の説明中に、非線形変換+畳み込みによるボケ計算を説明 キヤノン

2002-08-04[n年前へ]

キラキラ光る景色を描く 

「木漏れ日」プラグイン「リン」を作る

 夏の休日には、朝早く起きて西伊豆の松崎の先にある「雲見・岩地・石部」辺りへ行って、海の中でお魚と戯れてみたり、海辺の温泉に長々とつかってみたりする。例え休日であっても朝早く行けば混雑とは無縁だし、海に照りつける太陽と温泉とビールの三点セットが揃えば、夏の景色としてはとても素敵なのである。

 とはいえ、今日は朝寝坊したので、松崎までは行かずに「無名だけれどとても良い感じの場所」へ行った。海辺に車を止めて、景色を眺めて、ほんの少しの時間泳いでみた。下はその西伊豆の某所で眺めた「今日見た景色」だ。
 

西伊豆の某所で眺めた「今日見た景色」

 「雲見、岩地、石部」であれば温泉も海も最高だけれど、西伊豆の辺りには他にも「海水が綺麗で、人も全然いなくて、トイレも水もある」ような場所はいくつもある。これはそんな場所の一つ。

 県道から海辺の集落に向かう道沿いには素晴らしい滝もあって、まるでプレイステーション2のゲームソフト「ぼくのなつやすみ2海の冒険篇」の世界に迷い込んだかのよう。

 実際に眺めていた景色はもっとキラキラしていたハズなのに、その片鱗も残っていない…。それはひとえに写真を撮ったワタシのウデが悪いから。
 

 海辺でワタシが実際に眺めていた景色は、もっとずっと「キラキラ」していたハズなのに、残念なことに上の写真を眺めてみても、その片鱗すら残っていない。揺れてる波間も、足下の濡れている岩も、眩しい太陽だってもっとずっとキラキラしていたハズなのに、上の写真はただボンヤリした写真になってしまっている。それは、ひとえに写真を撮ったワタシのウデが悪いからである。もちろん、それが一番の理由である。クヤシイ話ではあるが、確かにワタシのウデは悪いのである。

 とはいえ、言い訳を少しばかり書くならば、実際に眺めていた景色がもっとずっとキラキラしていた理由は他にも考えられる。例えば、ワタシ達が景色を眺めるときには、目の前にかかる髪の毛や、睫毛や、目の水晶体を通して景色を眺めているわけで、それらの中で光が回折したりして、キラキラとまるで虹のように光が輝いて見えたりするからだ。そのため、例えば夜空の星の形、本来は丸いはずの星の形、が星型に見えたり、木漏れ日が虹のように輝いて見えたりする。

 そんな様子をもしカメラで再現しようとするならば、ケンコーが出しているクロスフィルターのようなものをつけることになる。しかし、手軽さが取り柄のデジタルカメラでわざわざそんなフィルターをつけるのは面倒くさいし、第一人によって見え方は違うから、「ただ一つのフィルター」で写真を撮ってしまうのは少しばかりイヤな気がする。例えば、「私は目の前に髪の毛がたくさんかかってしまって邪魔なのー」という人もいれば、「最近、抜け毛がハゲしーなぁ…、目の前に髪の毛がたくさんかかっていたあの頃が懐かしぃ…」という人もいるわけで、そんな二人が眺めた景色はきっと全然違うハズなのである。「百人の人がいれば百人百葉様の景色を眺めている」わけで、写真を撮る時点でただ一つのフィルターをデジカメにはめて写真を撮ってしまうのも面白くない。フィルターに限らず、何事も一つの枠にはめてしまうのは良くないのである。

 デジカメの便利なところは、何より撮った後の画像加工が自由自在、というところなわけで、撮った後に「眺めた景色」を再現するように画像を加工してやれば、「写真を撮るときには素直な景色を撮って」「その後で自分が眺めたキラキラ光る景色を蘇らせる」ということができる。そこで、今回はそんな「キラキラ光る景色を描く」Photoshop用のプラグインを作ってみることにした。そして、ワタシの写真の腕の悪さを「技術の力」で誤魔化そうと思うのである。
 

 といっても、基本的には、「ボケ」た背景で包み込めの時の処理を基にして、

  1. 色々な畳み込みの演算カーネル形状を用意し
  2. 演算カーネルのサイズを強度やアルファチャンネルの情報を元にしてピクセル単位で可変にし
  3. カーネル演算を対数変換有無などに対応する
ようにするだけで、比較的簡単に「キラキラ光る景色を描く」Photoshop用のプラグインを作ることができる。光が輪を作ってキラキラする景色を描くプラグインなので、輪を意味する"RINg"と名付けてみた。木漏れ日は時折鈴(りん)の音のように見えるので、その響きにもかけてみた。 ちなみに、RINgプラグインは今のところ、Windows2000(XP?)のPhotoshop6.0,7.0でしか動かないと思うが、いつもと同じようにアルファ版のものをここにおいて(+説明)おく。

 RINgの出力サンプルを少し眺めてみると、下の画像のようになる。まず最初のサンプル画像は、クローバーの写真に「虹十字状」の畳み込みの演算カーネルを用いて、処理をしてみたものだ。左のオリジナル画像では、朝露を載せて光るクローバーを眺めるときに私達が感じる「キラキラしたようす」がほとんど写っていないが、右のフィルター後の写真では私達が睫毛などを通して景色を見るときに感じる虹色のキラキラした自然?な景色が映し出されている。
 

職場の駐車場で眺めた景色
オリジナル画像

左の画像にRINgをかけたもの
(畳み込みの演算カーネルは虹十字状)

 そして、また下の写真は、新宿から初台へ歩く途中で眺めた木漏れ日の向こうのビルの景色だ。左のオリジナル写真はクッキリ・ハッキリ写っているのだが、ただ「それだけ」である。太陽の光を遮る木々の葉っぱも、そこから降り注ぐキラキラする木漏れ日も写ってはいない。しかし、右のRINgが描いた景色の方では、ボンヤリと、だけど強く光る初夏の「木漏れ日」が確かに写っているのである。夏の空気が写っているかのようなのだ。
 

新宿から初台へ歩く途中で眺めた景色
オリジナル画像

左の画像にRINgをかけたもの
(畳み込みの演算カーネルは円状)

 もちろん、このRINgは「ボケ」た背景で包み込めの時の処理を基にしているので、写真のボケも再現することができる。例えば、六角形の畳み込みの演算カーネルを用いて、画面全体に同じ演算カーネルで処理をかけると下の右の写真のようにピンボケの写真を再現することができる。
 

画像全体に同じようにRINgをかけてみた例
(畳み込みの演算カーネルは六角形状)
オリジナル画像
左の画像にRINgをかけたもの

 また、アルファチャンネルも選択してフィルタ処理を行うと、自動的にアルファチャンネルの情報を基に畳み込みの演算カーネルサイズを画素毎に変化させる。だから、例えばアルファチャンネルに距離の情報を入れておいてやれば、下の写真のように距離に応じたボケなども再現することができる。この写真では画面中央下の領域はピントが合ってていて、そこから離れるに従って、ピンボケの具合が大きくなっている。もっとも、現在のバージョンでは大雑把に計算してみただけなので、空の部分などに疑似輪郭などがずいぶんと発生してしまっている。きっと、それはいつかのバージョンで直すつもりなのである。
 

距離の情報としてアルファチャンネルを用いた例
オリジナル画像
左の画像にRINgをかけたもの
(畳み込みの演算カーネルは円状)

 今回のRINgプラグインは光が広がる様子を保存した「畳み込みの演算カーネル」を基に画像にフィルタをかけるだけなので、使う演算カーネルの形状・様子によって色んなフィルタに早変わりする。

 例えば、デフォルトでつけてある三日月型の"Moon"カーネルを使えば、色んな灯りが三日月型に光る景色に早変わりする。もし、星空の写真に"Moon"カーネルでRINgプラグインをかけたら、いきなり全ての星が三日月に早変わりだ。また、"Smile"カーネルであれば、いきなり光が大小様々な「笑顔」に早変わりする。そんな風にして、色んな画像ファイルを演算カーネルにして見ると、色んな景色が見えてくるはずだ。例えば、「星はなぜ星型に見えるのか」のグループが作成した「星型シミュレーションソフトウェア」の出力結果を演算カーネルにすれば、目の前の景色が星空の向こうの景色に早変わりするだろう。そしてまた、水で満たしたコップの向こうに浮かぶ光の画像を使えば、RINgはデジカメで撮った色々な写真を水槽の向こうの景色であるかのように描き直したりするかもしれないし、あるいはまたまるで瞳に涙を浮かべながら景色を眺めてみたかのように描き直したりするかもしれない。

2003-11-19[n年前へ]

公知資料探し 

 桜雷さんの特許申請の話です。

対数変換による画像処理技術が既知であることを示す資料を過去のSIGGRAPH論文から探したのですがあいにくと1996年からのPROCEEDINGSしかなく、SIGGRAPH97 Proceedings p.369-378が一番近そうな資料でした。
 ありがとうございます。後ほどメール致しますが、こちらにも参考のため挙げておきます。
 また、この論文に関してはRecovering High Dynamic Range Radiance Maps from Photographsのようなもので、論文内で「非線形変換→畳み込み→逆変換によってリアルなモーションブラーが得られる」といった例(Fig.9)も挙げられている、との情報も頂きました。ありがとうございます。

2003-11-20[n年前へ]

続々・桜雷さんの特許申請の話 - 二通目のメール - 

 人に書くメールというものはやはり丁寧に書きたいので、桜雷さんへの返事は日曜日にでも書くつもりですが、先に今朝届いた二通目のメールで述べられていた内容の概略を紹介しておきます。

(2003.11.22追記)
「私信として送ったメールなので、公開するのは止めて欲しい」と桜雷さんからの要望を頂きました。とりあえず、できるだけ文脈を保持しつつメールの元の文章は削除しておこうと思います。なお、削除作業以前の以前の文章も記録として別途保存してあります。

二通目のメールの概略現在、該当する特許申請については申請中であるため、公開停止を求める通知を取り消す。もし特許の申請が通れば、申請日までさかのぼり問題となる。別のアルゴリズムによる同機能のソフトを開発する場合には問題はない。

 とりあえず、特許の仕組みに対する認識が前回のメールからは変わられたようで何よりです。ところで、以前に質問メールを頂いたときに、
> hirax.netに「ご理解いただけましたら、私が同じ原理で特許を出している旨を> 掲示していただけたらと思います」ということを目立つように書いた場合には、> 異議申し立てをする会社や人が現れる可能性が高くなると思います。> なので、それは必ずしも桜雷さんに対して良い方向に向かうとは限らない> です。これは桜雷さんの好きな選択を尊重したいと思います。
と書いて、桜雷さんにとって望ましい選択を尊重したいと考えました。そして、「面倒なことになるのは避けたい」「そのままにしておいて欲しい」という希望に添いたいと考えました。

 それに加えて、「広くソフトが人に渡って安価で標準的に使えるようにしたい」「個人で作っている物には文句をつけない」という言葉があったことで、「桜雷さんの好きな選択を尊重したい」とお返事を書きました。請求項が狭いので特にその特許が何かの妨げにはならない、と判断したこともあります。

 とはいえ、前回のメールのような対応はあまり歓迎できるものではないので、とりあえず今回は公知資料を集めて特許庁への資料提供を行うつもりでいます。そんなわけで、公知資料提供を引き続き募集しております。また、あまりこの手の話を書くのもつまらないことですから、この記事を書くのもこれで終了したいと思っています。もちろん経過の報告は逐次させて頂きますが、「IrisFilterの特許とは? 」なんていうスレッドもできているようですし、この場では何か他のもっと楽しい話題でも書いていきたいと思います。

 個人的には、桜雷さんが今回のような対応をせずにこれからもただ良い製品を作っていかれることを期待しています。

(2003.11.21補足) 下記のメールを桜雷さんに返事として出させて頂いたことを報告しておきます。
(前記の理由により、なるべく文脈を保持しつつ桜雷さんからのメールの元文章は削除してあります)
 お久しぶりです。平林@hirax.netです。お問い合わせを頂いた件からまず先に回答させて頂きます。また、以前メールを頂いたときの記録が桜雷さんの手元に残っていないということなので、以前の返事と重なる部分はそのメールをなるべく引用しながらお答えさせて頂きます。> http://www.hirax.net/dekirukana5/bokeboke1/index.html> http://www.hirax.net/dekirukana6/rin/index.html> > は当方の出願中の特許に重なるもだと思います。> 日本とアメリカで申請中(アメリカは現在審査中)です。> アメリカの方は日本の申請のものを基本に、範囲を広げて申請しています。(中略)> これらの特許に抵触しないと確信された上でソフトの公開をされているのでし> ょうか、お考えをお聞かせください。 JP(日本特許)に関しては請求項に規定されているような対数変換の式は使っておらず、(仮に特許が成立したとしても)特許には抵触しないように配慮してあります。そのため、> 当方としましては、これにあたるものだと判断していますので、という判断の具体的な理由を参考までにお聞かせ頂ければ幸いです。> また、これらの記事を見て私の出願を知らずにこのアルゴリズムでソフトを作> っている人もでてきていますので、もしアルゴリズムに関する記事を公開され> る場合には、当方が特許を申請中であることを明記してください。 桜雷さんが特許を申請中であるということは、以前桜雷さんが「同じ原理で特許を出している旨を掲示して欲しい」という同様の要望を書かれてきた際に、その後「よくページを読むと特許の記述も書いてあった」とご自身でご確認されているようにこの記事を書いた時点から記載しておりますので、この点については再度よく確認頂きたいと思います。 さて、ここから先は以前メールでお知らせした事項と重なる部分も多いですが、桜雷さんの参考にもなると思いますので、若干書かせて頂きます。 最初に桜雷さんから頂いたメールは「画像処理ソフトで、自然対数を使う数式を使ってピンボケを作り出すソフトやアルゴリズムが存在したか教えて欲しい」というという内容のお問い合わせでした。それに対して、>  さて、特開2001−216513をざっと眺めてみました。> 処理の流れは、画像データに対して、>1.コンボリューションを行う(ただし限られたコンボリューションカーネルを用いる)> 2.その際特許内で示された非線形変換を行う> という感じでしょうか。>  特許という観点で見ると、> 1、2ともに公知の技術であって、その組み合わせ自体もおそらく画像処理関連の> 学会誌・レポートなどを探れば、通常の写真・レンズの研究の一環で既に発表されて> いそうなので、公知資料があるのではないか、と思います。> > ただし、公開された特許に対して、審査が通り、また、どこからか異議申し立て>が無ければ、特許は通るかもしれません。> > 計算上は上記、1,2の組み合わせのソフトは結構ありそうですが、特許に書いてある> 式ずばりそのものを使ったものは無いかもしれません。>  ただし、それは同時に特許の請求範囲が狭い(請求項に書かれている式に限定されて> いるので)ということも意味します。この特許の式を使わなければ良いわけで、特許が> 成立しても特許から逃げやすいかもしれません。と簡単に書きました。公知資料の方は例えば特開平8-241407 「画像処理システムの特許」SIGGRAPH97 Recovering High Dynamic Range Radience Maps from Photographなどの一例を挙げるに留めますが、このような画像をぼんやりさせる効果のために「非線形ガンマ変換→畳み込み→ガンマ逆変換」を行ったり、あるいは種々のボケ画像形成のために「フィルム特性を再現する変換カーブ→畳み込み→フィルム特性逆変換カーブ」を行う例を挙げている公知資料が見つかります。そのため、特許の新規性という点において、このような公知資料などと比較した上で、特許審査を通過するかどうかは若干の疑問があります。 また、上に書いたようにJPの請求項はそもそも規定範囲が非常に狭く特許回避は容易で、現実には他社技術の抑止力にはなりえないと思います。当然、請求項からすると「アルゴリズム」というような上位概念による抽象化は欠けており、そもそもアルゴリズムを規定する特許にはなりえていないように思えます。 この感想に対しては、前回桜雷さんも「請求項に式を書いてしまっているのは気になっている」「日本のは細かすぎたかもしれない」というような感想を書かれていましたから、同じご理解はされていたことと思います。また、同様の機能を有するソフトの作者の方々もおそらく「請求項に規定されている式は使っていない」と答える方が多いだろう、と思います。それだけ、規定範囲が非常に狭い特許申請になってしまっています。 また、USPの方ももし仮に通過したにせよ、現在のClaimであれば特許回避は非常に容易で、具体的な話は省きますが、他の類似のソフトも現状ですらほとんどがそのClaimを回避しているだろう、と考えます。 そのように、以前お話を伺ったときには、特許審査通過の可能性およびその実抑止力には疑問を感じましたが、とりあえずの感想としては>  ところで、私自身は特許はあまり好きではないです。といっても、「個人としては」ですけど。> それに、特許を申請する桜雷さんの考えも良く理解できます。> >  で、例えば実はワタシの手元にはIrisFilterと同様の機能を持つ自作Photoshop用のプラグインが> あります。こちらは従来からあるアルゴリズム組み合わせたものですが、私がどうしても> 欲しかった16bitモード対応、距離チャンネル対応(最新のバージョンではIrisFilterでも> 対応されたようですが)、そしてAdobeの通常のプラグインインターフェース、という> ものを備えたものです。あくまで、趣味で作成しているものですが自分で好きなようにできるので> 自分用にはなかなか良いです。で、こうした個人作成のソフトはインターネットに満ちあふれています。> そんな個人で作成してインターネットにあふれているソフトがさまざまな特許などで、出しづらい> 雰囲気を近年ひしひしと感じます。そんな雰囲気がそれほど好きでないのもまた確かです。 > それで、少し知りたいのですが、私は自分で作ったプラグインなどもいつもそうしているように>何かの話のネタを作って、ソフト自体はフリーで配布すると思います。で、私以外にも>自分で画像処理やプログラミングをしている人は多いので、そんなこともあるだろう、と>思いますが、そういうときに桜雷さんはどうされるつもりでしょうか?>  とはいえ、繰り返し書きますが、IrisFilterを拝見して、非常に面白く要望の高そうな> ソフトだなぁ、うれしく思いました。これからも、楽しみにさせて頂きます。 とメールで書かせて頂きました。それに対して桜雷さんの「特許を出したのは自分の研究が報われる部分が欲しいから」「自分や一部企業が独占して人が使えないような状態は望まない」「広く人に渡って安価で標準的に使えるように活動していきたい」「個人で作っている物に文句をつけても仕方ない」というような内容のお答えを頂き、「自分や一部企業が独占して人が使えないような状態は望んでいない」というお言葉と「いちいち個人で作っている物に文句をつけても仕方ない」というご判断を聞かせて頂き、納得しておりました。ですから、hirax.netで桜雷さんの特許申請についてさらに詳しく言及するかなどについては> > 目立つように書いた場合には、異議申し立てをする会社や人が現れる可能性が> > 高くなると思います。なので、それは必ずしも桜雷さんに対して良い方向に向かう> > とは限らないです。これは桜雷さんの好きな選択を尊重したいと思います。と、桜雷さんの希望を尊重することにし、「ややこしくなるのは避けたいのでそのままにしておいてほしい」という桜雷さんの判断をもとに、それ以降申請特許件には触れず、またなんのアクションもとらずにいました。 そういう桜雷さんからのご相談に乗っていた経緯で私自身は納得していたため、前回のメールのような> ソフトの公開を停止、回収されない場合には、ライセンス料の請求や法的な措置に出る考え> でおります。という対応には実に困惑を感じざるをえません。このようなことをされる予定であるならば、そもそも指摘の請求項には抵触していないので無関係である特許申請だと考えてはおりますが、そのような行為が私自身に及ぶことを防ぐために、特許庁への第三者による資料提供の制度に基づいて、公知資料の特許庁へ情報提供を行わせて頂こうと考えています。本当に、以前の桜雷さんのメールで書かれていた内容と今回の対応の違いは誠に残念でなりません。 また、多くの技術者は自らの特許申請・他社技術調査及び特許回避・あるいは異議申し立てなどを日常的に行っており、特許にいやでも慣れ親しんでいることが多い、ということはここに書き加えておきたいと思います。ですから、おそらく技術者以外の方が想像するよりも一般的に技術者は他者の特許を意識・尊重していることが多い、ということはぜひ理解しておいて頂きたいと思います。 最後になりますが、桜雷さんの特許申請というものは、後から他社から訴えられることを防止し、自分の技術の使用を保証するために、単に公開目的で使用するには有効であると思いますので、そのように活用されることを望んでいます。また、個人的には桜雷さんが良い製品をこれからも提供されていくことを願っております。 それでは、長文になりましたが、失礼させて頂ます。jun hirabayashi jun@hirax.net



■Powered by yagm.net