基準設計の物理構成 (Baseline Physical Configuration)

概要 (Overview)

Step 8（基準設計のキャリブレーション）で対象とする MiniTIAS 実機の物理構成を定義する． 本ドキュメントは実機写真（REFERENCE/）と Fusion 360 設計データから読み取った構成を、シミュレーション側でどう表現するかの 認識合わせ を残すためのものである．

仕様確定前の暫定値（材料パラメータ・LED 強度等）はキャリブレーション反復で更新する．

実体は configs/scene_baseline.yaml．

座標系 (Coordinate System)

• 単位: mm（YAML 内）．シミュレータには m に変換して渡す．
• 原点: STL モデル（Fusion 360 エクスポート）の座標系を踏襲．
• 主要部品の Z 座標（中心）:
  • 評価板（照明ムラ補正ボード）: Z=+4（厚み Z=-4.5〜+12.5）
  • LED 基板カバー: Z=-65.3
  • スマホ（SH-02M）: Z=-154.4

評価板（照明ムラ補正ボード）

構造

評価対象面

評価対象は内側（平坦面、-Z 法線面）の照度分布．照明ムラ評価とは「この面に届く光が空間的に均一かどうか」を測ること．

LED（光源）

物理仕様

実機搭載 LED は LED Paradise「Ra98 SunLightLED 2835 チップ LED 4000K」（型番 LP-2835D90VW） に確定（商品ページ）．以下は同商品ページから取得した規格値で、駆動条件は 規格通り 60 mA フル駆動 を前提とする．

※ Ra98 は太陽光のスペクトルに広帯域で近づけた高 CRI 品．本シミュは現状 RGB variant・無彩色等価で運用しており luma 指標には影響しないが、将来のスペクトル化（spectral variant）時に再評価する．

規格値に基づく radiance の独立推定

scene_baseline.yaml の radiance = 2807.247 W/(m²·sr) は実測 PNG mean=146.71 への線形アンカーで決まった校正値であり、規格値からの導出ではない．LED 物性が確定したので、規格値だけから radiance を独立に計算して校正値と並べる：

1.38× 差の解釈

サニティチェックとして電気→光のウォールプラグ効率を計算すると Φe / P = 0.0625 / 0.186 ≈ 33.6%（実用 LED として妥当範囲、Cree 等の高効率品で 40%・廉価品で 25–30%）．規格→radiance の換算は物理的に整合しており、桁・係数とも合っている．

校正値が規格推定より 1.38× 高い差分は、間接照明設計（LED は評価板から見て反対側を向いており、評価板輝度は 反射率の累積積を経由した経路でしか決まらない、後述）の下で LED 単体側ではなく反射率累積側で説明可能：

• 暫定 R = 0.85 で integrating sphere 近似 1/(1−R) = 6.67
• R = 0.89 にすると 1/(1−0.89) = 9.09 で 比 1.36×（観測差 1.38× と一致）
• マット白プラの実用反射率上限は ~0.92（反射率スイープ参照）であり、R ≈ 0.89 は 物理範囲内

→ 校正値 2807 と規格推定 2030 の差は反射率 0.85→0.89 で説明可能．現状の暫定 0.85 はやや低めに見積もっていた可能性がある．

形状指標への影響（重要）

LED の絶対 radiance は 線形ゲインなので CoV / 勾配 / C/P など無次元の形状指標には不変．したがって規格値 2030 への置換は形状指標残差（実測との 1.6–1.9× 差）を解消しない．本ドキュメントの「radiance を規格推定値で記録する」と「形状指標の残差を詰める」は 独立な作業であり、前者は物理妥当性の担保・後者は ISP モデル化（既知差分 #6 LSC）が本筋．

モデル化（光の広がり方）

• Mitsuba の AreaLight (rectangle) として表現
• 発光面の 片面のみ から放射する（direction ベクトルが示す向き側．裏面は完全に発光しない）
• 放射分布は Lambertian（法線方向で最大，cos(θ) で減衰）
  • データシート記載は配光角 120°（半値全幅 ±60°）のみ．これを満たす配光のうち最も標準的なのが Lambertian（cos(60°) = 0.5）であり、現実装はこれと数学的に整合
  • ただし：実 SMD 2835 はパッケージ内の蛍光体カップ・封止樹脂ドームで配光が純粋な cos^n 形にならないことが多く、典型的には Lambertian よりやや前方凸．LED Paradise は詳細 IES プロファイルを公開していないため厳密検証は不可
  • 仮に実 LED が前方凸であれば中央/周辺比が上がる方向＝形状指標残差を悪化させるが、これは ISP LSC（既知差分 #6）の周辺持ち上げと方向が逆であり、現状の「Lambertian + LSC なし」は近似的に「実 LED 前方凸 + 実機 LSC あり」と打ち消し合っている可能性がある．配光精緻化は LSC モデル化とセットで再評価する
• 各 LED の direction は z 軸マイナス方向 (0, 0, -1) で全 18 個共通．意図的な間接照明設計：LED 直接光は評価板に届かず、白筐体内壁の多重反射経由でのみ評価板を照らす．これにより評価板輝度は LED radiance と反射率累積の積で決まり、絶対値（mean）と相対分布（CoV/勾配/C/P）の感度は別物になる
• radiance は現状 2807.247 W/(m²·sr)（実測 mean=146.71 への線形アンカー校正値）．規格値からの独立推定は ≈ 2030 W/(m²·sr)（前項参照）．差 1.38× は反射率 0.85→0.89 で説明可能で物理範囲内
  • 全光束への換算: Φ [W] = radiance × area × π（Lambertian 半球積分）
  • 1 LED あたりの面積: 2.8 × 3.5 = 9.8 mm² = 9.8e-6 m²

配置

実機の LED 基板は 前側のでっぱりの直角部分 に取り付けられている．3 基板を Z 軸まわりに ±90° 回転で配置：

各基板上の LED 6 個は基板の長手方向に約 8.7 mm 間隔で等間隔配置．総数 18 個．

※ 左右基板の中心座標は STL の下基板（LED基板カバー.stl、bbox 中心 (0, -70.2, -65.3)）を基準に Z 軸まわり ±90° 回転で算出した推定値．Fusion 360 設計の実位置と微小なズレがある可能性あり．

カメラ（センサ）

評価板の 内側（平坦面）の照度マップを 2D 画像として直接取得 するため、orthographic（平行投影）センサを使う．

カメラ位置が評価板に近すぎる（Z=-10 等）と Mitsuba の orthographic の near_clip 内に入って何も映らないので注意．

画像 ↔ 物理 の向き（検証済み）

orthographic 投影の向きは scene/sensors.py の look_at(position, target, up) @ scale(sx, sy, 1) で一意に決まる．3D ビューア投影機能（visualize/projection.py）の実装時に output/baseline/luminance.npy で実測検証した結果、baseline センサ設定での対応は：

• clip_x = world_x / sx_m, clip_y = world_y / sy_m、画像行 row = (1 - clip_y) / 2 · H
• 画像右 = 物理 X+（画像左 col=0 ↔ clip_x=−1 ↔ 物理 X−）
• 画像上 = 物理 Y+（画像下 row>H/2 ↔ clip_y<0 ↔ 物理 Y−）．LED が Y− 側（下基板等）にあるため画像下部が明るい（実測 row 平均 156 vs 上部 123）と整合

注意: セッション中に「画像左=物理 X+」と表現されたことがあるが X 軸が逆（正しくは画像右=X+）．権威ある定義は sensors.py（look_at@scale）であり、projection.py の投影テストで担保されている．※ これはシミュ orthographic カメラの向き．Step 8 の実測 PNG ROI 物理対応で適用した「X 反転+Y 反転」は別カメラ（スマホ実機）の話で混同しないこと．

レンダリング設定（多重反射の扱い）

Mitsuba 3 の path tracer（モンテカルロ光線追跡）を使用し、多重反射（インターリフレクション）まで含めて計算する．

多重反射の意味

LED 光が評価板に届く経路は以下のすべてが計算される：

1. 直接光: LED → 評価板（評価板の表面に直接当たる光）
2. 1 回反射: LED → 内壁 → 評価板
3. 2 回反射: LED → 内壁 → 内壁 → 評価板
4. ...
5. max_depth (8) 回反射まで

MiniTIAS は 白い筐体内壁の多重反射で照明を均一化 する設計のため、多重反射の正確な計算が CoV 値の再現に必須．

制限

• visualize/baker.py は mode="direct"（直接照度のみ・後方互換）に加え mode="path"（scalar_rgb・完全シーン・コサイン重点 hemisphere MC による多重反射込み per-face 照度）を実装済み．3D ビューア（sm-visualize）の既定は全メッシュ path ベイク統一着色で、評価板も多重反射込みで色付く．ただし per-face ベイクはメッシュ境界の継ぎ目・粗メッシュのブロック感・低 samples の MC ノイズ・scalar_rgb の遅さ（高 samples は非現実的）という方式特性があり、評価面の精細な照度マップ評価は引き続き 2D の sm-render/sm-evaluate（path tracer）で行う（こちらが校正済みの定量結果）．シーム解消には全メッシュ UV 統合のシームレスライトマップ基盤が必要（将来の別タスク）．
• path ベイクの max_depth は --bake-max-depth（既定 16）で render 設定（max_depth: 8）から独立設定する．本ドキュメント記載の「depth=8 は均一化に効く後段多重反射を取りこぼし空間差を過大評価」の知見に基づき、3D ベイクは depth≥12 で内壁照度を物理どおり均一に近づける（2D の sm-render は校正都合で現状 8 のまま、独立）．
• 3D ビューアは既定で**幾何カリング（--cull-outward）**＝法線がシーン外を向く「外向き面」を非描画にする．筐体の外向き面は空洞外＝入射照度 ≈0 で、これを半透明描画すると暗殻の濁り・内壁との見かけ段差を生む（調査で判明：隣接内壁の照度自体は同一手法ベイクで ~1〜2 倍以内とほぼ均一．段差の主因は外向き ≈0 面の混在）．カリングで内向き面のみ描画し、共有 clim も可視内向き面に密着させる．
• max_depth を超える反射は無視される．エネルギー的には 0.85^8 ≈ 27% 減衰で小さいが、キャリブ実測では無視できない：同一条件で depth=8→12 にすると勾配が linear 空間で 24.65→22.08（−2.6pt）、sRGB 空間で 12.57→11.16（−1.4pt）下がった．8 回打ち切りはまさに均一化に効く後段反射を取りこぼし、勾配を系統的に過大評価する．キャリブ用途では depth≥12 を使うこと．

筐体（材料）

実機の筐体構造物（前側 / 後側 / LED 基板カバー / 評価板）は すべて同じ 3D プリンタ白素材（PLA / PETG / ABS の白フィラメント）で造形されている．スマホホルダのみ別素材．多重反射で照明を均一化する設計．

LED 基板カバーの取り扱いについて

当初 thindielectric（半透明 PMMA）でディフューザーとしてモデル化していたが、実機は 3D プリンタ白素材（不透明）であることが判明したため diffuse 0.85 に変更した．これにより：

• LED 光は基板カバーを 透過しない．Lambertian の発光面（AreaLight）から直接シーン空間に放出される
• 基板カバーの表面は 白プラとして拡散反射 に寄与し、多重反射の経路の一部になる
• 「半透明ディフューザーで散乱しない」問題は解消（そもそも実機にディフューザーは存在しなかった）

キャリブレーション目標（実測値）

PLAN_02 より：

キャリブレーション経過（spp 校正と診断）

spp 128 → 1024 の数値比較（2026-05-18）

代表実測 1 枚（MiniTIAS_20260408_144434、ROI 物理対応済み）に対するシミュ結果：

診断結論：ノイズ要因 vs 物理モデル要因の切り分け

spp を 8 倍にして判明した切り分け：

• モンテカルロノイズ由来だった成分：max/min 比 11.6→4.3、std 35.8→27.9、CoV 0.236→0.183．極端な外れ値ピクセルが消えた．
• 物理モデル由来（spp 非依存）の成分：中心/周辺比 (1.330→1.328) と勾配 % (24.83→24.72) はほぼ不変．計算ノイズではなく構造的な空間勾配．

ノイズ分解（std² = 信号² + ノイズ²、ノイズ ∝ 1/√spp）で逆算：

• spp=1024 の残留ノイズ std ≈ 8.5、真の物理信号 std ≈ 26.5
• spp→∞（ノイズゼロ）でも CoV は ≈ 0.174 までしか下がらない（実測 0.0426 の約 4 倍）
• ⇒ spp をさらに上げても CoV は 0.183→0.174 程度で頭打ち．spp 増加は費用対効果なし．spp=1024 を基準設定として確定．

筐体内壁反射率スイープ（2026-05-18、spp=256・depth=12・raw float linear）

printer_white（5 メッシュ共有）の reflectance を 5 点振った結果（linear 空間）：

全指標が反射率と単調・線形に改善するが感度は低い（∂勾配/∂R ≈ −38 %/単位, linear）．実測到達には R≈1.2〜1.4 が必要で物理範囲外．反射率は弱い二次レバーで、これ単独では差を閉じられない．

手法訂正：linear vs sRGB の直接比較は不成立（OETF 順方向適用が必須）

それまでの「シミュ linear 放射輝度 vs 実測 PNG」の数値突合は交絡していた． CoV・勾配・中心/周辺比が「無次元だからスケール任意」で不変なのは 光量→画素値が線形のときだけ．実測 PNG は実機 ISP の sRGB ガンマ（OETF, IEC 61966-2-1） が掛かった非線形符号化値（Camera2 YUV_420_888 → BT.601 は定義上ガンマ済み R'G'B' 上の量）であり、シミュの linear とは別ドメイン．非線形変換下でこれら指標は不変でない．

実測データ提供側 README も明示していた：

シミュ側を線形放射輝度のまま比較する場合、勾配/CoV の絶対値は変わる（実測は ISP 補正込み）．…ガンマ補正解除しない．実測は ISP 適用後の sRGB 表示輝度で評価している．

レンズシェーディング補正が ON だと周辺光量低下の一部は ISP が補正している．「シミュの勾配が実測より大きい」ことが期待される（このため 6% は補正後の残存ムラ）．

訂正手順（overfitting なし）：標準 sRGB OETF を順方向適用し、露出は AE が制御する量＝実測 ROI mean (146.71) にアンカー（線形ゲインなので形状指標には自由度を持ち込まない；OETF が非線形なため「曲線上の動作点」を合わせる原理的アンカーとして必須）．データに合わせて回す係数はゼロ．無彩色シーン（LED・材料が RGB 等価）のため luminance への直接 OETF 適用はチャネル別適用後 luma と厳密一致．

OETF 適用後の比較（係数調整なし、uint8 量子化、clip 0%）：

確定基準で勾配 24.65→12.57（実測との差 18.6→6.5、約 65% が符号化ドメイン不一致だった）、CoV 0.183→0.089（差の 約 67%）．標準変換だけで見かけの「物理差」の約 2/3 が消えた．

luma vs luminance と演算順序（実測式との整合）

実測 (MiniTias-Evaluation) の「輝度値」は厳密には Rec.709 luma Y' ＝ ガンマ済み成分への加重和 Y' = 0.2126R' + 0.7152G' + 0.0722B'（README どおりガンマを戻さない＝luminance ではなく luma）．一方シミュ側は linear luminance に直接 OETF を当てている．OETF は非線形なので一般に演算順序が効く（Σwᵢ·f(xᵢ) ≠ f(Σwᵢ·xᵢ)）が、矛盾しない：

• Rec.709 重みは合計 1（0.2126+0.7152+0.0722 = 1.0000）．R=G=B=x の無彩色画素では「チャネル別 OETF→加重和」Σwᵢ·f(x)=f(x) も「加重和→OETF」f(x·Σwᵢ)=f(x) も厳密に一致．
• シミュのシーンは白色 LED（RGB 等価 radiance）＋無彩色拡散材で厳密に R=G=B．よって「luminance に直接 OETF」＝「実測の演算順（チャネル別 OETF→Rec.709 加重和）」と同値．
• 本質: OETF は不整合を作る操作でなく消す操作．OETF 前のシミュ＝linear 空間 luma、実測＝gamma 空間 luma で別ドメイン（＝真の不整合）．OETF 後は両者とも gamma 空間 luma で同種量になり、突合が初めて正当化される．

残る近似（いずれも二次、調整しないモデル誤差に含む）：

1. 無彩色等価が厳密なのはシミュ側のみ．実測白板画像は LED 分光・ISP ホワイトバランス・センサ応答で微小に非グレー（R'≈G'≈B' が完全でない分の luma vs luminance 差）．
2. カメラ実 OETF ≠ 厳密 sRGB（独自トーンマップ）．

実装時（productionization）の方針: sm-evaluate への正規実装では「linear RGB をチャネル別 OETF → その後 Rec.709 luma」の順（実測の演算順そのもの）にする．無彩色シミュでは数値同一だが、将来カラー LED・色付き材料を入れても破綻しない忠実実装になる．今回の apply_oetf.py は無彩色前提の同値ショートカット．

寄与順の訂正と残差

以前の「主因は ISP レンズシェーディング（83%）」は OETF を抜かした交絡判断で誤り．正しい寄与順：

OETF（最大・約 2/3）＞ ISP レンズシェーディング補正（中・残差の主因候補）＞ 筐体内壁反射率（小・弱いレバー）

OETF 適用後も最良点（R0.92,d12,sRGB）で勾配 9.72／CoV 0.081 と実測 6.10／0.043 の 1.6〜1.9 倍が残る．この残差は ISP レンズシェーディング補正＋スマホ独自トーンマップ＋モデル誤差．LSC は周辺を持ち上げる動径ゲインで勾配・C/P を下げる方向＝残差の符号と整合．残差はガンマ曲線いじりで消さず正直に残す（OETF は標準で固定、調整対象は LSC 側）．

次アクション

1. OETF 順方向適用を sm-evaluate へ正規実装（完了）．evaluation/oetf.py（標準 sRGB OETF + 露出ソルバ）＋ EvaluationConfig.oetf スキーマ＋ sm-evaluate 統合として実装済み．configs/eval_baseline.yaml で有効化、configs/eval_real.yaml は非適用（二重適用禁止）．後方互換（oetf 省略時は linear 評価）．参照実装 apply_oetf.py と数値一致をテストで担保．以降の全シミュ vs 実測比較は OETF 後ドメインで行う．設定仕様は SPEC_02 evaluation.oetf 参照．
2. 【次の本筋】残差に対し LSC 順方向モデルを当てる．overfitting 回避のため自由多項式ではなく物理動機づけ低自由度形（cos⁴ ベース等）に限定し取得パラメータ数を明記する．
3. 反射率は均一性からは一意に定まらない（物理範囲内で縮退）ため暫定 0.85 据え置き．実フィラメント分光反射率データ入手時に再校正．

想定どおりの挙動（追加対応不要）

以下は実機と一致する挙動として 意図的にそのままにしている 項目：

1. 評価板の楕円窓からの光漏れ: 楕円窓は撮影用開口で、均一性測定時にも何も塞がない．シミュ上で楕円窓から外部に光が逃げる挙動は実機と整合．
2. 筐体開口部（スマホ取付穴等）からの光漏れ: 同上．実機でも漏れる構造で、シミュも同じ．
3. 被写体（白板）は別途配置しない: 「補正ボード」= 評価板（照明ムラ補正ボード）そのものを指す．楕円窓の奥に追加の白板は置かない．

既知の差分（実機との不一致）

Step 8 進行中に把握した、実機との未解消の差分：

1. 3D プリンタ白素材の反射率の正確な値: 暫定 0.85 だが、実物のフィラメント（PLA / PETG / ABS のどれか）と分光反射率データで再校正が必要．
2. 左右 LED 基板の正確な位置・向き: STL から推定した座標で、Fusion 360 設計とのズレがある可能性．
3. LED 1 個あたりの実 W 値（物性確定・物理整合確認済み、未対処項目は反射率の再校正のみ）: 実機搭載 LED は LED Paradise LP-2835D90VW（Ra98 SunLightLED 2835 4000K）と確定．規格値（Φv 16–19 lm @60 mA、Vf 3.1V）から独立推定した radiance は ≈ 2030 W/(m²·sr)、現状校正値 2807 との比 1.38× は反射率 0.85→0.89 への調整で物理範囲内（マット白プラ実用上限 0.92）に説明可能．ウォールプラグ効率 33.6% も実用 LED として妥当．LED セクション「規格値に基づく radiance の独立推定」参照．形状指標への影響なし（線形ゲイン）．残る課題は反射率の実フィラメント分光データでの再校正（既知差分 #1）．
4. スマホホルダの実素材: 推定 holder_dark (0.50)．実物確認が必要．
5. linear vs sRGB のドメイン不一致（OETF 欠落）（最大要因・解消済み）: シミュ linear と実測 gamma 空間 luma を直接突合していた交絡で見かけ差の 約 2/3．標準 sRGB OETF 順方向適用＋実測 mean アンカーを sm-evaluate に正規実装して解消（evaluation/oetf.py + EvaluationConfig.oetf、configs/eval_baseline.yaml で有効化）．以降の比較は OETF 後ドメインで行う．※ 旧版でここを「主因は ISP レンズシェーディング」としていたのは OETF を抜かした誤り．
6. 【残差の主因候補・未対処】ISP レンズシェーディング補正: 実測 PNG は実機 ISP の周辺減光電子補正込み、シミュは未補正．OETF 適用後も残る 1.6〜1.9 倍差の主因候補．LSC 順方向モデル（物理動機づけ低自由度形、overfitting 回避）で対処予定．
7. 【残差・不確実・未対処】スマホ独自トーンマップ: ISP は sRGB OETF に加え独自トーンマッピング/コントラストを掛けうる．真のトーンカーブ未知．残差の一部．調整で消さず正直に残す方針．
8. 【未対処】max_depth=8 が勾配を過大評価: depth=8→12 で勾配 linear 24.65→22.08（−2.6pt）/ sRGB 12.57→11.16（−1.4pt）．確定 YAML は現状 8 のまま（レンダコスト優先で変更保留）．キャリブ用途は depth≥12 を使うこと．
9. 評価 ROI の不一致（解消済み）: ROI を実機と物理対応させ（configs/eval_baseline.yaml = pixel (24,37,464,450)）、sm-evaluate は実測 PNG に対し MiniTias-Evaluation と小数点 14 桁レベルで一致を確認済み．評価ロジック起因の差はない．

参照（References）

• 実機写真: REFERENCE/housing_interior_real.jpg
• LED 基板拡大: REFERENCE/led_board_closeup.jpg
• Fusion 360 内部視点: REFERENCE/fusion360_housing_interior.png
• LED データシート: REFERENCE/smd2835_datasheets.png
• YAML 仕様（一般形）: SPEC_02_シーン定義仕様
• 基準設定の YAML 実体: configs/scene_baseline.yaml