# 技術的実現性・方式選定

調査日：2026-10-27。v0.1.1。理論上の容量、今回の模擬変換実測、実機未確認を区別する。

## 結論

ブラウザー内の非学習型DCT方式で、かな文・暗号・誤り訂正を写真そのものへ格納するプロトタイプは成立する。50〜100文字をスマートフォン画面の約1/3に表示した実機スクリーンショットから復元できるかは未実証。幾何同期（画像範囲の特定）と、画質・埋め込み強度の調整が次の主要課題。

研究で扱う「screen-shooting」はカメラによる画面の撮影を含む。OSのスクリーンショットには通常レンズ歪みやモアレはないが、縮小・拡大、画素位置のずれ、余白、JPEG化は発生する。カメラ撮影への耐性は今回の目標に含めない。

## 方式比較

|方式|長所|課題|今回の扱い|
|---|---|---|---|
|画素LSB|大容量・低負荷・見た目の変化が小さい|再補間・JPEGでビットが崩れる|スクリーンショット用途には採用しない。実装比較は未実施|
|8×8 DCT係数差・低周波|比較的低い周波数を利用、独立ブロックで処理可能|写真本来の勾配が強く、係数を反転すると変化量が増す|実装・実測比較|
|8×8 DCT係数差・中周波|JPEGの高周波除去を避けつつ、写真の勾配との干渉を抑制|強い縮小や位置ずれで損失、平坦写真では模様が見える|実装・実測比較、標準候補|
|画素領域の左右・上下ブロック差|演算が単純、周波数変換不要|ブロック境界や平坦部で模様、再補間で減衰|同じ暗号/ECC/容量を使って実装・比較|
|DWT-DCT|複数解像度の構成に拡張しやすい|同期方式が別途必要、実装と評価が増える|文献比較のみ。次段候補|
|DFT・log-polar同期テンプレート|回転・拡大縮小の推定に応用可能|短いデータ以外に同期の容量も必要|文献比較のみ。自動位置合わせ時に検討|
|学習型（StegaStamp等）|学習した変形に耐えるモデルを構築できる|モデル容量、学習データ、端末負荷、必要データ量の差|既定モデルは100ビット中ECC後の実データ56ビット。今回の92〜136バイトには不足。独自学習は初期版で行わない|

研究成果から本アプリの成功率を推定することはしない。今回のDCT・画素領域方式については、同じデータとチャネル変換で比較した[実測結果](RESULTS.md)に基づいて判断する。

## 容量の理論計算

独自かな符号は1文字7ビット。バイト境界までゼロ埋めする。暗号認証には短い文章でも固定の追加情報が必要。

|項目|50文字|100文字|
|---|---:|---:|
|かな文のビット数|350|700|
|かな文バイト数 ceil(7n/8)|44|88|
|識別・版・文字数|4|4|
|salt|16|16|
|GCM nonce|12|12|
|GCM tag|16|16|
|最小フレーム|92バイト|136バイト|
|v1で実装する固定フレーム|136バイト（44バイトのパディング）|136バイト|
|畳み込み符号後（1088入力ビット+6終端）×2|2188ビット|2188ビット|
|追加反復|756ビット|756ビット|
|既知同期信号|128ビット|128ビット|
|総埋め込み|3072ビット|3072ビット|

512×384の画像には64×48=3072個の8×8ブロックがある。1ブロック1ビットでちょうど収まる。50文字のときも固定136バイトにする初期設計なので、現段階では短文ほど自動的に誤り訂正が強くなるわけではない。短文専用モードの導入は別の物理フレーム版として検討する。

比較として343×257の画像を直接8×8分割すると42×32=1344ビットにとどまり、今回の2188ビットECC本体だけでも収まらない。本実装は512×384の正規化格子を使い、表示やスクリーンショット後にその格子へ戻す。縮小で情報が失われるため、画素数の計算だけで成立を主張しない。

iPhone 13 miniではCSS表示寸法・devicePixelRatio・OSの実際のスクリーンショット寸法を別に記録する。375 CSS pxの画面、343×257 CSS pxの写真（約1/3画面）を仮の表示条件とするが、DPR 3から実機画像寸法を断定しない。

## 次の技術選択

1. 中周波DCT・強度48を初期標準候補とする。受信方式は明示選択。保存前に必ず元PNG相当の認証復号を行う。
2. 写真範囲の手動指定でチャンネル損失と同期失敗を分ける。128ビットのpilotは一致度の検証用であり、現版に自動位置探索はない。
3. 実写真の種類を増やし、画像品質の主観評価と完全復元率を確認する。必要なら強度32へ下げる・短文フレームを追加する。
4. 手動範囲指定の誤差を測り、pilot相関による近傍位置探索、同期テンプレート、DWT-DCTの順に比較する。
5. 目標表示寸法で成功しない場合は、必要な表示サイズ・容量・強度のトレードオフを測って仕様を調整する。

## 参考資料（一次資料）

以下の研究の内容を要約して方式の選択に用いた。コードの転載はない。

- DCT透かしの初期研究：A DCT-domain system for robust image watermarking (1998), <https://doi.org/10.1016/S0165-1684(98)00015-2>。再圧縮・再標本化・幾何変換への耐性を扱う。
- Resampling-Detection-Network-Based Robust Image Watermarking against Scaling and Cutting (2023), <https://doi.org/10.3390/s23198195>, <https://pmc.ncbi.nlm.nih.gov/articles/PMC10575421/>。縮小・切出しによる同期の破壊を課題とし、DWT-DCTとスケール推定を組み合わせる。今回の軽量方式と同一ではない。
- Universal screen-shooting robust image watermarking with channel-attention in DCT domain (2024), <https://doi.org/10.1016/j.eswa.2023.122062>。DCT領域と学習・ノイズ層の組合せ。公開要旨を確認、全文の再現検証は未実施。
- Tancik et al., StegaStamp (CVPR 2020), 著者公式実装 <https://github.com/tancik/StegaStamp>。既定モデルのデータ量と誤り訂正を確認。
- Web Cryptography API（W3C Recommendation 2017）<https://www.w3.org/TR/2017/REC-WebCryptoAPI-20170126/>。AES-GCM・PBKDF2のAPI仕様。
- OWASP Password Storage Cheat Sheet <https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html>。PBKDF2-HMAC-SHA256の600,000回をコストの参考にする。これはパスワード保存指針であり、本ファイル形式の安全性の保証ではない。