Fork: 0
hasegawa / SmTIAS-LightSim
Transfer to URL with SHA Find file
Newer
Older
SmTIAS-LightSim / CLAUDE.md
@rintoHasegawa rintoHasegawa 15 days ago 28 KB [update] テンプレートを最新版（00dd94e）に同期
Raw Blame History

SmTIAS-LightSim

SmTIAS（スマートフォン舌画像撮影装置）の照明均一性を実機制作前に検討するための光散乱シミュレーションツール． LED 配置・ディフューザー形状を仮想的に変えながら，SmTIAS-Evaluation と同じ指標（CoV／3 ゾーン分析等）で均一性を定量評価できるようにする．

外部参照リポジトリ

関連プロジェクトのローカルコピーは置かない．参照が必要になったときに gh CLI で GitHub から直接最新を読むこと．

# ファイル一覧（リポジトリ構造の把握）
gh api "repos/rintoHasegawa/SmTIAS-Evaluation/git/trees/main?recursive=1" --jq '.tree[].path'

# ファイル内容の取得（常に main の最新）
gh api -H "Accept: application/vnd.github.raw" \
  "repos/rintoHasegawa/SmTIAS-Evaluation/contents/docs/PROGRESS.md"

これらの内容の修正は各リポジトリ側で行う（本リポジトリからは読み取り専用として扱う）．

開発進捗

最新: フェーズ 7（実装）— TEST_20 実機とシミュの形の突き合わせと配光の検討（実機 DNG 全灯 + 単灯 3 灯とシミュを同じノイズ処理で比較．同心円方向は ρ≈0.81 で合うが，単灯で明部が反対側へ寄る量と「左上が暗い」傾きはシミュが実機の半分．壁の光沢 ω・α では形全体を崩さずに合わせられず，LED 配光を spot FWHM 45〜60° に狭めると 4 構成の差分 RMS が最良．新しい基準候補は採用材質 ρ=0.85・ω=0.05・α=0.1 + spot 45〜60°．共通の傾きは基板の位置・向きが第一候補で未解決）．前ステップ: TEST_18 照明配置依存性（配置依存は球が立方体の 1/2〜1/3），TEST_19 spp と計算時間（GPU 時間 ∝ spp，構造 CoV は 1024 で十分）．サーバは sm-remote（学外からは SM_REMOTE_HOST=Newton-via-lab）．環境: mitsuba は 3.7.1 に固定（テストは uv run python -m pytest），開発機の SAC はオフ（ENV_04 参照）．同一 seed の再レンダは集計指標が一致するので，ノイズフロアは render.seed を変えて測る．spp の指針（TEST_19）: GPU 時間は spp に比例（1024 で 5 秒）・固定費 0.8 秒・ノイズは 1/√spp 則．構造 CoV なら 1024，画像全体 min/max 比を暗い条件で比べるなら 2048〜4096．詳細は docs/PROGRESS.md．

実装済みモジュール:

  • src/sm_tias_lightsim/uniformity.py — Rec.709 輝度変換 + CoV/std/max-min（SmTIAS-Evaluation コピー）
  • src/sm_tias_lightsim/evaluation/zones.py — 正規化楕円距離マップ + 3 ゾーン分類 + ゾーン別統計
  • src/sm_tias_lightsim/evaluation/radial.py — 20 ビン放射状輝度プロファイル
  • src/sm_tias_lightsim/evaluation/roi.py — image_pixel 型矩形 ROI 抽出（2D/3D 配列対応）
  • src/sm_tias_lightsim/evaluation/oetf.py — 標準 sRGB OETF（IEC 61966-2-1）+ 露出ソルバ（OETF 後 ROI mean を実測値に対数二分でアンカー）+ 順方向適用．シミュ linear を実測 sRGB ドメインへ変換
  • src/sm_tias_lightsim/evaluation/normalize.py — linear mean anchor 正規化（apply_mean_anchor）．OETF と排他適用，形状指標は厳密不変で mean のみ target_mean に揃う．configs/eval_baseline_linear.yaml で有効化
  • src/sm_tias_lightsim/evaluation/visualize.py — matplotlib 可視化（輝度マップ / ヒストグラム / 放射プロファイル / ゾーンマップ）．SmTIAS-Evaluation 互換スタイル（hot cmap，zone_map は luminance 背景 + 境界線）
  • src/sm_tias_lightsim/scene/schema.py — Pydantic ベース YAML スキーマ + ローダ．SensorConfig は perspective / orthographic 両対応．materials は DiffuseMaterial / RoughConductorBSDFConfig (alpha + distribution=ggx/beckmann，material="none" 固定で完全反射体) / BlendBSDFConfig (weight + components×2，再帰ネスト可能，forward reference + model_rebuild()) を Union として並列サポート．後方互換維持
  • src/sm_tias_lightsim/scene/audit.py — シーンの物理的健全性を監査するモジュール（TEST_13）．check_truncation_bias は最大反射率と max_depth から多重反射の打ち切りによる相対エネルギー欠損（rho^(max_depth-1)）を見積もり，1% を超えると警告文を返す（build_scene から呼ばれ警告ログを出す）．audit_scene_normals は読み込み済み Mitsuba シーンにレイを飛ばし，シェーディング法線と幾何法線の一致（face_normals の実効性）と裏向き面の有無を実測する（ベクトル化 variant では 1 回の交差計算にまとめる）
  • src/sm_tias_lightsim/geometry/loader.py — STL 読込（trimesh）+ LoadedMesh データクラス
  • src/sm_tias_lightsim/geometry/transforms.py — mm⇄m 単位スケール変換
  • src/sm_tias_lightsim/scene/{lights,materials,sensors}.py — Mitsuba emitter / BSDF / sensor dict 変換（sensors は orthographic 対応，lights は area / point / directional / spot 対応．Step 8-10 で SpotLight を追加，Step 8-14 β で materials.py に _build_bsdf_dict 再帰ヘルパを追加して blendbsdf ネスト対応）
  • scripts/select_white_board.py — 実測 PNG で白色板境界を OpenCV GUI で選択（Step 8 キャリブ用）
  • scripts/visualize_roi_3d.py — 評価板 STL に ROI を 3D 投影（PyVista，Step 8 キャリブ用）
  • src/sm_tias_lightsim/scene/builder.py — SceneConfig → Mitsuba scene dict（PLY 一時ファイル経由）
  • src/sm_tias_lightsim/render/runner.py — variant 管理（ensure_variant：プロセス内 1 回だけ設定．遮蔽検証などレンダ以外の前にも呼べる）+ mi.render 実行（render.seed を渡す）
  • src/sm_tias_lightsim/render/output.py — PNG / luminance.npy 出力
  • src/sm_tias_lightsim/render/pipeline.py — render_yaml(scene_yaml, output_dir, variant=None)：YAML 読込 → variant 解決 → レンダ → PNG/npy 保存の一括関数．sm-render の本体で，スイープはこれをプロセス内で呼ぶ（起動・import の重複を省く）
  • src/sm_tias_lightsim/evaluation/pipeline.py — evaluate_image(image, config, output_dir, save_figures=True)：sm-evaluate の本体．指標 dict を返し metrics.csv を書く．save_figures=False で図を省略（--no-figures）
  • src/sm_tias_lightsim/cli/render.py — sm-render CLI（YAML → PNG / luminance.npy）．--variant > 環境変数 SM_RENDER_VARIANT > YAML の優先順で variant を上書き（手元 llvm・サーバ cuda を同じ YAML で）
  • src/sm_tias_lightsim/cli/evaluate.py — sm-evaluate CLI（PNG / luminance.npy → metrics.csv + figures/）．oetf.enabled 時は ROI 抽出後・指標算出前に sRGB OETF を順方向適用，normalization.enabled 時は OETF 前段に linear mean 揃え正規化（OETF と排他）．後方互換、シミュ用設定のみ
  • src/sm_tias_lightsim/visualize/baker.py — face 中心の照度ベイク．mode="direct"（shadow ray + cosine + 距離減衰、直接光のみ、後方互換）/ mode="path"（scalar_rgb・完全シーン・コサイン重点 hemisphere MC、多重反射込み per-face、exclude_mesh_ids 対応）．max_depth 引数で path ベイクの反射回数を render 設定から独立設定（None で render 継承＝後方互換）
  • src/sm_tias_lightsim/visualize/projection.py — orthographic センサ投影の純関数（評価板メッシュ特定 / project_luminance_to_vertices 頂点 bilinear 投影 / compute_orthographic_uv テクスチャ UV / compute_face_camera_mask 幾何 Z ベース巻き順非依存の評価面選択 / compute_inward_face_mask 法線がシーン中心側を向く内向き面判定＝幾何カリング用）．sensors.py look_at@scale 規約と整合（SPEC_03「画像↔物理の向き」検証済）
  • src/sm_tias_lightsim/visualize/viewer.py — PyVista 3D ビューア．既定＝全メッシュ統一ベイク着色（lit のみ共有 clim・log/linear・単一カラーバー・bake_opacity 半透明・hide_below 非表示・bake_smooth 平滑化・depth peeling・viridis）＋**cull_outward（既定 ON）で外向き ≈0 面を非描画**＝暗殻の濁り/見かけ段差を解消・clim も可視内向き面に密着；hide_sensor_marker/hide_led_markers でマーカー個別非表示；luminance_map 指定時＝評価板 512² テクスチャ投影（E=π·L/ρ で壁と同一 W/m² スケール、内側カメラ向き face のみ、外側ニュートラル、マスク無効時 per-vertex フォールバック）．発表スライド向け表示機能（Step 8-14 期に追加）: style（"default"／"slide"．slide=白背景・座標軸/bounds 非表示・アンチエイリアス・黒文字スカラーバー _build_scalar_bar_args・センサマーカー自動非表示．未知値は warning で default フォールバック）／ cmap（None で style 既定を解決：default→viridis・slide→hot＝照明均一性評価と同一．未知名は warning で style 既定にフォールバック，_make_irradiance_texture(cmap_name=) も同一 cmap）／ subdivide_max_edge（m 単位．ベイク前に三角形を均一分割→巨大三角形のブロック感解消）／ bake_denoise（denoise_face_scalars_median 頂点経由メディアン近似でMCノイズ/firefly除去，エッジ保存．log変換後・smooth前に適用，_get_triangle_faces で PolyData/UnstructuredGrid 両対応）／ bake_smooth_radius（m 単位．smooth_face_scalars_radius ボクセル splat/gather 物理半径ガウス平滑化＝メモリ有界・純NumPy・sigma=radius/2．denoise後・bake_smooth前に適用，三角形スケールのチェッカーノイズ除去）／ backface_cull（VTK 背面カリング culling="back"，opacity=1.0 併用で手前壁が隠れ混色なし）
  • src/sm_tias_lightsim/geometry/subdivide.py — 三角形メッシュ均一分割の純関数（新規）．subdivide_mesh_to_max_edge(vertices, faces, max_edge)＝trimesh.remesh.subdivide_to_size で「最大辺長 ≤ max_edge」まで決定論的に三角形分割（同一入力→同一出力，baker と viewer が独立呼び出しでも face 配列一致）．単位は呼び出し側座標系に従う（m 系で呼べば m）．STL の三角形サイズが極端に不均一（曲面 ~1mm² vs 平面壁 最大 4794mm²）でも均一な空間解像度の per-face ベイクを可能にする
  • src/sm_tias_lightsim/cli/visualize.py — sm-visualize CLI（YAML → 3D 表示 / screenshot）．--bake-mode {direct,path} / --bake-samples / --bake-max-depth（path ベイクの反射回数、既定 16、render 設定から独立）/ --bake-cache <npz>（1回計算→以後即時．--bake-subdivide 設定値も npz に記録し不一致なら自動再ベイク）/ --cull-outward|--no-cull-outward（既定 ON）/ --opacity / --hide-below / --bake-smooth / --bake-scale {linear,log} / --clip-percentile / --no-sensor-marker・--no-led-markers・--no-markers / --render <luminance.npy>（任意・テクスチャ投影）．発表スライド向け（Step 8-14 期に追加）: --style {default,slide} / --cmap NAME（既定: style に応じ viridis/hot）/ --bake-subdivide MM（三角形を最大辺長 MM mm 以下に均一分割）/ --bake-denoise N（メディアンデノイズ反復）/ --bake-smooth-radius MM（物理半径 MM mm のガウス平滑化）/ --backface-cull（背面カリング）．mm 引数は内部で ×0.001 して m 系で show_scene/baker へ．--render 無し＝全面統一ベイク（既定）
  • src/sm_tias_lightsim/runtime/llvm_init.py — LLVM JIT 初期化ヘルパ．ensure_drjit_libllvm_path() で DRJIT_LIBLLVM_PATH 未設定時に Windows/POSIX 標準パスを自動探索して os.environ 設定．log_variant_status() で variant 経路（llvm_/cuda_/scalar_）を INFO 明示，要求 llvm_* で実 scalar_* なら WARNING 追加．runner.py / baker.py から呼ばれ環境変数未設定時のサイレントクラッシュを防ぐ．Ubuntu / Debian の libLLVM-<版>.so と /usr/lib/llvm-*/lib/（Fedora 形式も）も探索し新しい版を優先
  • src/sm_tias_lightsim/runtime/overrides.py — 環境変数による実行時上書き．SM_RENDER_VARIANT（sm-render の variant）と SM_DRJIT_THREADS（Dr.Jit の CPU スレッド数上限．runner.py / baker.py が dr.set_thread_count で適用．共用サーバの全コア占有を防ぐ）．不正値は ValueError
  • src/sm_tias_lightsim/scene/paths.py — relative_mesh_path()：スイープ生成スクリプトが _tmp YAML に書くメッシュパスを YAML からの相対パス（POSIX 区切り）にする（手元とサーバで同じ YAML を読むため．別ドライブは警告して絶対パス）
  • src/sm_tias_lightsim/remote/{commands,files,transfer}.py + src/sm_tias_lightsim/cli/remote.py — sm-remote CLI（研究室サーバ Newton での実行）．push（tar over ssh．.venv/output/.git/configs/_tmp_* 除外）/ run（tmux でデタッチ起動．既定 cuda_ad_rgb・--gpu・--threads）/ status / logs / attach / kill / pull（output/ 配下のみ．要求パス外・不正な名前・リンクを拒否）．サーバ上で実行すると止まって案内．使い方は ENV_04「研究室サーバでの実行」
  • src/sm_tias_lightsim/evaluation/dng_loader.py — DNG 読み込みモジュール．SmTIAS-Evaluation src/io/dng_loader.py を SmTIAS-LightSim にコピーしたもの (オリジナルは SmTIAS-Evaluation 側で管理．バグ修正・機能追加はそちらで反映)．主要 API: load_image_dng(path, demosaic, black_level, output_format)．output_format は rgb_float32 / luma_float32 / rgb_uint8．linear 系出力 (rgb_float32 / luma_float32) は output_color=raw でカラーマトリクス非適用・per-channel 比例性保持．gamma=(1,1) + no_auto_bright=True + use_camera_wb=False + user_wb=[1,1,1,1] で linear raw を保つ．依存: rawpy>=0.21.0
  • src/sm_tias_lightsim/evaluation/radial.py — 20 ビン放射状輝度プロファイル．既存 calc_radial_profile に加えて SmTIAS-Evaluation src/analysis/spatial.py:calc_radial_min_max_ratio をマージ．動径 min/max 比 (20 点輪帯平均) は画素単位 max/min よりノイズに対しロバスト．nan ビン除外を移植時に補強 (既存 calc_radial_profile は空ビンを nan で返す)
  • src/sm_tias_lightsim/evaluation/fullimage.py — 画像全体で評価するノイズ補正付き最小/最大比（calc_fullimage_min_max_ratio）．σ=12 平滑化の min/max からノイズ場（残差の空間シャッフルを同じ平滑化）の極値を差し引く．動径 min/max 比が方位平均で非対称を見逃す問題（TEST_18）と，画素・パーセンタイルがノイズの裾を拾う問題の両方を避ける．MetricsConfig.fullimage_min_max / fullimage_sigma で有効化（既定 False）．偏りとノイズ床の注意は SPEC_04
  • src/sm_tias_lightsim/evaluation/shape_metrics.py — 輝度分布「形」評価指標モジュール（新規）．現状 CoV/勾配/C/P/動径 min/max は不均一性の絶対量しか測れず，Y 軸単調勾配と中央ピーク楕円を構造的に区別できない問題を解決する 5 つの純関数: calc_intensity_centroid（輝度重心，5 値）/ calc_angular_radial_decomposition（極座標分解，angular_ratio が 0=同心円〜1=方向依存，3 値）/ calc_ssim（構造的類似度，scikit-image 依存，shape_reference 指定時のみ）/ calc_ncc（正規化相関係数，絶対輝度不変）/ calc_intensity_pca（weighted PCA で主軸角度と eccentricity，4 値）．mask 省略可能，完全均一画像で angular_ratio/NCC は NaN を返す．MetricsConfig.shape_metrics=true / shape_reference フィールドで有効化，後方互換保持．依存追加: scikit-image>=0.21.0．詳細: TECH_11 形状指標の見直し ※ 本欄は最新ステップ 1 行のみ上書き更新．詳細な進捗履歴（動機・設計判断・失敗パターン）は docs/PROGRESS.md に追記する．運用ルールは .claude/rules/progress-log.md を参照（該当ファイル編集時に自動ロードされる）．

必須ルール（コード実装時）

Git 運用

  • ブランチ名・コミットメッセージの書式は .claude/rules/git-conventions.md に従う（常時ロードされる）
  • コミットは /commit を使用する（push・PR 作成は /commit push，マージ・プルまで行う場合は /commit merge）
  • /commit はユーザーが明示的に指示した時のみ実行する．Claude が自発的に /commit や git commit を呼んではならない（/implement 完了後も，案内するだけで自分ではコミットしない．/commit skill は disable-model-invocation によりユーザー起動限定として強制されている）
    • 例外: 以下（プロジェクト立ち上げと無人運転ループ）はユーザー承認済みの例外として専用ブランチに自律コミットする．いずれも push・PR・マージ・main への操作はしない（取り込みは人間が /commit push 等で行う）
      • /setup（プロジェクト立ち上げ）→ chore/project-setup 専用ブランチ（フェーズごとに 1 コミット）
      • /auto-refactor（リファクタ／ドキュメント整理ループ）→ refactor/ 専用ブランチ
      • /auto-audit（バグ／脆弱性の巡回監査ループ）→ fix/ 専用ブランチ
    • 例外（main へのマージ）: /deps-update は，Dependabot が作成した依存更新 PR に限り，ゲート（メジャー更新でない・競合なし・CI 緑またはローカル検証緑）を満たすものを gh pr merge で main に取り込む（ユーザーが明示的に起動した時のみ．メジャー更新・CI 赤・PR が付かない alert は報告して人間が判断する）
  • ops-runner によるマージは承認済みの定常操作: /commit merge および /deps-update では，ユーザーが明示的に起動したことを受けて，ops-runner サブエージェント（軽量モデル）が手順書に従い git push → gh pr create → gh pr merge --merge --delete-branch で自リポジトリの PR を main にマージする．force push・--admin・main への直接 push は行わない（権限設定は docs/01_GUIDE/GUIDE_01 の「Claude Code の権限設定」）

テンプレート同期

  • テンプレートの更新は /sync-template で取り込む
  • テンプレート由来のファイル（.claude/agents/・skills/・rules/・hooks/，docs/01_GUIDE/）をこのプロジェクトの都合で意図的に変更したときは，.claude/template-overrides.md（テンプレート改変台帳）に理由付きで記録する（.claude/rules/template-customization.md．該当ファイル編集時に自動ロードされる）．記録が無いと次回同期で改変が消えうる

タスク管理（任意）

  • やるべきことを GitHub Issues で管理してよい（solo / team 共通）．/task-create（起票・事前計画）→ /task-start <Issue番号>（着手準備）→ /task-handoff（中断時の引継ぎメモ投稿）を使う
  • Issue は必須ではない．小さい変更や試験的作業は Issue 無しで進めてよい
  • solo モードでは進捗記録（.claude/rules/progress-log.md）は従来どおり運用し，Issue はタスクの管理・引継ぎの補助として使う

エージェントチーム（GUIDE_02 準拠）

  • 実装は /implement <タスク> で開始する（コーディング → テスト → リファクタリング → ドキュメント更新）
  • Phase 1 後に人間が動作確認，Phase 2 でテスト失敗時のみ方針判断
  • Phase 2 成功後は Phase 3 → Phase 4 まで自動で進む（Phase 4 で更新がある場合のみ確認）
  • テスト・リファクタリングをスキップしない
  • 検証プロファイル（.claude/verify-profile.md）を用意したプロジェクトでは，Phase 1 の後に Phase 1b（verifier による動作確認．対象はローカル環境と，プロファイルが根拠つきで許可した検証用環境のみ．本番は対象外）が入り，人間が確認する範囲が絞られる（単独実行は /verify）．プロファイルが無ければ Phase 1b はスキップされ，動作確認は従来どおり人間が行う．verifier の OK は人間の動作確認の代わりにならない

開発コマンド

  • 起動・テスト・lint 等の開発コマンドは docs/02_ENV/ENV_04_開発コマンド.md にまとめる．存在する場合は実行前に必ず参照し，推測でコマンドを試さない
  • コマンドが新しく確定・変更された時は同ファイルに反映する（無ければその時点で作成する．/implement の Phase 4 でも見直される）

シミュレーション実験の進め方

  • 幾何（メッシュ・光源・センサ位置）を変えるシーンは，本番レンダを回す前に必ず 3D で配置確認する（sm-visualize --no-bake --screenshot / scripts/show_led_geometry.py）．確認画像をユーザーに提示し，位置の OK をもらってからレンダを実行する（2026-08-18 ユーザー指示）

手動確認が必要な作業（自分で完了させないこと）

以下は実装完了後にユーザーへ報告し，確認・実施を依頼すること．

  • 外部サービスの設定（コンソール操作，セキュリティルール変更等）
    • 例外: gh CLI で操作できる GitHub リポジトリ設定（Dependabot alerts / security updates の有効化）は Claude が gh api で行う（手順は .claude/skills/setup/reference.md，背景は GUIDE_01「環境構築」）
  • 実機・ブラウザでの動作確認（verifier による自動検証は前段であり，これを置き換えない）
  • ストアへのアップロード・リリース作業

ドキュメント

設計・規約に関する情報は docs/ にある． コードを書く前に関連するファイルを読むこと．

01_GUIDE（規約・ルール）

  • プロジェクト立ち上げフロー: docs/01_GUIDE/GUIDE_01_プロジェクト立ち上げフロー.md
  • エージェント運用ルール: docs/01_GUIDE/GUIDE_02_エージェント運用ルール.md
  • ※ コーディング規約・テスト方針・構成規則・エラー処理・Git 規約・ドキュメント書式・命名規則・進捗記録・テンプレート改変記録は .claude/rules/（coding-style / testing / project-structure / error-handling / git-conventions / markdown-style / docs-naming / progress-log / template-customization）に path-scoped rule として定義されている（git-conventions は常時，他は該当ファイル編集時に自動ロード）

02_ENV（環境）

  • 技術スタック: docs/02_ENV/ENV_01_技術スタック.md
  • 環境構築手順: docs/02_ENV/ENV_02_環境構築手順.md
  • 管理者用環境構築手順: docs/02_ENV/ENV_03_管理者用環境構築手順.md

03_PLAN（計画）

  • 要件定義書: docs/03_PLAN/PLAN_01_要件定義書.md
  • 開発ステップ: docs/03_PLAN/PLAN_02_開発ステップ.md

04_SPEC（仕様・設計）

  • アーキテクチャ設計: docs/04_SPEC/SPEC_01_アーキテクチャ設計.md
  • シーン定義仕様: docs/04_SPEC/SPEC_02_シーン定義仕様.md（シーン YAML + 評価 YAML のスキーマ）
  • 基準設計の物理構成: docs/04_SPEC/SPEC_03_基準設計の物理構成.md（評価関連は SPEC_04 に分離済み）
  • 評価仕様: docs/04_SPEC/SPEC_04_評価仕様.md（評価パイプライン・ROI・OETF・メトリクス・可視化・キャリブ目標と経過要約）

05_TECH（技術設計）

06_TEST（テスト）

  • キャリブレーション検証履歴: docs/06_TEST/TEST_01_キャリブレーション検証履歴.md（Step 8 イテレーション 8-1〜8-7 のフル記録．仮説／変更／数値／解釈／学びを時系列で）
  • シミュレーション実行記録: docs/06_TEST/TEST_02_シミュレーション実行記録.md（output/ 各サブディレクトリの索引．Step との対応・シーン/評価 config・主要指標・再現コマンド・削除推奨）
  • 輝度マップ形状追跡: docs/06_TEST/TEST_03_輝度マップ形状追跡.md（数値とは独立に「形」を実機に近づける観点．比較パネル画像と LSC モデル化の構造的意義）
  • 物理モデル健全性の一括監査: docs/06_TEST/TEST_13_物理モデル健全性の一括監査.md（「無警告で結果だけが歪む」故障モードの横断監査．解析解による絶対放射量検証・法線監査・打ち切りバイアス・常設した再発防止テスト）
  • 材質パラメータ再スイープと残差の構造分解: docs/06_TEST/TEST_14_材質パラメータ再スイープと残差の構造分解.md（面法線修正後の ρ×ω×α 全 60 条件スイープ．ρ ≈ 0.81 純 diffuse の確定と，材質では直せない傾き成分の分離）
  • バッフル導入と球半径スイープ: docs/06_TEST/TEST_15_バッフル導入と球半径スイープ.md（LED 壁面密着＋バッフルで直接光を遮る新構成と，球内半径 88〜250mm のスイープ．ロフト接合の 2 段階の作り直しで「大きいほど悪化」が逆転し，板直下の喉が最大のレバーと判明した経緯）
  • 立方体キャビティ導入と球との比較: docs/06_TEST/TEST_16_立方体キャビティ導入と球との比較.md（ロフト・接合・喉の無い立方体を L=120〜360mm でスイープし内面積で球と対応づけ．同面積なら立方体が一貫して均一で，四隅の写り込みは m=4 方位フーリエで検出限界以下と確認）
  • オフ軸 LED 配置の影響とサイズ依存: docs/06_TEST/TEST_17_オフ軸LED配置の影響とサイズ依存.md（LED を側壁に置いた非対称の定量．サイズとともに減衰するが，頑健性は球 > 立方体で軸上の優劣と逆転．明るくなるのは LED の反対側）
  • spp と計算時間・ノイズ・指標の安定性: docs/06_TEST/TEST_19_sppと計算時間ノイズ指標安定性.md（spp 256〜8192 × 6 条件．GPU 時間は spp に比例・固定費 0.8 秒，ノイズは 1/√spp 則に一致．構造 CoV は 1024 で十分，画像全体 min/max 比を暗い条件で比べるなら 2048〜4096）
  • 実機とシミュの形の突き合わせと配光の検討: docs/06_TEST/TEST_20_実機とシミュの形の突き合わせと配光の検討.md（実機 DNG とシミュを同じノイズ処理で全灯 + 単灯 3 灯の形で比較．お椀は ρ で合うが単灯のピークのずれと傾きはシミュが半分．壁 ω・α のスイープでは形全体を崩さずに合わせられず，LED 配光を spot FWHM 45〜60° に狭めると最良．共通の左上暗の傾きは未解決）
  • 照明配置依存性の球と立方体の比較: docs/06_TEST/TEST_18_照明配置依存性の球と立方体の比較.md（LED の位置 θ・向き・個数を同内面積ペアで振った 198 条件．配置依存は球が立方体の 1/2〜1/3，対向 2 灯以上で形状差が消える．追加実験: 立方体は面の稜へ寄せると悪化，真下向き多灯はバッフル無しで成立するが板向き多灯には劣る，校正材質 ρ=0.81 でも結論不変だが軸上は両形状とも最良になる）