hirax.net::Keywords::「ライブラリ」のブログ

■WireIt　

　Yahoo!PipesのようなJacascript GUIライブラリ WireIt

■光スペクトル操作用のMathematicaライブラリ　

以前、Mathematicaの演習用に作った「スペクトル操作用Mathematicaライブラリ」を少し直したので、ここ（”ColorLib_amature.nb”に置いておきます。以前作ったものと同じく、スペクトル・データをリストのような離散データではなくて、関数として（純関数＝無名関数として、あるいは、明示的な関数として）取り扱うという点が特徴だと思います。「（せっかくMathematicaで解くのですから）解析的に解く」「使用者には離散化・数値計算など、面倒くさい汚い部分は見せない・見たくない」という方針で作ったものです。

以前のものからの変更点としては、"spectorPlot"や"labPlot""labColorPlot"など、関数名のMathematicaの命名規則に合わせた変更、加法混色・減法混色用関数の追加・グラフ表示関数の追加・バグ修正といったところです。

　最初のラフスケッチが、絵画の原理を自分なりにおさらいするためのものだったので、濃度変調・面積変調などを扱おうとする場合には、比較的簡単に・気持ち良く作業ができると思います。たとえば、下記のようなコードを書けば、D65光源のもとで、赤紫色の絵具を重ね塗りしていったときの色の具合を CIE Lab 空間で眺めたりすることができます。

labPlot[
　Map[lab,
　　Table[transmissionSpector[D65,
magentaFilter, d],{d,0,10.0,0.1}]
]
];

　また、白色光照射時に黄色い絵具を塗り拡げる面積を増やしていった場合の反射光スペクトル変化をアニメーションとして作成・グラフ表示するコードはこんな感じです。"addtiveMixtureSpector"は加法混色用の関数で、"transmissionSpector"は減法混色用の関数です。お遊びソフトですが、色々遊ぶこともできるかもしれません。

Map[spectorPlot,
Table[
addtiveMixtureSpector[
{whiteLight,
transmissionSpector[whiteLight, yellowFilter, 1]},
{1-r, r} ],{r,0,1,0.1}]];

　コードを書く際に、Mahematicaで数式と文字列をシームレスに取り扱うことができたなら、もっと簡単に関数が書けるのにとも感じました。しかし、そういった感覚になるときは、たいていの場合「その道具の使い方・その道具を扱うプログラミングスタイルが間違っている」ことが多いものです。というわけで、Mathematicaプログラミングをまた勉強しなおしてみよう、と思ったのです。

■「スペクトル操作Mathematicaライブラリ」で動画を作る　

　光スペクトル操作用のMathematicaライブラリで、スペクトル変化の動画を作ると、こんな感じになります。Map　も　spectorPlot　も　Table も addtiveMixtureSpector　も whiteLight も cyanFilter も・・・どれも「関数」です。addtiveMixtureSpector　や whiteLight や cyanFilter は「関数を返す関数」で、Map などは関数を引数にとる関数です。Mathematica でコードを書いていると、なぜか自然に関数を重ね合わせていくような書き方が気持良くなってきます。

Map[spectorPlot,
　Table[
　　addtiveMixtureSpector[
　　　{whiteLight,
　　　transmissionSpector[whiteLight,
　　　cyanFilter, 1.0]}, {1-r,r}]
　,{r,0,3,0.05}]]

　それで、今この瞬間の悩みはMathematicaで"spectorFitting[targetSpector_,usingSpectrum]"というような関数をどうやって書くか、ということです。targetSpector は、任意のスペクトルを表現する関数で、usingSpectrum は「スペクトルを表す関数群」で要素数は任意のリストです。usingSpectrumを使いtargetSpectorをどのように表現するかを、最小二乗近似で最適解をNMinimize で解くというのが、そんな関数を作るときの定番の手順なのだろうと思います。つまり、方程式と制約条件を動的に作成し、それをNMinimize で解いた結果を返す、という具合です。

　さて、この　spectorFitting という関数はどう簡単に書くことができるものでしょうか。Mathematicaは変数名と文字列を明確に区別する割に、見た目ではまったくその違いがわからないのが面白いところ（同時に苦労するところ）かも、と思ったりしたのです。

■「肌」と「昼の日差し」のスペクトル　

　夏の日差しを実感するようになりました。肌は日焼けして赤黒くなり、そんな肌はピリピリと痛く、熱っぽさすら感じます。そんな、夏の明るい景色を眺めていると、なぜか楽しくなります。

　痛いけれど日焼けする夏の日差しが気持良く感じる人もいる一方で、日焼けする夏を嫌う人も多いと思います。特に日焼けしたくない女性にとっては、夏は面倒でとても嫌な季節だったりするのかもしれません。

…と考えているうちに、ふと、夏の日差しを浴びる「肌の色」を眺めてみたくなったのです。そこで、２週間ほど前に作った「光スペクトル操作用のMathematicaライブラリ」にいくつかの色関数（スペクトル吸収関数）を追加してみました（サーバからダウンロードできるライブラリ更新は数日後になります）。追加したスペクトル吸収関数は、「血液」「カロチン」「メラニン」…といったもので、皮膚内部にある物質の吸収スペクトルを表現するための（単純化した）スペクトル関数を実装してみました。

　そういった色関数を組み合わせると、いろいろな「肌色」を眺めることができるます。たとえば、右上の図は、(どの波長も均等に含んでいるような)白色光源で照らした時に血液の反射スペクトルがどう見えるかを試しに計算してみたものです。

spectorPlot[transmissionSpector[
whiteLight, bloodColorFilter, 0.5]
]];

　ところで、こんな「色関数」を作り、適当で大雑把な「肌」を作って眺めてみました。すると、色温度6500ケルビンの標準光源、すなわち自然な昼光光源であるD65で、肌色を形作るメラニンや血液を照らしてみると、意外なほど「反射スペクトル」が平らになるものだ、と気づかされました。

　つまり、昼の日差しのスペクトルのうち、スペクトル強度が強い短波長領域では、メラニンや血液などの色吸収率が高く、その一方、「昼光」のスペクトル強度が低下する長波長域では、メラニンや血液などの色吸収率が低く、それらの結果として反射スペクトルが”結構”均等になるのだなぁ、と感じたのです。たとえば、右のスペクトルグラフが、昼光＝D65光源で皮膚を照らした時の反射スペクトルの例になります（ちなみに、右下のグラフがD65光源のスペクトルです）。

　それは、単に長波長領域の光は皮膚中で吸収されることが少なく、短波長の光が吸収される、というだけのことでしょうし、さらには、人によってメラニンの分布量・形状が異なり、反射スペクトルは全然違うわけで、こんな結果も一般的なものでは全くありません。

　けれど、「昼光の逆関数のような、まるで、強い日差しから身を守るかのように最適化されたような皮膚の吸収スペクトル」を適当に作ったライブラリ関数が生成したのを眺めたとき、とても不思議なくらい新鮮さ・意外な面白さを感じたのです。

■Simulinkで”日焼け対策”を最適化 Vol.1 [はじめに 編]　

　先日、Mathematicaで肌の色や日光の色スペクトルを表現するためのライブラリを作り、いくつか計算をしてみました。また、昨日は、「日焼けに影響を与える日照時間」の変化・「気温の変化」「化粧品の商品切り替え時期」「日焼け対策を行う時期」について考えてみました。

　そんなことを考え出すと、究極の”日焼け対策”・至高の”日焼け対策”はどういう風にすれば良いだろうか、という技術的な興味が湧いてきます。もちろん、外に一切出ない・顔には紫外線反射膜をコーティングする、といったような対策もあるわけですが、そんな対策をしても「そんな毎日でいいのか？」という疑問を感じるに違いありません。やはり、色々な観点を含めた上で、それらの観点を少しづつ満たすような”日焼け対策の最適化”を考えなければならないように思われます。

　そこで、Simulinkを使って、（動的なシステムのモデル化・制御システム構築・プロトタイピングを簡単に行うことができる）MATLAB社のSimulinkで”日焼け対策”を最適化に挑戦してみたくなりました。そこで、今日はまず[はじめに]ということで、平均日照時間と平均気温をSimulinkでグラフ表示してみました。

とりあえず、下の微分方程式のように平均気温(TEMP)の変化は平均日照時間(SUN)に比例するとおくと、

d TEMP /dt = SUN

平均気温は平均日照時間を積分したもの、ということになります。そんな関係をSimulinkでモデル化し(数値はまだ合わせていません)、グラフ表示してみたのが下の図です。気温が日照時間に対する「位相遅れ」を持っていることがわかります。

　・・・と、ここまでは当たり前の結果ですが、こんな感じで「日焼け対策の最適制御」について色々考えていこうと思います。