Newer
Older
SmTIAS-Capture / docs / 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 も全体上書きせず進捗欄だけ二段構成に書き換え.既存進捗エントリは本ファイルへ移植