スライド写真の歪みを直す — perspective-corrector の単一責務設計

学会・社内会議・講演 ── プレゼンテーションが行われる場面でスライドを撮影しようとすると、ほぼ必ず 台形に歪んだ写真 が得られます。会場後方から斜めにスマートフォンを構えれば、矩形のスクリーンは台形として撮像される ── 物理的に避けようがない歪みです。

この歪みを補正するという、ありふれた、けれども細部に判断が要求される問題に対する一つの実装が、本サイトの既掲記事 記録を標準化する で扱った 4 ツールの一つ perspective-corrector² です。本稿はその設計判断を一つずつはっきり言葉にし、本サイトの既掲記事 ツールとオーケストレーターを分ける で論じた 単一責務 という設計原則の具体例として扱ってみます。

設計判断 1 ── 単一責務に留める

最初の判断は「何をしないか」でした。スライド写真の補正と隣接する機能は多数あります。

• OCR (画像から文字を抽出する)
• 文書スキャン全般 (名刺、領収書、ホワイトボード)
• ファイル整理 (タグ付け、検索)
• クラウド同期
• 自動色補正の高度化 (HDR、明るさ自動調整)

商用アプリ (Office Lens、CamScanner、Adobe Scan) はこれらを統合した「文書スキャンスイート」として設計されており、結果として どの機能も中途半端 になりやすい構造を抱えるといえるでしょう。

perspective-corrector は逆方向の判断を取りました ── 台形補正のみに責務を閉じ、それ以外は一切持たない。新しい機能の要望が出るたびに、その機能を入れたら何が困るか、入れなかったら何が困るか、を Doug McIlroy の単一責務命題³ で問い直します。OCR は別ツールに任せる、ファイル整理は OS のファイラーに任せる、クラウド同期は Dropbox / iCloud に任せる、と決めると、本ツールが扱う対象は 歪みのある画像 → 歪みのない画像 という、入出力で 1 行で記述できる責務に閉じます。

この判断により、ツールとしての複雑性は最小化され、本サイトの既掲記事 偉大なプログラマは優秀なプログラマのコードを利用する で論じた再利用の原則 ── 既存の優秀なツールに任せられるものは任せる ── がそのまま実装に反映される構造になります。

設計判断 2 ── 入力形式は HEIC ネイティブ対応

iPhone で撮影した画像は標準で HEIC 形式 で保存されます。多くのデスクトップツールは JPEG / PNG しか受け付けず、ユーザは事前に変換を要求されます。この変換の手順は、

1. 余計な手作業
2. 画質劣化 (HEIC → JPEG)
3. ストレージ二重化

という三つの摩擦を生み、結果として「歪みを直すこと」より「形式を揃えること」に手間が割かれてしまうといえるでしょう。

perspective-corrector は pillow-heif を依存に加えて HEIC を直接読み込めるよう設計しました ── 撮影直後の iPhone 画像をそのままドラッグ&ドロップして補正に進める、という流れを保証します。これは「入力形式の摩擦を削る」という小さな判断ですが、ユーザの認知負荷を 1 段下げる効果は大きい、と整理することができます。

設計判断 3 ── 出力は可逆圧縮 PNG と 300dpi A4 PDF

出力形式の選定は二つに分けて整理できます。

個別画像出力 ── 1920×1080 PNG (可逆圧縮):

• スライドのアスペクト比は 16:9 が事実上の標準
• 1920×1080 は Web 表示・スライド再構成・記録閲覧のいずれにも十分な解像度
• 可逆圧縮 にすることで、後段で再加工 (色調補正、注釈、抽出) しても劣化しない
• JPEG ではなく PNG を選ぶ理由は、テキストを多く含むスライドでは JPEG の DCT 方式の圧縮がブロックノイズを発生させ、文字の可読性を損なうため

集約出力 ── 300dpi A4 横 PDF:

• 300dpi は印刷品質の基準値、複数のスライドを A4 に並べた印刷物として機能する解像度
• A4 横は会議資料・配布物として汎用、海外含めた可搬性も高い
• 複数ページの PDF として 1 ファイルにまとめられる ── 後段の閲覧・配布で ファイル管理の認知負荷が下がる

両形式が同時に出力されることで、ユーザは「画像として再利用したい」「印刷・配布したい」のどちらの用途にもそのまま対応できる構造になっています。

設計判断 4 ── 自動検出と手動微調整の二段構え

歪み補正の核心は「スライドの 4 隅の正確な位置」を特定することです。完全自動化は理想ですが、現実には次の場面で破綻します。

• スライドの境界が壁紙や暗幕に溶け込んでいる場合
• 反射やプロジェクターの光漏れで境界が曖昧な場合
• 撮影者の手前に他の聴衆や物体が入り込んでいる場合

perspective-corrector の判断は、自動検出をまず試み、外れた場合に手動微調整に切り替えられる画面を用意する という二段構えです⁴。

• 自動: Canny エッジ検出 + 輪郭近似で 4 隅の座標を推定
• 手動: クリックで 4 隅を指定、ドラッグで微調整
• 拡大鏡: マウス位置周辺を拡大表示し、1px 単位の精密な位置決めを可能にする

完全自動化を諦めて手動の選択肢を残した、というより、自動と手動の組合せが現実の使用条件に最もよく適応する という判断だといえるでしょう。実使用の摩擦を最小化するための設計判断です。

設計判断 5 ── バッチ処理を一級市民にする

会議でスライドを撮影する場合、1 セッションで撮る枚数は 30–60 枚 に達します。1 枚ずつ補正する設計では実用に耐えません。

perspective-corrector はバッチ処理を中核機能として実装しました。

• フォルダを開くと、その中の画像が一覧表示される
• 1 枚ずつ 4 隅を指定 (自動 + 手動微調整) する
• 「一括処理」ボタンで全画像を補正実行、PNG / PDF を一気に出力

「個別処理の自然な拡張としてバッチ処理を提供する」のではなく、最初からバッチ処理が前提の画面 として設計されたのが特徴です。

設計判断 6 ── プラットフォーム横断のバイナリを配布する

配布経路の判断は、対象ユーザの技術的な習熟度の分布に依存します。

• pip からのインストールのみ → 開発者向け、技術的ハードルあり
• スタンドアロン・バイナリ配布 → 一般ユーザ、ハードル低い

perspective-corrector の対象は、技術的背景を持たない研究者・教員・受講者を含みます。pip だけでは届かない層が想定されたため、PyInstaller によるスタンドアロン・バイナリ配布を採用しました。

• macOS: DMG ファイル (Apple Silicon / Intel)
• Windows: EXE ファイル (32-bit / 64-bit)

ffmpeg / ffprobe を含む依存物はすべてバイナリに同梱され、追加インストールは不要です。pip 版も並行提供されており、開発者は通常の Python パッケージとして扱えます ── 配布経路を二系統に切ることで、ユーザ層に応じた経路選択ができる構造です。

設計判断 7 ── プロジェクター投影の色補正

会議で撮影されるスライド写真には、プロジェクター投影特有の 色かぶり が発生します ── 暖色系のフィラメントランプは黄色、LED は青みがかった、それぞれの光源特性が画像に乗ります。

perspective-corrector はこれを後処理として補正する機能を提供します。

• ホワイトバランス自動補正 (色温度推定)
• コントラスト・明るさ・彩度の手動調整

色補正を「歪み補正と同時に行う」ことで、ユーザは別ツール (Photoshop / GIMP) を立ち上げずに済みます。これは前節の単一責務原則とトレードオフの関係にありますが、「会議スライド撮影」という分野に特化した補正として範囲を切ることで 単一責務の枠内に収めています ── 汎用色補正ツールに発展させない、という境界線です。

---

ここから少し、perspective-corrector を本サイトの既掲記事との接続で読み直してみたいと思います。

本ツールの設計判断は、本サイトで論じてきた複数の主張の 具体例 だといえるでしょう。

• 決定論的にではなく、相対的に で宣言した態度 ── 「正解の手順」を固定せず、状況に応じて意味を確認しなおす ── が画像補正という分野で現れる。完全自動化を諦めて「自動検出 + 手動微調整」の二段構えにしたのは、スライドの 4 隅の正しい位置が撮影条件 (壁紙との同化、反射、聴衆の映り込み) に対して相対的であり、決定論的に正解を出すアルゴリズムが存在しないことを認めた判断である。自動検出 (検証) でまず差異を詰め、人間が「これで本当に正しい 4 隅か」を確認しなおす (妥当性確認) ── 検証と妥当性確認の非対称性が、画面の設計に直接現れている¹
• ツールとオーケストレーターを分ける で論じた 単一責務の徹底 ── perspective-corrector は「歪みのある画像 → 歪みのない画像」という入出力に責務を閉じ、OCR・文書スキャンスイート・クラウド同期といった隣接機能には踏み出さない。これにより、media-scribe-workflow などのオーケストレーター層から 置換可能な部品 として組み込める構造になっている
• 偉大なプログラマは優秀なプログラマのコードを利用する で論じた 書かない設計 ── 自動 4 隅検出は OpenCV が提供する Canny エッジ + 輪郭近似に乗り、HEIC 対応は pillow-heif に乗り、バイナリ配布は PyInstaller に乗る。本ツール固有のコードは、これらを 接続し、画面上で操作可能にする 接続部のみ
• 記録を標準化する で論じた 段階間の取り決め ── 出力は PNG (画像処理の標準) と PDF/A 互換 PDF (長期保存の ISO 規格) という標準形式を採用。後段の media-scribe-workflow や任意の文書ツールが、形式に依存せず受け取れる構造になっている

設計判断それぞれは小さく見えますが、累積すると 「会議スライドを補正する」という具体課題に対する、UNIX 哲学に基づいた一つの答え が形作られている、と整理することができるでしょう。

オンライン講座の文脈では、こうした 個別判断の連鎖 を辿ることが教材的価値になります。「Canny エッジ検出の使い方」を教えるのではなく、「Canny で自動検出を試みつつ手動微調整を残す、という判断をなぜ取ったか」を辿る ── 後者の方が、別の問題に立ち向かう際の 設計判断の型 として転移可能だといえるでしょう。

参考文献