Newer
Older
SmTIAS-LightSim / docs / 04_SPEC / SPEC_03_基準設計の物理構成.md

基準設計の物理構成 (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 座標構造役割
表面(外側)+Z 法線Z=-2.5〜+12.5(凹凸)楕円窓 + AR マーカー + カラーチャート撮影された画像で見える側.スマホで写真を撮るときに映る面
裏面(内側)-Z 法線Z=-4.5(平面)平坦な取付面照度均一性の評価対象面.LED 光がこの面に均一に届くことが MiniTIAS の設計目的

評価対象面

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

LED(光源)

物理仕様

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

項目値根拠
型番LP-2835D90VWLED Paradise 商品ページ
パッケージSMD 2835同上、REFERENCE/smd2835_datasheets.png
サイズ(外形)2.8 × 3.5 mm2835 命名規則どおり(現 YAML の size と一致)
色温度3800–4250 K(公称 4000 K)LED Paradise
演色性 Ra98(太陽光近似スペクトル)同上
順方向電圧 Vf3.1 V (typ)同上
順方向電流 If60 mA (max)同上.実機は規格通り 60 mA で運用する前提
全光束 Φv16–19 lm @ 60 mA(中央値 17.5 lm)同上
電気入力電力Vf × If ≈ 186 mW上記から算出
配光角(ビーム角)120°(半値全幅、Lambertian と数学的に整合)同上
詳細配光プロファイル(IES)未提供LED Paradise 商品ページにデータシート PDF 掲載なし
分光分布(SPD)グラフ未提供(4000K Ra98 と説明のみ)同上

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

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

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

ステップ値備考
全光束 Φv(@60 mA、typ 中央値)17.5 lm16–19 lm の中央値
LER(4000K 高 CRI 白色 LED の典型値)≈ 280 lm/W5000K で ~300、3000K で ~260、Ra98 で V(λ) ピーク外帯を多く含むため低め
放射束 Φe = Φv / LER0.0625 W1 LED あたり
発光面積 A9.8 × 10⁻⁶ m²2.8 × 3.5 mm
半球 Lambertian 積分: Φe = L · A · π
規格推定 radianceL ≈ 2030 W/(m²·sr)駆動電流 60 mA・LER 280 lm/W・面光源 2835 想定
現状校正値(mean アンカー)2807 W/(m²·sr)configs/scene_baseline.yaml:65
比2807 / 2030 ≈ 1.38×

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²

Spot emitter による配光表現(Step 8-10 試行)

scripts/extract_led_positions_from_stl.py の SpotLight クラスを用いて,LED の配光をデータシート FWHM 120° に従う Mitsuba spot emitter で表現する試行を実施.configs/scene_baseline_spot.yaml に 18 LED 分の spot 設定を並列保持.

項目設定
typespot
cutoff_angle90°(半球内のみ発光)
beam_width30°(中央フラット領域)
半値 (FWHM)(90 + 30) / 2 = 60° → 配光角 120° と一致
intensity (I_0)0.026784 W/sr(flux Φ=0.0864 W/LED を保存する数値積分から)

結果: X 方向の対称性が部分改善(目視).数値指標は微悪化.Y 方向の中央ピークは LSC が必要.詳細は TEST_01 Step 8-10.LSC モデル化との組み合わせで本格採用可否を判断する.

データシート従順版(Step 8-11 試行)

Step 8-10 の spot を データシート規格値 + 同等品配光プロファイル で更に詰めた版を configs/scene_baseline_datasheet.yaml に並列保持.

項目設定出典
LED typespotStep 8-10 から踏襲
cutoff_angle85°同等品 SMD 2835 の典型配光 cos^1.2 を表現
beam_width26.72°同上.半値 55.86° (FWHM 111.72°)
I_00.021951 W/sr規格 Φv=17.5 lm / LER 280 lm/W = 0.0625 W,配光積分 K=2.847 sr
printer_white.reflectance0.89Step 8-6 で導出した規格 radiance との物理整合点

結果: Step 8-10 と 8-9 の中間値(CoV 0.183, 勾配 26.79%, C/P 1.366).形は依然 Y 軸単調勾配.データシート従順度を上げても形は実機に近づかないことを確定.副次的に「規格値だけで mean を実機に合わせることはできず,校正値 (radiance=2807) には他のレバーの累積吸収が含まれる」が再確認された.詳細は TEST_01 Step 8-11.

配置

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

基板LED 基板カバー中心 mmLED 並び方向個数
下(Y-)(0, -70.25, -65.35)X 軸6
右(X+)(+65.25, -14.97, -65.27)Y 軸6
左(X-)(-65.26, -15.00, -65.27)Y 軸6

各基板上の LED 6 個は 3 個 + 中央ギャップ + 3 個 の配置(LED 同士 4.2 mm 間隔,中央 10.8 mm ギャップ).中央ギャップは電流制限抵抗 2 個分のスペースに対応(実機写真 REFERENCE/led_board_closeup.jpg で確認).total 18 個.

LED 18 個の正確な座標は Step 8-9 で Fusion 360 設計 (configs/meshes/SmTIASv3.stl) から抽出 し,scripts/extract_led_positions_from_stl.py 経由で configs/scene_baseline.yaml の lights セクションを更新済み.抽出値は configs/leds_extracted.yaml を参照.既知差分 #2 はこれで解消(TEST_01 Step 8-9).

カメラ(センサ)

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

項目値意図
typeorthographicパースペクティブ歪みを排除し、評価板の各位置の輝度を pixel と 1 対 1 対応させる
position(0, 0, -50) mm評価板の裏面(Z=-4.5)より少し離れ、かつ LED 基板(Z=-65.3)より評価板側.ray の経路に LED が入らない位置
target(0, 0, 0) mm評価板の方向(+Z)を見る
ortho_scale(50, 52) mm評価板の bbox(X=99, Y=102 mm)に余裕を持たせた半幅

カメラ位置が評価板に近すぎる(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(モンテカルロ光線追跡)を使用し、多重反射(インターリフレクション)まで含めて計算する.

項目値意味
integratorpath多重反射を考慮した path tracing.LED → 内壁 → 評価板 のような間接照明経路もすべて積分する
max_depth16ray の最大反射回数.Step 8-14 候補 α 前半 (2026-06-03) で d=16 に更新.5 値スイープ {8,12,16,20,28} の結果 d=16 で形状指標 4 つすべてが実用的に収束(d=16→28 で CoV 改善は 1.3% のみで MC ノイズ同等).理論累積 92.6%.d=8 時代に比べて勾配を 24.01→20.59% に改善.既知差分 #6 解消(TEST_01 § Step 8-14 候補 α 前半 参照)
spp1024pixel あたりサンプル数.大きいほどノイズ減・計算重.spp 校正済み(下記「キャリブレーション経過」参照).llvm_ad_rgb・512×512 で 1 レンダ約 9.6 分
variantllvm_ad_rgbLLVM JIT による RGB レンダリング.LLVM-C.dll が PATH(または DRJIT_LIBLLVM_PATH)で参照可能なこと

多重反射の意味

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

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

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: 16)から独立設定する.本ドキュメント記載の「depth=8 は均一化に効く後段多重反射を取りこぼし空間差を過大評価」の知見に基づき、3D ベイクは depth≥12 で内壁照度を物理どおり均一に近づける(2D の sm-render は Step 8-14 で d=16 へ更新済み、独立変更は不要).
  • 3D ビューアは既定で**幾何カリング(--cull-outward)**=法線がシーン外を向く「外向き面」を非描画にする.筐体の外向き面は空洞外=入射照度 ≈0 で、これを半透明描画すると暗殻の濁り・内壁との見かけ段差を生む(調査で判明:隣接内壁の照度自体は同一手法ベイクで ~1〜2 倍以内とほぼ均一.段差の主因は外向き ≈0 面の混在).カリングで内向き面のみ描画し、共有 clim も可視内向き面に密着させる.
  • max_depth を超える反射は無視される.現状 d=16 では 0.85^16 ≈ 7.4% の最終 bounce 寄与で、理論累積の 92.6% を取り込み.d=16→28 (98.7%) の追加改善は CoV 1.3% で MC ノイズ同等のため d=16 で実用収束.参考: 過去 d=8 では 0.85^8 ≈ 27% 減衰で キャリブ実測で無視できなかった(depth=8→12 で勾配が linear 24.65→22.08 / sRGB 12.57→11.16).Step 8-14 候補 α 前半で d=8 → 16 へ更新.キャリブ用途は depth≥16 を使うこと.

筐体(材料)

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

部品材料定義名材料モデルreflectance備考
前側 / 後側(筐体)printer_whitediffuse0.853D プリンタ白フィラメント(暫定値.実物の素材データシートで再校正)
LED 基板カバー 3 枚(下 / 右 / 左)printer_whitediffuse0.85同じ 3D プリンタ白素材.不透明な白プラの枠で LED の周囲を囲む構造.Step 8-9 で 1 枚(下基板用)から 3 枚構成(下/右/左の各基板用) に展開.meshes/LED基板カバー{下,右,左}.stl(configs/meshes/SmTIASv3.stl から scripts/extract_led_positions_from_stl.py --export-covers で抽出)
評価板printer_whitediffuse0.853D プリンタ白.照度マップ上の輝度から照度への換算は E ≈ pixel × π / 0.85
スマホホルダholder_darkdiffuse0.50別素材(推定.要確認)
スマホ本体(SH-02M)phone_body_darkdiffuse0.05樹脂・金属の黒系

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

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

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

評価関連 (Evaluation — See SPEC_04)

本シーンの評価方法論(ROI / OETF / メトリクス / 可視化),キャリブレーション目標と経過要約は SPEC_04_評価仕様 に集約した.以下を参照:

本書 (SPEC_03) は 物理構成(位置・材料・LED・カメラ・レンダ設定)と既知差分 に範囲を限定する.

想定どおりの挙動(追加対応不要)

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

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

既知の差分(実機との不一致)

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

  1. 3D プリンタ白素材の反射率の正確な値: 暫定 0.85 だが、実物のフィラメント(PLA / PETG / ABS のどれか)と分光反射率データで再校正が必要.
  2. 左右 LED 基板の正確な位置・向き(解消済み・Fusion 設計から正確化): configs/meshes/SmTIASv3.stl(Fusion 360 アセンブリ全体エクスポート)から 18 LED 位置を scripts/extract_led_positions_from_stl.py で抽出し,configs/scene_baseline.yaml の lights セクションを更新.主な変更: 下基板内 LED 配置を「等間隔 8.7mm」→「3+ギャップ+3 (4.2mm+10.8mm+4.2mm)」へ訂正.左右基板も実位置 X=±66.0, Y=-12 付近に修正.direction は (0,0,-1) で不変(実機写真の中央電流制限抵抗 2 個と整合).形状指標は ~1% 以内のほぼ不変(多重反射が支配的,LED 数 mm 誤差は ROI 上で平滑化).TEST_01 Step 8-9 参照.
  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 が勾配を過大評価(解消済み 2026-06-03): Step 8-14 候補 α 前半で d=8→16 へ更新.5 値スイープ {8,12,16,20,28} で d=16 が実用収束点(d=16→28 の追加改善は CoV 1.3% で MC ノイズ同等)と判明.d=8 時代の勾配 24.65% → d=16 で 20.59% に改善.参考: TEST_01 § Step 8-14 候補 α 前半.
  9. 評価 ROI の不一致(解消済み): ROI を実機と物理対応させ(configs/eval_baseline.yaml = pixel (24,37,464,450))、sm-evaluate は実測 PNG に対し MiniTias-Evaluation と小数点 14 桁レベルで一致を確認済み.評価ロジック起因の差はない.

参照(References)