1

imageresing.net コミュニティと開発者。

imageresing.netの内部に関する詳細を教えてください。

  1. imageresing.net は .NET Drawing ライブラリを使用して jpeg を再圧縮しますか? そうでない場合 - サードパーティのエンジンまたは内部アルゴリズムを使用していますか?

  2. パフォーマンスのベンチマークはありますか? imageresing.net を libjpeg、Intel Integrated Performance Primitives などの他のライブラリと比較したいと思います。

前もって感謝します、

アントン

4

1 に答える 1

7

ImageResizer は 3 つのイメージング パイプラインを提供します。

  1. GDI+ (System.Drawing) デフォルト。プリスムージング付きの 2 パス高品質バイキュービック。提供される品質に対して非常に高速です。(サイズ変更の場合、平均 200 ～ 300 ミリ秒。) 最近の Windows の更新により、GDI+ の並列化が不十分になりますが、これは MSFT によって積極的に調査されています。
  2. WIC (WPF も使用するもの)。4 ～ 8 倍高速 (サイズ変更の場合は 20 ～ 200 ミリ秒)。シングル パスのサイズ変更では、多くのモアレ アーティファクトが発生し、ぼやけが発生します (Fant モードと Bicubic モードの両方で)。Windows Imaging Components 内では、高品質のサイズ変更は利用できません。
  3. フリー画像。DSLR 形式をサポートしたり、Lanczos リサンプリング (最高品質) にアクセスしたりする必要がある場合は、FreeImage がライブラリです。他のものよりも遅く (多くの場合 800 ～ 2400 ミリ秒)、サイズが大きく、モノリシックで、監査が難しいため、信頼できる画像データでのみ使用することをお勧めします。libjpeg-turbo に対してビルドされた FreeImage のカスタム バージョンを使用します。これは、libjpeg よりも大幅に高速です。

エンコーダー、デコーダー、および (ある程度) サイズ変更アルゴリズムを組み合わせて使用​​できます。一部のアルゴリズムは品質上の理由から内部的に実装されていますが、ほとんどは依存関係で C/C++ に実装されています。

りんごとりんごを比較することは決してできないため、写真の品質に関心がある場合、エンドツーエンドの比較ベンチマークは一種のばかげたものです。2011 年に GDI+ と WIC の間でいくつかのベンチマークを行いましたが、写真家やグラフィック デザイナーは WIC の画像品質を受け入れられないと考える傾向があるため、特に公平ではありません。

各パイプラインを定期的にベンチマークして、パフォーマンスの改善や低下を検出していますが、パイプラインを比較すると、さまざまな理由で誤解を招く可能性があります。

  1. メタデータを気にしますか? libjpeg-turbo は、メタデータの解析を無効にすると、jpeg の読み取りが (奇妙なことに) 2 ～ 3 倍高速になります。カメラの Exif データに基づいて自動回転する場合は、その情報が必要になります。
  2. 色の正確さを気にしますか？JPEG は RGB 形式ではありません。ICC プロファイルがある場合は、サイズを変更する前に sRGB に変換するのが正しい方法です。それは遅いです。
  3. サイズ変更の品質を気にしますか？バイキュービック サイズ変更フィルターを実装する方法は 100 通りあります。速いものもあれば、遅いものもあれば、最も醜いものもあれば、正確なものもあります。バイキュービック WIC != バイキュービック GDI+。最近接モードでは、ImageResizer WIC から 20 ミリ秒未満のエンド ツー エンドを取得できます (視覚的な結果に満足している場合)。
  4. 出力ファイルのサイズを気にしますか? より多くのクロック サイクルを費やす意思がある場合は、PNG/GIF ファイル サイズを 30 ～ 80%、jpeg で 5 ～ 15% 削減できます。リクエストごとに 150 ～ 600 ミリ秒を追加したい場合、ImageResizer は帯域幅コストを半分にする WebP 画像を作成できます (WebP は jpeg よりもエンコードにコストがかかります)。

マイクロベンチマークを理解することができます (同じ状況下で、libjpeg-turbo は libjpeg よりも 40% 高速であるなど)。エンコード、デコード、および色変換を除外した後、特定の単純な低品質の画像サイズ変更フィルター (最近隣、ボックス、バイリニア) を比較することもできます。

問題は、真に高品質のサイズ変更は非常に複雑であり、同じ方法で 2 回実装されることはないということです。高品質の実装はほとんどなく、1 秒未満のパフォーマンスを発揮する実装はさらに少数です。参照実装を見つけることができるかどうかを確認するために、画像処理に関する多数の教科書を注文しましたが、このトピックは... ほとんどの人が巧妙に避けており、他の人は簡単に触れているだけです. エッジ ピクセルの処理、事前フィルタリング、およびパフォーマンスの最適化については言及されていません。

私は高速で高品質の画像サイズ変更に関する多くの研究に資金を提供してきましたが、まだ GDI+ に匹敵することはできていません。ImageResizer のデフォルト設定は、多くの種類の画像で Photoshop の品質を上回る傾向があります。

カスタムのサイズ変更アルゴリズムを備えた libgd のフォークに基づいて、近い将来、4 つ目のパイプラインが ImageResizer に追加される可能性があります。まだ確約はできませんが、 GDI+ とほぼ同じくらい高品質で、シングルスレッド (ただし同時実行) のパフォーマンスが向上する可能性があります。

すべてのソース コードは GitHub にあるため、プラグインまたは代替パイプラインとしてデモを行いたい高速なものを見つけた場合は、ぜひお知らせください。

于 2013-10-28T19:30:08.663 に答える