前回の時点における問題点は以下の3つだった。

1. エッジに鉛筆で書いたような線が見える
2. 平らな面における色の変化がなだらかじゃない（マッハバンドが見える）
3. ベイク処理に時間がかかる（これについては現時点でまだ何も対応してない）

1については、テクスチャの”島”をその外周部の色で外の領域に広げる処理（テクスチャ空間でのポストプロセス）を実装して解決。

2については、トーンマッピングの実装をもっとちゃんとしたものに変更して解決。
実装にあたっては以下のページで紹介されてる方法を参考にし、とりあえずCPUで処理するよう実装した。
t-pot『Tone mapping』

ということでその結果。
総フォトン10万、推定に利用したフォトン500個/テクセル

だいぶ綺麗になったけど、イラストっぽさはそのまんま。
リアルとは程遠い。
まぁこれはこれで味があるというか、リアルの一歩手前で不気味の谷に入ってしまうよりはマシに見えるのかもなとは思ったけど、そういう絵作りを志向するにしても、偶然に頼ってたらダメなわけで。
それに、実装中はリアル志向でやらないと結果を見て実装がおかしいかどうかが判断しづらいわけで。

そこでなんでイラストっぽいのか考えてみた。

「イラストっぽく見える」をもう少し詳しく言うと、「キャンバス（色変化がない一定の色）の上に色を重ねてるように見える」とも言えると思う。
実際に、陰影無しの元テクスチャの色 x 0.5 + 放射輝度推定の結果をトーンマッピングしたモノ x 0.5 という超テキトーな実装になってたので多分それがイラストっぽさの原因の一つだろう。

あと、色の伝搬のようすが強調（デフォルメ）されてるように見えるのも原因のひとつだと思う。
これに関してはフォトントレース処理の実装を見直したら、拡散反射率と吸収率を逆に扱ってたことに気づいた。
初歩的なミス。
あと、元のテクスチャから読み込んだRGBデータをそのまま拡散反射率の計算やフォトンのエネルギーとして扱ってた、つまり輝度とRGBをごっちゃにして扱ってたので、内部では全て輝度で扱って最終的にRGBにするようにしてみた。

ということで上記の問題に対処した結果は以下のとおり。
総フォトン100万、推定に利用したフォトン500個/テクセル

見栄え的には良くなったのか悪くなったのかなんとも分からないけど、本家コーネルボックスの例と比べるとデータ的には確実に近づいたと思う。

ちなみに、光源が明るくなってるけどこれについては、フォトンをトレースする前、フォトンを光源にランダムに配置するときに、その5%ぐらいのフォトンについてその向きを逆にするという、これまたテキトーな方法でそれっぽく見せてる。
5%ぐらいの光がそのカバーで拡散してしまうライト、という事にしとけば物理的にも全く意味が無いわけじゃないと思う。

本家の結果に近づいたとは言え、おかしなところはまだたくさんある。
例えばエッジやコーナー付近が暗くなりすぎてる。
これは前回問題になったテクスチャの継ぎ目が原因ではなく、フォトン密度推定の誤差だろう。
ある地点の色は、その地点の局所的な表面積（円の面積）とそこに含まれるフォトンの数から推定するんだけど、エッジやコーナー付近だと局所的な円の片側だけにフォトンが存在しがちになる。
円の半分しか有効じゃないのに、円全体として密度を求めてしまうので、フォトンが少なめ = 暗い として処理されてしまう。

あと、色の伝搬具合も本家と違っている。
現状では、元のテクスチャの色（RGB）を輝度スペクトルに変換して、その各スペクトルの大きさの平均に拡散反射率を比例させるという、物理的にあまり意味がないやりかたで計算してるせいだと思う。
このあたりを物理的にやるにはどうしたらいいんだろうか。
本家のサイトを見たら波長ごとの拡散反射率のデータが細かくのってるけど、波長で反射率が変わるとなると面倒だなぁ。
コーネルボックスのシーンでしか使えないとしても、近似する計算式が割り出せたらいいんだが。

色合いに関しては、トーンマッピングの処理内容に違いがあるせいかもしれない。
そのあたりもしらべなければ。

あと、フォトンマッピングだけで直接照明も間接照明も表現するのは収束するまでのデータ量や処理時間的にキビシイ気がする。
やはり直接照明はレイトレーシングで計算して合成すべきかもしれない。

だんだん問題が難しくなってきたから、更新頻度が下がるかもなぁ。