さまざまな解像度を作成するために、必要に応じていくつかの画像のサイズを変更 (およびシャープ化と回転) する必要があります。私は小さな開発用コンピューター (Ivy Celeron @ 2.6GHz) を持っています。私の小さなテスト写真は、かわいい子猫の写真の 64 メガピクセル (解像度) と 4 メガピクセルのバージョンを取り込み、両方のバージョンを 750 x 400 (ターゲット サイズ) に縮小します。
1 つのバージョンは JavaIO + ImgScalrを使用し、もう 1 つのバージョンはGraphics Magick + im4javaを使用します。
4 メガピクセルのバージョンでは、ネイティブ JavaIO + scalr を使用すると画像あたり 270 ミリ秒かかり、GraphicsMagick を使用すると 360 ミリ秒かかります。64 メガピクセルの画像のサイズ変更には、JavaIO + scalr を使用すると 3100 ミリ秒かかり、GraphicsMagick を使用すると 4300 ミリ秒かかります。
ここで何か不足していますか？ほとんどの時間は、ファイルを開いて読み取り、結果を保存するのに費やされますが、GraphicsMagick を使用するとスケーリングも大幅に遅くなります。それらはいくつかのより高度なアルゴリズムのユーザーに関連していることを理解していますが、最終的には両方のバージョンで結果が非常によく見えますが、2013 年のコンピューターが 1 秒あたり少なくとも 1000 枚の画像を処理できないとは思いませんでした。 1 秒間に 3 ～ 3 枚の写真。
そこで問題は、私は何を間違っているのでしょうか? 画像のサイズ変更の手段は何ですか？1秒間に10枚の写真を処理するためにサーバー全体が本当に必要ですか?
** アップデート **：
いくつかの計算を行う: 64M / 3 秒 = 20M/秒 / 2.6GHz = 10Mio/GHz = 1 ピクセル/100 クロック サイクル。だから、それはほとんど大丈夫だと思われます。4M の場合: 3M /.3sec = 9M/sec = 1pix/200 サイクル。
ここで更新された質問があります: 画像を高速に読み込むためにメモリを犠牲にする可能性のあるフォーマットはありますか? SSD は遅いため (64M*3 = 192MB、4M*3 = 12MB)、読み込みに 1 秒ほどかかるロー/ビットマップが最適です。しかし、その間に何かがありますか？品質の低い JPEG を使用することは、解凍を高速化しないように縫い合わせられているため、取引になるとは思えません。
カラーチャンネルが分離された圧縮されたビットマップでしょうか？（笑うな！：-））。多分他のいくつか。ZIPはどのくらい速かったですか？
また、いくつかの解決策 (1 回のペナルティ) を提供し、利用可能な最も近い解決策のバージョンを使用することも考えられます。1M の解像度はメモリ内で 4M になり、1 秒あたり 12 回の画像変換が行われるはずです (argh)。私は少なくとも 1000/秒を見込む準備ができていましたが、過去 10 年間でコンピュータの処理能力が大幅に向上することはありませんでした。2 つ以上のワーカー スレッドを使用して、これを並行して開始しようとします。これが2倍になるかどうか見てみましょう。