このパッケージを知って以来、画像のサイズ変更がどのくらい早く実装されたかを知りたいと思っていました。 ドキュメントには公式のベンチマークやパフォーマンスデータはなく、サードパーティのベンチマークもありません。 私が見つけた最も近いものは、libjpeg-turboプロジェクトのJPEGコーデックベンチマークでした 。
そして、昨日の前日、記事「 Image Resize Methods 」の準備の過程で（さらなる議論を理解するためにこの記事を読むことは非常に望ましいです）、私はもう一度記事に出会いました。
libNthumb、The NHN * Intel IPPライブラリを使用したサムネイルイメージのリアルタイム作成のためのパフォーマンスプリミティブ
この記事は、1行目または2行目の「Intel ipp画像サイズ変更ベンチマーク」のリクエストに応じてGoogleに掲載され、IntelのWebサイトに掲載されています。
この記事では、有名なImageMagickと比較して、特定のlibNthumbライブラリの負荷テストについて説明します。 libNthumbはIntel IPPに基づいており、それを利用していることが強調されます。 どちらのライブラリも、4000×3000の解像度で12メガピクセルのJPEGファイルを読み取り、400×300の解像度でサイズを変更してから、JPEGに保存し直します。 libNthumbライブラリは、2つのモードでテストされます。
libNthumb -JPEG画像はネイティブ解像度で開かれませんが、8倍（つまり、500×375解像度）で縮小されます。 JPEG形式では、元の画像を完全にデコードせずにこれを行うことができます。 その後、画像は必要な解像度400×300にスケーリングされます。
libNthumbIppOnly-イメージは元の解像度で開き、その後、1回のパスで必要な解像度400×300にスケーリングされます。 このモードは、記事で述べられているように、追加の技術的なトリックなしで、Intel IPPの使用とパフォーマンスの違いを正確に強調することを目的としています。 記事自体からの説明図は次のとおりです。
その後、3つのオプションすべて（ImageMagick、libNthumb、libNthumbIppOnly）のパフォーマンス測定の結果が、デコード時間、サイズ変更時間、圧縮時間、および合計操作時間のパラメーターに従って表示されます。 サイズ変更の結果に興味がありました。 引用：
以下の図は、サイズ変更プロセスの平均経過時間を示しています。
ワーカースレッドの数に関係なく、libNthumbはImageMagickよりもパフォーマンスが約400倍向上します。 これは、libNthumbのデコードプロセス中にIDCTスケールファクターによって設定されるデータが小さくなるためです。
グラフからわかるように、どちらの場合もlibNthumbはImageMagickよりも400倍高速です。 この記事の著者は、画像を開くとすぐに8倍縮小されるため、libNthumbが処理する入力データがはるかに少ない（正確には64倍）ことでこれを説明しています。 これはlibNthumbの結果を説明しますが、ImageMagickと同じ入力データのセットを使用するlibNthumbIppOnlyの結果は説明しません 。 フルサイズの画像。 著者は、libNthumbIppOnlyの優れた結果については黙っています。
libNthumb（したがってIntel IPP）とImageMagickでは画像のサイズ変更にまったく異なる方法が使用されているように思えます（実際、私は確信していますが、物語の形式は客観的に書くことを強制します）。 インテルIPPは、アフィン変換メソッド（ここでは画像サイズ変更メソッドを読むためにもう一度お送りします）、元の画像のサイズに対して一定時間動作するメソッド、サイズを2倍以上縮小するのにまったく不適切なメソッド、メソッド、 2倍に減らすと、それほど高品質ではありません。 ImageMagickはコンボリューション法を使用しますが（ここでは絶対に確信しています）、より良い結果が得られますが、より多くの計算が必要です。
私の仮定が正しい場合、これは結果の画像から簡単に理解できます。libNthumbIppOnlyの結果は非常にピクセル化されているはずです。 元の記事には、結果の写真の品質を比較するセクションがあります。 私は完全にそれを与えます：
サムネイル画像には一定の品質が必要です。 libNthumbのサムネイル画像の品質に関しては、ImageMagickとの品質の違いは肉眼では見えません。 以下の画像は、ImageMagickとlibNthumbによってそれぞれ生成されたサムネイル画像です。
ImageMagickによるサムネイル画像
libNthumbによるサムネイル画像
サイズ変更にはさまざまな方法があります。 画質は、使用するフィルターによって異なります。 libNthumbは、それぞれ異なるルックアンドフィールを持つ複数レベルのサイズ変更およびシャープフィルターを介して画像品質を向上させます。
奇跡的に、libNthumbIppOnlyの結果はここにはありません。 さらに、上記の画像は解像度が異なり、両方とも宣言された400×300ピクセルよりも小さくなっています。
私が言ったように、アフィン変換の方法は画像の任意のサイズ変更には完全に不適切であり、それがどこかで使用される場合、これは明らかなバグだと思います。 しかし、これは私の意見であり、インテルがこの特定の方法を実装するライブラリを販売するのを止めることはできません。 私が干渉できるのは、他の開発者を誤解させ、根本的に異なる2つのアルゴリズムの動作の違いを実装の違いとして与えることです。 何かが400倍高速に動作すると主張している場合は、結果が同じであることを確認する必要があります。
私はインテルに対して何もしていませんし、何らかの形でそれを害するという目標を設定していません。 そして、私の観点から、彼女は次のことをすべきです。
1）記事を修正します。 ImageMagickとIPPのパフォーマンスを直接比較できない理由を書いてください。
2）ドキュメントを修正します。 間接符号だけでは2倍以上の縮小には適さないアフィン変換を使用した、ランチョス関数による線形、キュービック、および補間を推測できるようになりました。フィルターの正確なアルゴリズムは、ドキュメントアプリケーションに記載されています 。
3）（非常に素晴らしい）誤解を招く謝罪とともに製品ユーザーに謝罪を送ります。