# 開発進捗ログ

<!--
本ファイルは追記型のフル進捗ログ．

- 最新エントリは下に追記する（時系列順．古いものが上，新しいものが下）
- CLAUDE.md の「開発進捗」セクションは最新 1 行のみ（上書き運用）
- 詳細・失敗パターン・設計判断はすべて本ファイルに残す
- 書式・運用ルールは docs/01_GUIDE/GUIDE_05_エージェント運用ルール.md
  「進捗記録の運用ルール（CLAUDE.md / PROGRESS.md）」を参照
-->

## Step 1〜5: 撮影・保存・一覧・削除の実装

- 状況: 初期バージョンのアプリ（撮影画面 + 一覧画面）が動作する状態に到達
- 動機: TIAS（積分球を用いた大型装置）のスマホ版として研究メンバー向け撮影アプリを立ち上げる．PC 側で解析するため，スマホ側は撮影・保存に特化（PLAN_01 要件定義書参照）

## 撮影→保存の高速化

- 状況: YUV→PNG 変換を Android ネイティブに移行．非圧縮 PNG + 回転統合により 15 秒 → 約 2 秒に短縮
- 動機: Dart の image パッケージで PNG エンコードが遅く撮影フローが詰まっていた
- 設計判断: 非圧縮 PNG（Deflater.NO_COMPRESSION）を選択．圧縮率より速度優先．研究用途で 1 ショット数 MB は許容
- 失敗パターン: 当初 Dart の isolate で並列化を検討したが，Plane バイトの copy オーバーヘッドで思ったほど速くならなかった

## カメラ診断機能の追加（インフラのみ・UI 非表示）

- 状況: `DiagnosticsProvider` / `RawCaptureService.getCameraDiagnostics` / `FileService.saveDiagnosticsJson` を追加．UI ボタンは出さず将来再利用に備えて温存
- 動機: 定量モード撮影を実装する前提として，実機 AQUOS sense3 の Camera2 能力（HW Level・MANUAL_SENSOR/POST_PROCESSING の有無・RAW 出力可否・LSC マップ取得可否）を一度きっちり確認したかった
- 結果: AQUOS sense3 フロントカメラは **HW Level 3 + RAW + MANUAL_SENSOR + MANUAL_POST_PROCESSING** 対応．診断結果 JSON は `docs/06_TEST/camera_diagnostics_20260531_161734.json` に保存
- 失敗パターン: `LENS_INFO_SHADING_MAP_SIZE` は hidden API でビルドエラー．`STATISTICS_INFO_AVAILABLE_LENS_SHADING_MAP_MODES` で代替判定 + 実キャプチャ後に CaptureResult から取得する設計に変更

## 定量モード撮影機能（DNG 経路）完成

- 状況: シャッターで `MiniTIAS_QM_YYYYMMDD_HHmmss.dng`（10-bit BGGR Bayer 3264×2448，約 16MB）と `.meta.json`（settings/actual/sensorCharacteristics/lscMap）を `Pictures/MiniTIAS/` に保存．既存 PNG 経路は `captureFullResolutionPng` として温存
- 動機: SmTIAS-LightSim 側でのシミュ vs 実機の定量比較で残差 2.1× が解消しない問題．原因は MiniTIAS 通常モードが AE/AWB/NR/EDGE/TONEMAP 全自動で撮影ごとに値が揺らいでいたこと（TECH_01 参照）
- 設計判断: Camera2 マニュアル制御で `CONTROL_MODE=OFF` + AE/AWB/AF/NR/EDGE OFF + TONEMAP 線形 + 露光 1/60s 固定 + ISO 40 固定．`SHADING_MODE` は HIGH_QUALITY を採用（LSC マップ実値を取りたいため．OFF だと単位マップしか返らない）．フォーマットは DNG (RAW_SENSOR) を採用（8bit PNG では舌の色再現には情報量不足）
- 失敗パターン: ① MTP コピー直後の DNG が PC で 0 バイトに見える→「MethodChannel 16MB 転送が失敗」と誤診断．実際は MTP コピー遅延で，30 秒待てば全データあった．② `SHADING_MODE = OFF` 初回採用で LSC マップが全 1.0（Android 仕様）→ HIGH_QUALITY に変更で実値取得
- 後段: 露光時間・ISO のキャリブ機能（白板撮影で AE 一回走らせて値を固定する半自動モード），撮影連射再現性検証 V1（CoV < 1%），他機種展開時の `getCameraDiagnostics` 再実行

## テンプレート同期

- 状況: programming-template から進捗記録の二段構成（CLAUDE.md 1 行 + PROGRESS.md 追記ログ）と関連スラッシュコマンド・ガイド更新を取り込み
- 動機: テンプレート側で進捗記録ルールが更新された．CLAUDE.md が毎ターン読み込まれることを考えると履歴を切り離す設計は合理的
- 設計判断: `.gitignore` はテンプレート版（ミニマル）を採用せず Flutter 用エントリを温存．`CLAUDE.md` も全体上書きせず進捗欄だけ二段構成に書き換え．既存進捗エントリは本ファイルへ移植

## DNG プレビュー JPEG 機能を追加

- 状況: 撮影 1 回で `.preview.jpg`（1632×1224，100〜300KB）を `.dng` と並べて保存．一覧画面で表示・拡大できる．削除時は dng / meta.json と連動
- 動機: DNG は Flutter `Image.file` でデコードできずアプリ内で撮影結果を確認できなかった．研究者が「ちゃんと撮れたか」を端末上で判断できるようにする
- 設計判断: 別ファイル方式（案 B）を採用．案 A（DNG 内サムネ）は Dart で TIFF パーサが必要で実装重い．案 C（マルチストリーム + JPEG）は ISP のフルパイプライン処理が混じり研究データの位置付けが曖昧になる．案 B は Kotlin で Bayer→2×2 demosaic→ガンマ 2.2 で JPEG 化するだけのシンプル実装で，DNG 本体は無変更で済む
- 失敗パターン: なし（実機で意図通り動作）
- 既知の課題: プレビューが緑がかる．原因はおそらく WB 未適用（COLOR_CORRECTION_GAINS=identity）と BGGR の G チャネルが 2 サンプル平均で他より重み付けされる効果の組み合わせ．プレビュー画質の話なので DNG 解析には影響しない
- 後段: 緑かぶり改善（グレーワールド WB or AsShotNeutral 反映）．露光時間キャリブ機能．連射再現性検証 V1

## プレビュー JPEG をライブビュー（自動 ISP）スナップショットに切替

- 状況: プレビュー JPEG の生成元を「Kotlin Bayer demosaic」から「`capturePreviewSnapshot` のライブプレビュー YUV→JPEG」に切替．Kotlin プラグインから約 200 行削除．Dart で `FileService.savePreviewJpeg` を追加し，`takePicture(previewBytes:)` でシャッター瞬間のスナップショットを保存
- 動機: 自前で Bayer→グレーワールド AWB→自動レベル→sRGB トーンカーブと再現したが，旧 PNG（フル ISP）の見た目に届かなかった．Camera2 ISP がフル稼働するライブプレビューと同じ絵を使えば一発で一致する．かつコードが大幅にシンプルになる
- 設計判断: ライブプレビューの絵を「研究データには使わない確認用」と割り切る．DNG は引き続きマニュアル制御の RAW．Preview のソースが自動 ISP かマニュアルかは独立に決められる．既存の `capturePreviewSnapshot` は保存中オーバーレイで既に使われていたので新規 API 追加なし
- 失敗パターン: ① 自前 demosaic + ガンマ 2.2 → 緑かぶり ② グレーワールド AWB → 緑かぶり解消だが暗い・フラット ③ 自動レベル + sRGB トーンカーブ → さらに改善も自動 ISP に届かない → ライブビュースナップショットを直接使う方針に転換．結果コード ~200 行削減 + ライブビュー完全一致
- 後段: 解像度がプレビュー由来（おそらく 1280×720）になるが研究用途では十分．画素統計 meta 追加，hot pixel マップ，連射機能 V1 検証