私は、画像を大量にサイズを変更する必要があるアプリケーションを書いています...これらは私の要件は次のとおりです。最速C/C++、画像リサイズのライブラリ
これまでのところ、私のオプションは次のとおりです。
これらのすべては、仕事を得るだろうが、私はここに最速を探しています、と私は彼らのパフォーマンス上の任意のベンチマークを見つけることができませんでした。
Intel IPP (Integrated Performance Primitives)（WikiリンクはIntelよりも優れています...）AMDでも動作し、画像のサイズを変更する機能（双線形、最近隣など）があり、LinuxおよびWindowsで動作します。
無料ではありませんが、銀行を破損することはありませんが、その中で最も速く見つけることができます。
イメージがデコードされた場合は、IPPが適しています。ただし、デコードとスケーリングを1ステップで行う方が高速になる可能性があります。 IPPを使って1：1のビットマップを先にデコードせずにサイズを変更する方法はわかりません。 – kcwu
その声明についてちょっと考えてください。単一の（複雑な）ステップでそれを行うのは、それをもっと速くすることでしょうか？画像復号ルーチンは、フィルタルーチンがそれらをフィルタリングするために、依然としてすべての画素を復号する必要がある。たとえそれらが1回のパスでそれを行ったライブラリであったとしても、IPPルーチンのベンチマーキングはIPPとの2パスがおそらくもっと速いことを示しています。 –
おそらく、1回目のパスでそれを実行すると、すでにCPUキャッシュにあるデータを使用できるからです。 – CiNN
あなたが無料のものを探して、かつ迅速な処理をしたい場合は、GimpのC-コンパイルされたプラグインを開発しようとは：これは非常に簡単です、と私はGimpのサイズ変更で良い仕事をして思う：
これは、サイズを変更するのが最速ではないかもしれませんが、最も安い（無料）を開発するのが最も速いです。
thereをご覧ください。
あるいは、Pythonプラグインを介してリサイザを呼び出します。 –
GimpはGUIです。私は、C/C++から使用できるライブラリについての質問だと思う。私はGimpがスクリプトから制御できることを知っていますが、これは高速ではありません。 – guettli
起動に時間がかかるために時間がかかると思うかもしれませんが、Gimpを使用してサイズを変更するのは非常に高速です。メモリにロードしておくと、これは最速ではありませんが、あなた自身でテストすると驚くかもしれません;） –
オープンソースをお探しの場合、FreeImageはどうですか？商用のものについては、私はSnowboundを使用します。両方とも非常に高速であり、多くの異なる画像フォーマットとサイズ変更アルゴリズムが可能です。
FreeImage Public Licenseは、商業利用を妨げません。 – darklon
@クリスベッケさんのコメント：。？
「という声明についてちょっと考えて、単一の（複雑な）ステップでそれを行うのどの部分がどのより速くそれを作るために起こっている画像復号ルーチンはまだする必要がフィルタルーティンでフィルタリングするためにすべてのピクセルをデコードします。
これは必ずしもそうではありません。例えば、JPEGをデコードするときには、JPEGライブラリーに1/2、1/4、1/8サイズのイメージを与えるように頼むことができます。 JPEGの仕組みのために、余分なディテールをまったくデコードする必要はありません。完全なデコード+スケールよりもはるかに高速です。
（もちろんあなたは小さいイメージが希望正確なサイズでない場合は、後でビットを拡張する必要があるかもしれません。）
（申し訳ありませんが、私は唯一の原因なしreputatonにコメントとしてこの回答を投稿することができます。まず、時間を
スケーリングアルゴリズムは、より多くのデータ（より小さい特定の小さなレベルでのみ問題ありません）でより良い結果を得ることができますが、再びすべての異なる圧縮方法（BMP、GIF、PNG、JPEG）特定のバージョン。 –
私はJPEGがこのように最適化できる唯一のフォーマットだと思います。構造化されているため、さまざまなレベルの詳細を完全に解読する前に分離することができます。 –
チャンクで作業することは、デコードと再コードをオーバーラップできることも意味します。例えば、libvips（@bithiveの答えを参照）は、イメージをストリームし、デコード、処理、再コードを並行して実行します。多くの操作では、デコード/コード化はシングルスレッドのレート制限のステップなので、高速化が可能です。 – user894763
IPPがwhat you needの場合（たとえば、12章で関数のサイズ変更）、私は疑問に思っていますが、私はここに何かを投稿しようとしました。どこにいても、はるかに高速なx86コードを見つけることができます。 AMD CPU上で実行すると、遅い "リファレンス実装"に落ちるかもしれないことに注意してください。
CPUがあなたの性能要件を満たしていない場合、OpenGLを使用してGPUにリサイズをプッシュすることをお勧めします（テクスチャマッピングを使用した最も簡単な実装はハードウェアインターポレータの恩恵を受けるでしょう、より複雑なフィルタリングはGLSLシェーダコードを使用します）。 GPUがCPUより数百倍速いこの種の処理を行う能力は、カードとの間の比較的遅いデータ転送（通常、1秒あたり1ギガバイトまたは2ギガバイト）に対して重み付けする必要がありますせいぜい）。
VIPSをご覧ください。これまで私が見つけた最速のものです。
私はVIPSを自分で使っていません。しかし、それは速い（とLGPL）ようです：http://www.vips.ecs.soton.ac.uk/index.php?title=Speed_and_Memory_Use – guettli
大量の（例えば先月のアップロード画像全体のように）画像の量は非常に特殊なアプリケーションのように聞こえるので、なぜクロスプラットフォームが重要であるのか疑問に思っていますか？特定のハードウェアに頼ることができるのであれば、スケーリング部分で非常に速く動くことができるでしょう。すべてのデータを読み書きする方法について真剣に考え始めなければならないでしょう。 – Chris
「私はベンチマークを見つけることができませんでした」：あなたはいつでもベンチでそれらを箱に入れ、あなたの所見をここで共有することができます:-) – lothar
@chrisこれは古い質問ですが、汎用CPUとローカルディスクのサイズ変更はほぼ確実に計算上の問題になります。特定のハードウェアではなく特殊化された（CUDAなど）場合は、IOバインドできるようになります。 – Yaur