画像サーバーは、画像の配信(多くの場合、画像の修正)に特化したWebサーバーソフトウェアです。ただし、すべての画像サーバーがHTTPをサポートしているわけではなく、Webサイトで使用できるわけでもありません。
従来のウェブサーバーは、クライアントに画像ファイルの静的コピーを提供するのが一般的ですが、画像サーバーは通常、ファイルを提供する前に追加の画像処理を行います。これらの機能には、フレーム/フォーマットの選択、サイズ変更、切り抜き、アルファブレンディング、ソース画像の合成、回転、色調整、フィルタリングなどが含まれます。
画像サーバーの主な用途は、ブラウザベースのパン&ズームビューアをサポートすることです。[ 1 ]ポート/1188
概念
単一光源イメージング
モバイルデバイスの普及、画面解像度、ピクセル密度の高低により、Webデザイナーはますます多くの画像バリエーションの作成を迫られています。動的な画像サイズ変更機能を備えた画像サーバーは、必要なサイズとバリエーションをオンデマンドで作成できるため、反復作業や人的ミスの発生を防ぎます。
宣言文と命令文
宣言型API(RIAPIなど)を使用すると、クライアントは画像のサイズ、アスペクト比、回転、フィットモードなど、最終的な特性を記述できます。コマンドの順序は重要ではありません。?width=200&height=100 と ?height=100&width=200 は同じ結果になります。サーバーは、互換性のある操作を自由に統合してパフォーマンスを向上させることができます。
命令型API ( IIPやIIIFなど) は、画像に適用する操作を順番に記述し、ユーザーにより多くの制御を提供しますが、計算に対する責任も大きくなります。
用途
動的なタイルベースの配信
高解像度画像用のブラウザベースのビューアは、高解像度のソースから生成された小さなタイル(通常は256x256または512x512ピクセルの正方形のJPEGまたはPNG)を要求することで、レスポンシブなパンとズーム体験を可能にします。ユーザーの現在のビューポートとズームレベルをレンダリングするために必要なタイルのみが読み込まれ、ユーザーが特定の領域にズームインすると、オンデマンドで追加のタイルが要求されます。このタイル生成は事前に実行でき、サーバーファイルシステムに画像ピラミッドとして保存できます。[ 2 ]ただし、これにより、関連するストレージと管理のオーバーヘッドを伴う、数千の小さなJPEGファイルが発生する可能性があります。画像サーバーは、タイルに対するHTTPリクエストに動的に応答し、HTTPレスポンス(タイル画像)をオンザフライで生成します。サーバーに必要なのは、単一の高解像度ソース画像だけです。[ 3 ]
電子商取引
最もシンプルな商品ビューアでは通常、少なくとも3つのバージョンの画像が必要です。100×100のサムネイル、400×300の中サイズのページ内選択バージョン、そして1200×900の拡大バージョンです。元のファイルと合わせると、4つの別々の画像が作成され、それぞれを保存、更新、リンクする必要があります。
電子商取引では、画像サーバーは、数十万枚の画像、複数のCPUまたは負荷分散されたサーバーマシンに拡張できる能力、サイズ変更、合成、ズーム、3D ビューアなどの画像処理機能の量と品質、オーバーレイされたテキストやグラフィックスの形式で画像に動的データを追加する能力によって評価されます。
ダイナミックコンポジットは、製品のカスタマイズを許可する販売者にとっても非常に便利です。多くの自動車メーカーは、訪問者にカスタマイズ内容を視覚的に確認してもらうためにダイナミックコンポジットを使用しています。
大規模な画像セット、マッピング、地理空間の利用
地理空間や地図作成には、専用の「画像サーバー」が特に必要です。航空写真や衛星画像は地理参照されており、数百ギガバイトから数千ギガバイトにも及ぶことがあります。こうしたデータを提供する従来のメカニズムでは、対応しきれないことが分かっています。地理空間画像データに特化した最初の画像サーバーは、1999年にリリースされたImage Web Serverです。Image Web Serverは、他のプロトコルの中でも、 HTTP経由で通常の画像を送信するのではなく、大容量画像をユーザーのアプリケーションに「ストリーミング」するECWP(ERDAS Compressed Wavelet Protocol)をサポートしています。地理空間データの分散アーキテクチャの標準的な規格として、Web Map Serviceがよく知られています。
レスポンシブウェブデザインとモバイルサポート
レスポンシブ Web デザインにより、デバイスや解像度の検出を統合した新しい画像サーバーが数多く作成されました。
再サンプリングによるアーティファクトを防ぐには、画像がネイティブ解像度(デバイスの表示ピクセルごとに 1 つの画像ピクセル)で表示されることが重要です。
これを実現するには、画面解像度ごとに多数のバリエーションを作成する必要があります。画像サーバーは、ユーザーのブラウザ設定に応じて画像のサイズを動的に調整することで、この問題を解決します。
下位互換性
Internet Explorerの古いバージョンではPNGおよびMNG画像を表示できませんが、画像サーバーがユーザーのブラウザ バージョンを検出し、代わりにGIFなどのサポートされている形式で画像を送信できます。
画像サーバーにより、すべてのブラウザがサポートを実装する前に、早期導入者がWebP の使用を開始できるようになる可能性があります。
ベンチマーク
2024年のベンチマークでは、imgproxy(Goでlibvipsを使って記述)が複数のファイルタイプにわたって最速のサーバーであり、thumbor(PythonでPillowを使って記述)とimagor(Goで記述)が遅れていることが判明しました。[ 4 ]
規格と仕様
- RESTful Image API (RIAPI) - 2012 - シンプルで宣言的なクエリ文字列ベースの画像APIのドラフト仕様。[ 5 ]ブラウザ互換。
- インターネットイメージングプロトコル(IIP) - 1997 - (オプション) 画像編集用のHTTPベースの命令型プロトコル。FlashPixファイル形式と密接に関連しています。国際画像産業協会 (IIP)によって策定されました。
- ECWP (ERDAS 圧縮ウェーブレット プロトコル)
- ウェブマップサービス
参照
参考文献
- ^ Agüera y Arcas, Blaise (2007年5月27日). 「PhotoSynthが世界の画像をどのように繋げるか」 . 2015年3月8日閲覧。
- ^ガシエニカ、ダニエル. 「Inside Deep Zoom」 . gasi.ch/ . 2015年3月8日閲覧。
- ^ 「IIPImageについて」 . iipimage.sourceforge.net/ . 2015年3月8日閲覧。
- ^ 「画像処理サーバーのベンチマーク | imgproxy Blog」 . imgproxy.net . 2024年4月2日. 2025年9月14日閲覧。
- ^ RESTful 画像 API