画像を「きれいにしたい」と言っても、実際には問題の種類が異なります。
- ぼやけて輪郭が甘い
- 画像サイズが小さく、表示や印刷に必要なピクセル数が足りない
- 古い写真に傷、退色、ノイズなどの劣化がある
この3つを同じ処理に投げると、必要のない拡大をしたり、傷まで大きくしたり、逆に解像度だけ増えて見た目が改善しないことがあります。
この記事では、画像処理の前段で「何を直したいのか」を分類し、Enhance / Upscale / Restore をどう使い分けるかを、Webアプリ側のルーティングという観点から整理します。
※記事後半では、筆者が運営する EnhancePhoto.org を実装例として扱います。特定サービスの宣伝ではなく、処理経路を分ける設計例として記載します。
1. 最初に「症状」と「目的」を分ける
画像処理のUIを作るとき、モデル名から選ばせるよりも、ユーザーが見ている症状から入口を分ける方が判断しやすくなります。
| 見えている問題 | 本質 | 第一候補 | 処理後に確認すること |
|---|---|---|---|
| 輪郭が甘い、少しぼやけている | 見かけのディテール不足 | Enhance | 顔・輪郭・細線が不自然になっていないか |
| 幅・高さのピクセル数が足りない | 解像度不足 | Upscale | 最終表示サイズで十分なピクセルがあるか |
| 傷、退色、経年ノイズがある | 画像の損傷・劣化 | Restore | 修復部分が原写真の内容を変えていないか |
| 小さく、かつ古く傷んでいる | 複数問題 | Restore → 必要なら Upscale | まず損傷を直し、その後サイズを確認 |
ポイントは、Upscale は「ピクセル数を増やす」処理であって、すべての画質問題を解く処理ではないことです。
たとえば傷のある古写真をそのまま拡大すると、傷やノイズも大きく見える場合があります。逆に、十分な解像度がある写真をむやみに4倍へ拡大しても、利用目的によっては処理コストだけ増えることがあります。
2. 判断フローをコードにするとシンプルになる
フロントエンド側では、モデル名ではなく「ユーザーの目的」を入力として処理経路を決められます。
type PhotoIssue = {
hasPhysicalDamage: boolean;
needsMorePixels: boolean;
looksSoftOrBlurry: boolean;
};
type Route = "restore" | "upscale" | "enhance" | "review";
function choosePhotoRoute(issue: PhotoIssue): Route {
if (issue.hasPhysicalDamage) return "restore";
if (issue.needsMorePixels) return "upscale";
if (issue.looksSoftOrBlurry) return "enhance";
return "review";
}
実際のプロダクトでは、これを自動判定にする必要はありません。最初は3問程度で分岐させるだけでも十分です。
- 古い写真で、傷や退色がありますか？
- 最終的にもっと大きな画像が必要ですか？
- サイズよりも、ぼやけや見え方を改善したいですか？
3. 「低解像度かどうか」は出力先から逆算する
画像が小さいかどうかは、元画像だけを見ても決まりません。どこで使うかで決まります。
印刷なら、必要なピクセル数は概算できます。
print_width_inch = image_width_px / target_ppi
1200px幅の画像を300ppiで印刷する場合は、約4インチ幅です。
Webでも同じで、640px幅の画像を1200px幅のヒーロー画像として使いたいなら、問題は「ぼやけ」だけではなく、出力サイズに対するピクセル不足です。この場合は Enhance だけでなく Upscale を検討する理由があります。
4. 古い写真は「解像度」より先に損傷を見る
古写真では、傷、退色、スキャン由来のノイズ、柔らかくなった輪郭、元データ自体の小ささが混在しやすいです。
最初から「4倍にする」と決めるのではなく、まず損傷を修復する経路に入れ、修復後の画像が最終用途に必要なサイズを満たすか確認します。
damage restoration
↓
visual review
↓
resolution check
↓
upscale only if needed
5. ローカル処理とAI処理も分けておく
Webアプリでは「何を直すか」だけでなく、「どこで処理するか」もUXに影響します。
軽い補正をブラウザ内で完結できる場合は、ファイルを外部へ送らず結果の方向性を確認できます。一方、超解像や復元のような処理は、モデル推論を行うサーバーやプロバイダー側の処理が必要になることがあります。
そのため、UI上では次のような段階を分けて見せると理解しやすくなります。
Local preview
↓
Need stronger processing?
├─ No → export locally
└─ Yes → AI processing route
6. 実装例：EnhancePhoto.org では入口を分けた
EnhancePhoto.org では、現在のUIを問題別に分けています。
Quick / Standard Enhance
ホームでは、軽いプレビューをブラウザ内で試せる Quick Enhance と、2×のAI処理を行う Standard を分けています。
Quick はローカル処理で0 credits。Standard は Real-ESRGAN を使う2×処理で2 creditsです。
Image Upscaler
単純に「もっと大きな画像が必要」という問題には、Image Upscaler を分けています。
現在は2× / 4×を選択でき、元画像のアスペクト比を維持します。
Photo Restoration
傷、退色、ノイズ、古いスキャンなどは、Photo Restoration へ分けています。
「古いから拡大する」のではなく、「損傷があるから修復する」という入口にしているのがポイントです。
7. 3つのケースで考える
ケースA：ECの商品画像が小さい
- 商品自体は壊れていない
- 色や輪郭も大きな問題はない
- 掲載枠に対してピクセル数が足りない
→ Upscale
確認対象は、ロゴ、ラベル、縫い目などの細部です。サイズだけ増えて文字や輪郭が崩れていないかを最終表示サイズで確認します。
ケースB：スマホ写真が少しぼやけている
- ピクセル数は足りている
- 傷や退色はない
- 輪郭や細部だけが弱い
→ Enhance
元画像と処理後を並べ、顔や細線に不自然な変化がないか確認します。
ケースC：古い家族写真を保存・共有したい
- 傷や退色がある
- ノイズが目立つ
- スキャンサイズも小さい可能性がある
→ Restore → 必要なら Upscale
損傷と解像度不足を別問題として扱います。
8. 処理後のチェックリスト
AI画像処理では、「処理が完了した」だけでは成功とは言えません。
- 顔の特徴が不自然に変化していない
- 文字やUIの細線が崩れていない
- 修復結果に元にない形が強く追加されていない
- 商品写真ならラベルや形状が維持されている
- 最終表示・印刷サイズで必要な解像度を満たしている
- 元画像を残し、Before / After を比較できる
このチェックリストは特定のモデルに依存せず、モデルを変更したときにも同じ評価軸として使えます。
まとめ
画像の「画質が悪い」を1種類の問題として扱うと、処理選択を誤りやすくなります。
傷・退色がある？ → Restore
必要なピクセルが足りない？ → Upscale
輪郭・見え方が弱い？ → Enhance
どれでもない？ → 原画像と用途を再確認
モデルを選ぶ前に、入力画像の問題と最終用途を定義する。この一段を入れることで、Web上の画像処理ツールも、単なる「AIボタン」ではなく、ユーザーが判断できるワークフローとして設計しやすくなります。