MiniTIAS への回答 (Response to MiniTIAS)

本ドキュメントは TECH_03 定量モード実装報告と SHADING_MODE 相談 に対する SmTIAS-LightSim 側からの回答書 である．MiniTIAS 側の実装結果評価・SHADING_MODE 判断・物理解釈の修正・運用上の合意事項を明文化する．

想定読者 (Intended Reader)

• MiniTIAS 側 Claude セッション: 本ドキュメントを読んで，SmTIAS-LightSim 側の判断と次フェーズの依頼内容を把握する．
• 人間レビュー (rinto): 両セッションの判断整合を確認する．

サマリ (Summary)

→ フェーズ A で MiniTIAS 側に追加で依頼するのは 画素統計・Hot pixel map の 2 件と 白板 1 ショット試し撮りのみ．連射機能はフェーズ B まで保留．

SHADING_MODE 判断の詳細 (SHADING_MODE Decision Rationale)

結論

選択肢 (1) HIGH_QUALITY を本流で維持．MiniTIAS 側の現状実装をそのまま継続する．

物理的整合性の説明

TECH_03 §SHADING_MODE 経緯では「Mitsuba 出力は LSC 適用前の生 Bayer 相当か？」という確認があったが，実はそうではない．Mitsuba 3 の orthographic sensor は次の特性を持つ：

つまり：

• Mitsuba 出力 ≒ 「ISP が完璧に LSC 補正できた場合の理想値」相当
• これと HIGH_QUALITY DNG を直接比較するのが 物理的に最も整合
• 両者の残差 = 「実機 LSC 補正の不完全度 + シミュ物理モデルの誤差」となり，これがまさに評価したい本質

逆に SHADING_OFF DNG と Mitsuba 出力を直接比較するには Mitsuba 側に物理 cos⁴ falloff を別途モデル化する必要があり，新たな自由度（絞り径・焦点距離・口径食モデル）が入る．自由度が増えれば overfitting リスクも増える．現状の方針（HIGH_QUALITY 維持）は overfitting 回避の観点でも妥当．

LSC マップの位置付け

実装した LSC マップ取得機構 (STATISTICS_LENS_SHADING_MAP_MODE = ON) は本流の比較では直接使わないが，以下の検証用途で価値が高い：

→ メタデータ JSON に LSC マップを保存し続ける現実装は そのまま維持を依頼．

将来 SHADING_OFF 切替のフォールバック条件

「もし問題があったら OFF にした時の差を確認する」という運用方針を踏まえ，以下のいずれかが発生した時に SHADING_OFF 撮影の追加検証を依頼する：

これらの条件が発動した時は，MiniTIAS 側に「同一シーンを HIGH_QUALITY と OFF で 1 セット連続撮影するオプション」の追加実装を依頼する．コスト見積もり：Kotlin 側 1〜2 時間，ファイル命名規則拡張（*_hq.dng / *_off.dng）．

現時点では発動条件未到達．実装は不要．

Mitsuba 出力の物理解釈の補足 (Physical Interpretation Note)

TECH_03 §SHADING_MODE 経緯で混乱の元になった「Mitsuba 出力 = 生 Bayer 相当か？」について，SmTIAS-LightSim 側の正式な物理モデルを整理する．

現状の Mitsuba シーン構成

• emitter: LED 配置から 18 個の area emitter（位置は Fusion 360 設計 STL から抽出，Step 8-9 参照）
• bsdf: Lambertian（反射率 0.85，校正は Step 8-6 参照）
• integrator: path tracer（多重反射，max_depth=8）
• sensor: orthographic（平行投影，cos⁴ falloff なし）

→ シミュ luminance.npy は「評価板表面の物理放射輝度 L を orthographic 平行光線でサンプリングした値」．これは「実カメラで perspective sensor + 完璧な LSC 補正が掛かった時の出力」に最も近い．

厳密に言えば足りないもの

物理的に Mitsuba 出力と HIGH_QUALITY DNG が完全一致しない理由：

→ MiniTIAS 側 DNG (HIGH_QUALITY) は 10-bit linear で sRGB OETF 未適用のはず．SmTIAS-LightSim 側で DNG 読み込み時に linear 域で評価し，比較時には Mitsuba 側も linear のまま使う（または両者に同じ OETF を適用する）．

作業フェーズ分け (Work Phase Strategy)

本回答時点での研究上の優先順位として，「シミュ vs 実機の対応がそもそも取れるか」を 1 ショットで先に確認してから連射に進む 二段階方式を採用する．

方針の根拠

• 連射再現性が確保できても，シミュとの対応自体が取れなければ意味が薄い
• 1 ショット分析でフェーズ A の対応が取れない場合：
  • 物理モデルの根本見直し（Mitsuba 側の物性・配光・反射特性）
  • SHADING_MODE フォールバック条件 C1〜C3 の発動判断
  • シミュ側の自由度パラメータの再キャリブ
• これらは どれも 1 ショット分析で判断できる ことで，連射機能の有無に依らない
• 連射機能を先に実装すると「結局使わないかもしれない実装」のコストがかかるリスクがある

フェーズ A（直近・1 ショット対応検証）

目的: 1 枚の定量モード DNG とシミュ Mitsuba 出力の対応そのものを評価する．

MiniTIAS 側の作業:

1. 白板で 1 ショット試し撮り（現状実装で OK，追加実装なし）

   • 1/60s + ISO 40 で mean が 10-bit 中央値 500 前後に収まるか確認
   • 範囲外なら露光時間 or ISO を 1〜2 通り試行
   • 確定した撮影条件と DNG + meta.json を SmTIAS-LightSim 側に共有

2. 画素統計を meta.json に追加（高優先）

   • mean_per_channel / max_per_channel / p99 / saturated_pixel_ratio
   • 撮影直後に飽和判定したい．撮り直しの即時判定にも使える

3. Hot pixel map 取得（高優先）

   • STATISTICS_HOT_PIXEL_MAP_MODE = ON
   • meta.json に座標リストを記録．SmTIAS-LightSim 側の解析でマスク

SmTIAS-LightSim 側の作業:

1. DNG (RAW_SENSOR) 読み込み I/F の実装 (evaluation/dng_loader.py 想定)

   • rawpy 等で 10-bit BGGR Bayer を展開
   • 黒レベル除去 + デモザイク

2. メタデータ JSON 読み込み I/F の実装 (evaluation/metadata.py 想定)

   • settings / actual / sensorCharacteristics / lscMap の読み取り
   • hot pixel マスク適用機能

3. 新規 baseline config の作成 (configs/eval_baseline_quantitative.yaml)

   • 既存 baseline と並列保持

4. 1 ショット シミュ vs 実機 突合

   • sm-evaluate に DNG 入力経路を追加
   • 既存メトリクス（CoV / 勾配 / C/P / max-min）を 1 ショット定量モード DNG に適用
   • TEST_01 に Step 8-13 として記録

フェーズ A 完了の判定:

• 1 ショット定量モード DNG（10-bit linear，HIGH_QUALITY，hot pixel マスク済）と Mitsuba シミュ luminance.npy の評価指標を直接比較
• 既存 baseline（通常モード PNG）での残差 2.1× が どう変化するか を観察
• 結果次第で以下を判断：
  • 残差が縮む（≤ 1.5×）: 撮影モード変更が効いた．フェーズ B に進む
  • 残差変わらず: SHADING_MODE フォールバック条件 C1 の検討・物理モデル見直し
  • 残差が増える: 解析パイプラインの不整合（DNG 読み込み・黒レベル・デモザイク）を疑う

フェーズ B（後続・連射再現性検証）

フェーズ A で対応の見通しが立った場合のみ着手．目的は TECH_01 検証 V1（10 連射 mean CoV < 1%）の達成．

MiniTIAS 側の作業（フェーズ B 時点）:

• 連射 UI 実装: ボタンタップ → 10 連射 → 全保存
  • ファイル命名: MiniTIAS_QM_YYYYMMDD_HHmmss_burst{0..9}.dng
  • 連射間隔は端末性能依存．インターバル指定は不要
  • meta.json は撮影ごとに保存（10 個生成）．プレビュー JPEG は 1 枚で十分

SmTIAS-LightSim 側の作業（フェーズ B 時点）:

• 再現性検証スクリプト scripts/verify_repeatability.py
  • 10 ショット間で mean / std / CoV / 形状指標を集計
  • V1 合格判定（mean CoV < 1%，形状指標 std < 0.005）

役割分担の根拠：SmTIAS-LightSim 側に既存の解析基盤（uniformity.py, evaluation/*.py）があるので，再現性検証もそこに統合する方が将来のキャリブ作業との整合性が高い．

フェーズ B 着手の条件

• フェーズ A で「シミュ vs 実機」の対応が一定程度取れた（残差 ≤ 1.5× 程度）
• もしくはフェーズ A の結果から「連射で SN 比改善 / 平均値安定化が必要」と判断された
• いずれもフェーズ A 完了後に判断する

露光時間・ISO 運用の目安 (Exposure & ISO Guideline)

TECH_03 「露光時間 / ISO の運用」への回答：

白板撮影の理想値

10-bit DNG (値域 0〜1023) で：

現状の 1/60s + ISO 40 が適切かは 実機で 1 度白板撮影して mean を確認する必要がある．mean が 400 を下回るなら露光時間を倍にする（1/30s）または ISO を上げる．mean が 600 を超えるなら露光時間を半分（1/120s）に．

MiniTIAS 側の半自動キャリブ機能（TECH_03 「検討中の対応 (a)」）について

提案された「AE を 1 回走らせて値を読み，以降固定」は 歓迎．実装すれば以下の利点：

• 環境光（部屋の明るさ）の影響を吸収して撮影条件を一定化
• 白板用・舌模型用で個別校正値を保持できる
• meta.json の settings.exposure_time_ns / settings.sensor_sensitivity_iso に校正済み値を記録

ただし優先度は 中（現状の手動ハードコードでも研究は進められる）．連射 UI と画素統計が先．

改善案優先度のフィードバック (Improvement Priority Feedback)

TECH_03 「検討中の改善案」に対する SmTIAS-LightSim 側の優先度評価．本回答ではフェーズ A/B 分けにより 連射 UI を高優先 → フェーズ B（中優先）に降格する点が当初提案からの修正．

→ フェーズ A で MiniTIAS 側に依頼するのは「画素統計・Hot pixel map」の 2 件のみ．連射 UI と他項目はフェーズ A 完了後に再評価．

データ受け渡し細部の追補 (Data Exchange Refinements)

TECH_02 データ受け渡し仕様 を以下で補足する．

ファイル転送経路

• 推奨: adb pull /sdcard/Pictures/MiniTIAS/ <local_path>
• 非推奨: Windows エクスプローラ経由 MTP コピー（DNG サイズ 16MB で不整合報告あり）

配置先（既存仕様の確認）

SmTIAS-LightSim/
└── reference_measurement/
    └── quantitative/
        ├── MiniTIAS_QM_YYYYMMDD_HHmmss.dng
        ├── MiniTIAS_QM_YYYYMMDD_HHmmss.meta.json
        ├── MiniTIAS_QM_YYYYMMDD_HHmmss.preview.jpg  # 解析対象外（任意配置）
        └── MiniTIAS_QM_YYYYMMDD_HHmmss_burst{0..9}.dng  # 連射時

reference_measurement/ は .gitignore 対象（個人ローカル）．preview.jpg は解析不要なので配置任意．

既存 baseline の参照

MiniTIAS_20260408_144434.png（通常モード）は SmTIAS-LightSim/reference_measurement/MiniTIAS_20260408_144434/ 配下に保持．新規定量モード baseline 取得後は参考扱いで，本流キャリブから外す．

次のフェーズの作業範囲 (Next Phase Scope)

本回答に基づく次フェーズの作業を整理．フェーズ A 完了後にフェーズ B への移行を判断する．

フェーズ A（直近・1 ショット対応検証）

MiniTIAS 側（実装依頼）

1. 画素統計を meta.json に追加（高優先・フェーズ A 必須）
   • mean_per_channel / max_per_channel / p99 / saturated_pixel_ratio
2. Hot pixel map 取得・meta.json に保存（高優先・フェーズ A 必須）
   • STATISTICS_HOT_PIXEL_MAP_MODE = ON
3. 白板で 1 ショット試し撮り → mean 確認（露光/ISO の妥当性確認）
   • mean が 400〜600（10-bit 黒レベル除去後）なら現状の 1/60s + ISO 40 で運用
   • 範囲外なら設定を調整
4. 確定した撮影条件で 白板を 1 枚撮影 → reference_measurement/quantitative/ へ adb pull 転送

連射 UI は不要．本フェーズでは 1 ショット分析を優先．

SmTIAS-LightSim 側（受け入れ実装）

1. DNG (RAW_SENSOR) 読み込み I/F の実装（evaluation/dng_loader.py 新規想定）
2. メタデータ JSON 読み込み I/F の実装（evaluation/metadata.py 新規想定）
3. LSC マップ読み込み I/F の実装（検証用，本流では使わない）
4. 新規定量モード baseline 設定 configs/eval_baseline_quantitative.yaml の作成
5. 1 ショット シミュ vs 実機の突合
   • 既存メトリクス（CoV / 勾配 / C/P / max-min）を 1 ショット DNG に適用
   • 既存通常モード baseline 残差 2.1× が定量モードで どう変化するか を観察
6. TEST_01 に Step 8-13: 定量モード 1 ショット対応検証 として記録

フェーズ A 完了判定とフェーズ B 移行条件

フェーズ A 完了後，1 ショット突合の結果から以下を判断：

フェーズ B（後続・連射 V1 検証）

フェーズ A で対応の見通しが立った場合のみ着手．

MiniTIAS 側（フェーズ B 時点）

• 10 連射 UI 実装（V1 検証前提）
• 連射機能で 10 ショット baseline 撮影 → reference_measurement/quantitative/ へ転送

SmTIAS-LightSim 側（フェーズ B 時点）

• 再現性検証スクリプト scripts/verify_repeatability.py の実装
• V1 検証実施
• 必要に応じてキャリブ自由度（反射率・emitter 強度等）を再調整

未確定事項 (Pending Items)

以下は本回答時点では判断保留．後続作業の進捗に応じて追加判断する：

関連ドキュメント (Related Documents)

• TECH_01 定量撮影モード要求仕様 — MiniTIAS 側への原始要求
• TECH_02 MiniTIAS 引き継ぎ手順 — 引き継ぎ作業ガイド
• TECH_03 定量モード実装報告と SHADING_MODE 相談 — MiniTIAS 側からの実装報告（本回答の対象）
• TEST_01 キャリブレーション検証履歴 — Step 8 系の経緯
• TEST_03 輝度マップ形状追跡 — 形のずれ議論．LSC モデル化の物理動機
• SPEC_04 評価仕様 — sm-evaluate パイプライン