LSC 取り扱い方針 (Lens Shading Correction Handling Policy)

本ドキュメントは 3 プロジェクト（SmTIAS / SmTIAS-Evaluation / SmTIAS-LightSim）における LSC (Lens Shading Correction) の取り扱い に関する設計判断と物理的根拠を明文化したものである．過去 TECH_03〜TECH_06 / TEST_05 / TEST_06 で散在していた議論の 結論をここに集約し，将来の参照を容易にする．

結論（先に） (Conclusion First)

役割分担

一言で言うと

**「実機側で LSC 順方向適用で物理 cos⁴ を除去」＋「シミュ側で orthographic で物理 cos⁴ を最初から持たない」**で，両者を 同じドメイン (LSC 補正後相当) で比較する設計．シミュ側に LSC モデル化を追加する必要も価値もない．

背景・経緯 (Background)

LSC 取り扱いの議論は，過去 Step 8 キャリブレーション（TEST_01）で「シミュ vs 実機の形が違う」現象の原因解明から始まった．時系列：

シミュ側で LSC を扱わない物理的根拠 (Physical Rationale)

各経路で「何を測っているか」

[実機・新パイプライン]
LED 発光
  ↓ 多重反射（筐体内壁）
評価板表面の放射輝度 L (W/m²/sr)  ← この値を測りたい本質
  ↓ レンズ通過時に物理 cos⁴ falloff
センサ raw （cos⁴ 残ったまま）
  ↓ DNG (RAW_SENSOR) として保存
  ↓ ★ SmTIAS-Evaluation 側で lscMap を順方向適用
  = 理論上「cos⁴ を打ち消した = 評価板表面の放射輝度 L 相当」
  ↓ Rec.709 luma 抽出 + 白板 ROI
評価指標 (CoV / 勾配 / 中心/周辺 / 動径 min/max)

[シミュ側]
LED 発光（SceneConfig）
  ↓ Mitsuba path tracer + 多重反射（max_depth=8）
評価板表面の放射輝度 L (W/m²/sr)  ← 全画素 orthographic で取得
  ↓ ★ cos⁴ falloff は最初から含まない（全画素平行光線）
luminance.npy = 放射輝度 L そのもの
  ↓ ROI 抽出
評価指標

等価性の本質

両方の「★」で同じドメイン（放射輝度 L 相当）に到達する：

• 実機: 生raw × lscMap = 放射輝度 L 相当（実機 ISP の lscMap が完璧なら）
• シミュ: 最初から放射輝度 L（cos⁴ を持たないので除去すべきものがない）

→ 両者は 構造的に同じものを測っている．シミュ側に追加の操作は不要．

検討した代替案と却下理由 (Alternatives Considered & Rejected)

過去議論で「シミュ側で LSC を考慮するか」という観点で 3 つの選択肢を検討した．結果はすべて却下：

選択肢 A: シミュに LSC 順方向モデルを追加（Step 8-N 候補だったもの）

当初の発想: 過去 TEST_03 で「形を変える唯一の道は LSC モデル化」と結論していた．シミュ側で cos⁴ または多項式モデルを sm-evaluate に追加する案．

却下理由:

• 実機側で LSC 順方向適用するアプローチが SmTIAS-Evaluation で確立した（TEST_05）→ シミュ側にモデルを追加する必要が消失
• シミュ側に自由度パラメータ（cos^n の n や多項式係数）を追加すると overfitting リスクが増す
• 過去 TEST_03 finding 4 の「形を変える唯一の道は LSC モデル化」は 当時の前提（実機側を改善しない）下での結論であり，実機側改善で同じ目的を達成した今は無効

選択肢 B: Mitsuba を perspective + thinlens に変えて物理 cos⁴ をシミュレート

発想: Mitsuba 3 の thinlens カメラを使えば物理 cos⁴ falloff が自動で出る．

却下理由:

• thinlens で cos⁴ falloff を入れても，実機側との比較には lscMap で割り戻す必要が出る
• → 結果として (シミュ × cos⁴) / lscMap と シミュ（orthographic） が 数学的に等価（lscMap ≒ cos⁴ の逆数のため）
• 余分な計算ステップが増えるだけで得るものがない
• 加えて thinlens は aperture / focal_length の物理値が必要で，自由度パラメータが増える

選択肢 C: 実機 ISP の LSC 補正残差を物理から導出してシミュに反映

発想: 「実機 LSC マップが完璧に物理 cos⁴ を補正できているか」を独立に検証してから，残差をシミュに反映する．

却下理由:

• 実機 ISP の LSC アルゴリズム・補正残差は メーカー非公開で，物理から導出できない
• 実機計測から残差を逆推定すれば数値は出るが，それは「物理モデル」ではなく「fit」であり overfitting リスク
• 残差を物理的に切り分けたい場合は SHADING_OFF 撮影（フォールバック条件 C1〜C3）が必要だが，それは別途撮影が必要な大掛かりな話

つまり「数値的に正しく考慮できない」の正確な意味

ユーザー疑問（2026-06-02）への正式回答として：

→ 「シミュ側で LSC を考慮しない」は構造的に最適．他の選択肢は「できないか」「できても価値が増えない」．

限界と注意点 (Limitations & Caveats)

1. 実機側にも残る誤差

実機 ISP の lscMap は「メーカー出荷時にキャリブされた標準補正値」であり，個体差・経時変化・撮影条件（色温度等）による補正残差が残る．これは：

• SHADING_OFF 撮影で生 raw を取得 → 物理 cos⁴ パターンと比較すれば定量化可能（フォールバック条件 C1〜C3 で実施，TECH_04）
• 現状（フォールバック未発動）では「補正残差は実機側に残るが小さい」と仮定して進めている

2. SmTIAS-LightSim 側の「実機との一致度」は別問題

LSC 取り扱いの整理が完了しても，シミュ vs 実機の 残差そのものは消えない：

→ この残差は LSC 由来ではない別要因（シミュ側の物理モデル誤差 / 反射率 / 配光 / 幾何精度等）．LSC モデル化で解消できる問題ではない．

3. 過去 Step 8 残差解釈の見直し

過去 Step 8-1〜8-12 で「シミュ vs 実機の残差 2.1×」と評価していたが，これは PNG sRGB（ガンマ圧縮）と シミュ sRGB の比較で，PNG 側がガンマでムラを過小評価していた．Step 8-13 で 真の linear ドメイン比較を行った結果 2.63× と判明（TEST_05 §結果比較 参照）．

→ 過去残差 2.1× は楽観的．真の残差 2.63× は LSC モデル化以外の方法で減らす必要がある．

フォールバック条件（再掲） (Fallback Conditions)

TECH_04 §将来 SHADING_OFF 切替のフォールバック条件 で定義した条件：

現状（2026-06-02）の状態: Step 8-13 で残差 2.63× を計測．これは C1 候補（残差は大きく、形は説明可能性が要検討）．SHADING_OFF 撮影の正式検討に進むか，物理モデル見直しに進むかは別途判断．

次のアクション (Next Actions)

LSC 取り扱いは本ドキュメントで決着．残る課題：

短期

• Step 8-13 の正式記録（TEST_01 への Step 8-13 セクション追記）
• handoff_smtias_lightsim/ 一時ディレクトリの削除（S3 完了処理）

中期（残差 2.63× の解消が必要なら）

• 物理モデル精緻化: 反射率 / LED 配光 / メッシュ幾何の各要素を 1 つずつ詰める
• SHADING_OFF 撮影: フォールバック条件 C1 発動として実施．SmTIAS 側で 1 ショット撮影 → 物理 cos⁴ パターンと lscMap の合致度を独立検証

中長期

• 「実機との完全一致」を諦めて 形状指標の相対比較に絞る選択肢（過去 TEST_03 の「形」観点）
• LSC モデル化を「fit」として割り切って追加（overfitting リスク受容．推奨しない）

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

TECH 系（設計判断）

• TECH_01 定量撮影モード要求仕様 — SmTIAS への撮影モード要求
• TECH_02 SmTIAS 引き継ぎ手順 — 引き継ぎパッケージの構造
• TECH_03 定量モード実装報告と SHADING_MODE 相談 — SmTIAS 側からの SHADING_MODE 相談
• TECH_04 SmTIAS への回答 — SHADING_MODE = HIGH_QUALITY 維持判断とフェーズ A/B 分割
• TECH_05 SmTIAS-Evaluation DNG 対応要求仕様 — Evaluation 側への DNG 対応要求（§4 訂正済）
• TECH_06 SmTIAS-Evaluation 引き継ぎ受領 — DNG ローダ受領．LSC 順方向適用が正しいと判明した経緯

TEST 系（試行検証）

• TEST_01 キャリブレーション検証履歴 — Step 8 全イテレーション．Step 8-13 で本方針の数値結果を記録予定
• TEST_03 輝度マップ形状追跡 — 「形のずれ」議論．finding 4 の前提変更を本ドキュメントで明示
• TEST_05 PNG/DNG 評価比較 — LSC 補正なし/あり の数値実証
• TEST_06 外乱光影響評価 — 外乱光がロバスト < 1%（補正残差解析の前提）

外部参考

• Android Camera2 API LensShadingMap
• Android Camera2 API CaptureRequest.SHADING_MODE
• DNG Spec 1.4 OpcodeList2 GainMap