ブラウザで画像のサイズを変更します。 すべてがとても悪い

ブラウザーで画像のサイズを変更するタスクに直面したことがあるなら、おそらくそれが非常に簡単であることを知っているでしょう。 最新のブラウザには、キャンバス（ <canvas> ）などの要素があります。 画像を希望のサイズに適用できます。 5行のコードと画像の準備ができました：

 function resize(img, w, h) { var canvas = document.createElement('canvas'); canvas.width = w; canvas.height = h; canvas.getContext('2d').drawImage(img, 0, 0, w, h); return canvas; } 

キャンバスから、画像をJPEGで保存し、たとえばサーバーに送信できます。 この記事を終了することはできましたが、最初に結果を見てみましょう。 そのようなキャンバスをその隣に配置し、同じ画像がロードされる通常の<img>要素（ source 、4 MB）を配置すると、違いがわかります。



何らかの理由で、デスクトップとモバイルの両方の最新のブラウザーはすべて、アフィン変換の安価な方法を使用してキャンバスに描画します。 画像のサイズ変更方法の違いは、 対応する記事で既に説明しました。 アフィン変換の方法の本質を思い出させてください。 その中で、最終画像の各ポイントを計算するために、ソースの4ポイントが補間されます。 これは、画像が2倍以上縮小されると、元の画像に穴が形成されることを意味します。最終的な画像ではまったく考慮されないピクセルです。 品質が低下するのは、これらの説明されていないピクセルのためです。

もちろん、この形式の写真は、まともな人には見せられません。 当然のことながら、キャンバスを使用した品質のサイズ変更の問題は、stackoverflowでよく尋ねられます。 最も一般的なヒントは、数ステップで画像を縮小することです。 確かに、 強力な画像縮小がすべてのピクセルをキャプチャしない場合、画像をわずかに縮小しないのはなぜですか 。 そして、目的のサイズになるまで何度も繰り返します。 この例のように 。

間違いなく、元の画像のすべてのポイントがファイナルで考慮されるため、この方法ははるかに優れた結果をもたらします。 別の質問は、それらがどのように正確に考慮されるかです。 既にステップサイズ、初期サイズ、最終画像のサイズに依存しています。 たとえば、ステップサイズを正確に2にすると、これらの削減はスーパーサンプリングと同等になります。 そして、ここが最後のステップです-なんて幸運か。 完全に幸運な場合、最後のステップも2になります。しかし、最後のステップで画像を1ピクセル縮小する必要があり、画像が石鹸のようになる場合は、まったく幸運ではありません。 比較すると、サイズの違いは1ピクセルのみで、違いは何ですか（ ソース 、4 MB）：



しかし、おそらくあなたは完全に異なる方法を試してみるべきですか？ ピクセルを取得するキャンバスがあり、サイズ変更のタスクに簡単に対応できる超高速のJavaScriptがあります。 したがって、ブラウザのサポートに依存することなく、任意のサイズ変更メソッドを自分で実装できます。 たとえば、 スーパーサンプリングまたは畳み込み 。

あとは、フルサイズの画像をキャンバスにアップロードするだけです。 それは理想的なケースのように見えるでしょう。 resizePixelsの実装はオフスクリーンのresizePixelsします。

 function resizeImage(image, width, height) { var cIn = document.createElement('canvas'); cIn.width = image.width; cIn.height = image.height; var ctxIn = cIn.getContext('2d'); ctxIn.drawImage(image, 0, 0); var dataIn = ctxIn.getImageData(0, 0, image.width, image.heigth); var dataOut = ctxIn.createImageData(width, heigth); resizePixels(dataIn, dataOut); var cOut = document.createElement('canvas'); cOut.width = width; cOut.height = height; cOut.getContext('2d').putImageData(dataOut, 0, 0); return cOut; } 

それは一見したところとてもつまらなくて退屈です。 卵の栄光、ブラウザ開発者は退屈させません。 いいえ、もちろんこのコードは場合によっては機能します。 キャッチは予期しない場所にあります。

クライアントでサイズを変更する必要がある理由について説明しましょう。 サーバーに送信する前に、選択した写真のサイズを小さくして、ユーザーのトラフィックを節約するタスクがありました。 これは、接続が遅く、トラフィックが有料のモバイルデバイスで最も関連性があります。 そして、そのようなデバイスに最もよくダウンロードされる写真は何ですか？ これらのモバイルデバイスのカメラで撮影。 カメラの解像度、たとえば、iPhone-8メガピクセル。 しかし、それを使えば、25メガピクセルのパノラマを撮ることができます（iPhone 6ではさらに）。 AndroidおよびWindows Phoneでは、カメラの解像度はさらに高くなります。 そして、ここでこれらのモバイルデバイスの制限に直面しています。 残念ながら、 iOSでは5メガピクセルを超えるキャンバスを作成できません 。

Appleは理解できますが、限られたリソースでデバイスの正常な動作を監視する必要があります。 実際、上記の関数では、全体像が3回メモリを占有します！ Once-Imageオブジェクトに関連付けられたバッファー。イメージは展開され、2回目-キャンバスピクセル、3回目-ImageDataの型付き配列。 8メガピクセルの画像の場合、25メガピクセル-300の場合、8×3×4 = 96メガバイトのメモリが必要です。

しかし、テストプロセスでは、iOSだけでなく問題に遭遇しました。 Mac上のChromeは、1つの大きな画像の代わりにいくつかの小さな画像を描画するようになり、Windowsでは白いシートが表示されました。

しかし、一度にすべてのピクセルを取得することはできないので、それらを部分的に取得できますか？ 幅が元の画像の幅に等しく、高さがはるかに小さい断片でキャンバスに画像をロードできます。 最初に最初の5メガピクセルをロードし、次にもう1つをロードしてから、残りの量をロードします。 または2メガピクセルでさえ、メモリ使用量をさらに削減します。 幸いなことに、2パスコンボリューションのサイズ変更とは異なり、スーパーサンプリングのサイズ変更方法はシングルパスです。 つまり 画像を分割して受信できるだけでなく、一度に1つずつ送信して処理することもできます。 メモリは、Image要素、キャンバス（2メガピクセルなど）、および型付き配列にのみ必要です。 つまり 写真の場合、8メガピクセル（8 + 2 + 2）×4 = 48メガバイト、つまり2倍少ない。

上記のアプローチを実装し、各部分のランタイムを測定しました。 ここで自分自身をテストできます 。 これは、10,800×2,332ピクセルの解像度の画像（iPhoneのパノラマ）で得たものです。

ブラウザ	Safari 8	Chrome 40	Firefox 35	IE 11
画像の読み込み	24ミリ秒	27	28	76
キャンバスに描く	1	348	278	387
画像データを取得する	304	299	165	320
Jsサイズ変更	233	135	138	414
データを戻す	1	1	3	5
画像ブロブを取得する	10	16	21	19
合計	576	833	641	1243

これは非常に興味深いテーブルです。詳しく見ていきましょう。 素晴らしいニュースは、javascriptでのサイズ変更自体がボトルネックではないことです。 はい、SafariではChromeとFirefoxより1.7倍遅く、IEでは3倍遅くなりますが、すべてのブラウザで画像をダウンロードしてデータを受信する時間はさらに長くなります。

2番目の注目すべき点は、ブラウザでは画像がimage.onloadイベント用にデコードされないことです。 デコードは、本当に必要なときまで延期されます-画面に表示するか、キャンバスに表示します。 また、Safariでは、キャンバスも画面に表示されないため、キャンバスに適用しても画像はデコードされません。 また、ピクセルがキャンバスから削除された場合にのみデコードされます。

表はデータの描画と受信の合計時間を示していますが、実際にはこれらの操作は2メガピクセルごとに行われ、上記のリンクを使用するスクリプトは各反復の時間を個別に表示します。 これらのインジケータを見ると、Safari、Chrome、およびIEのデータを受信する合計時間がほぼ同じであるにもかかわらず、Safariでは、ほとんどの場合、最初の呼び出しだけで画像がデコードされ、ChromeとIEの時​​間はすべての呼び出しで同じであり、データ受信の一般的な速度低下を示しています。 Firefoxについても同じことが言えますが、程度は劣ります。

これまでのところ、このアプローチは有望に見えます。 モバイルデバイスでテストしましょう。 私の指先には、iPhone 4s（i4s）、iPhone 5（i5）、Meizu MX4 Pro（A）があり、オレグコルサンスキーにWindows Phoneでのテストを依頼したところ、HTC 8x（W）であることが判明しました。

ブラウザ	Safari i4	Safari i5	Chrome i4s	Chrome a	Chrome a	Firefox a	IE W
画像の読み込み	517ミリ秒	137	650	267	220	81	437
キャンバスに描く	2 706	959	2 725	1 108	6 954	1 007	1 019
画像データを取得する	678	250	734	373	543	406	1,783
Jsサイズ変更	2 939	1,110	96,320	491	458	418	2,299
データを戻す	9	5	315	6	4	14	24
画像ブロブを取得する	98	46	187	37	41	80	33
合計	6,995	2,524	101 002	2,314	8 242	2,041	5,700

最初に目を引くのは、iOS上のChromeの「顕著な」結果です。 確かに、最近まで、iOSでは、すべてのサードパーティブラウザーはjitコンパイルなしでバージョンのエンジンでしか動作しませんでした。 iOS 8では、jitを使用できるようになりましたが、Chromeはまだ適応できていません。

もう1つの奇妙な点は、Android上のChromeの2つの結果です。描画時間は根本的に異なり、他のすべてでほぼ同じです。 これはテーブルの間違いではなく、Chromeは実際に異なる動作をする可能性があります。 ブラウザーは、必要と判断した時点で、画像を遅延的に読み込むと既に述べました。 そのため、画像が不要になったと判断した場合、ブラウザは画像が占有しているメモリを解放することを妨げるものはありません。 当然、次にキャンバスに描画するときに画像が再び必要になった場合、再度デコードする必要があります。 この場合、画像は7回デコードされました。 これは、個々のチャンクを描画する時間で明確に見ることができます（表では合計時間のみを思い出します）。 このような状況では、デコード時間が予測不能になります。

悲しいかな、これらはすべての問題ではありません。 エクスプローラーであなたの脳を粉にしていたことを認めなければなりません。 実際には、キャンバスの各辺のサイズには4096ピクセルの制限があります。 また、これらの制限を超える画像の一部は、透明な黒いピクセルになります。 最大キャンバス領域の制限をバイパスするのが非常に簡単で、画像を水平にカットしてメモリを節約する場合、幅制限をバイパスするには、サイズ変更機能を大幅にやり直すか、隣接するピースをストリップに接着する必要がありますが、これはメモリ消費を増やすだけです。

この時点で、私はこの問題を吐き出すことにしました。 サイズを変更するだけでなく、クライアントでjpegをデコードする完全にクレイジーなオプションがありました。 短所：jpegのみ、ChromeのiOSにとっての悪い時間はさらに悪化します。 長所：AndroidでのChromeでの予測可能性、サイズ制限なし、必要なメモリの削減（キャンバスへの無限のコピーなし）。 純粋なjavascriptにはjpegデコーダーがありますが、私はこのオプションをあえてしませんでした。

パート2.最初に戻る

最初の段階で、最高の場合は2倍、そして最悪の場合は石鹸の連続的な減少という良い結果が得られたことを思い出してください。 しかし、アプローチをあまり変えずに最悪のオプションを取り除こうとするとどうなるでしょうか？ 最後のステップで写真を少し減らす必要がある場合、石鹸が得られることを思い出させてください。 最後のステップが最初に実行され、最初に不特定の回数だけ減少し、その後厳密に2倍だけ減少した場合はどうなりますか？ 途中で、最初のステップは、面積が5メガピクセル、幅が4096ピクセル以下であることを考慮する必要があります。 この場合、 コードは明らかに手動でサイズ変更するよりも簡単です。



左側では、画像は4段階で縮小され、右側では5段階で縮小され、ほとんど違いはありません。 ほぼ勝利。 残念ながら、2つと3つのステップの違い（1つと2つのステップの違いは言うまでもありません）は、まだ非常にはっきりと見えます。



石鹸は最初の頃よりもはるかに少ないですが。 右の画像（3段階で取得）は、左よりも少し見た目がいいと思いますが、これはシャープすぎます。

それでもサイズ変更を引き上げ、同時にステップ数を減らし、平均ステップ比を2に近づけることができます。主なことは時間内に停止することです。 ブラウザの制限により、基本的にもっと良いことをすることはできません。 次のトピックに進みましょう。

パート3.行の多くの写真

サイズ変更は比較的長い操作です。 額を操作してすべての画像のサイズを次々に変更すると、ブラウザが長時間フリーズし、ユーザーがアクセスできなくなります。 サイズ変更の各ステップの後にsetTimeoutを実行することをおsetTimeoutします。 ただし、ここで別の問題が発生します。すべての画像が同時にサイズ変更を開始すると、それらのメモリが同時に必要になります。 これは、キューを整理することで回避できます。 たとえば、前の画像のサイズ変更の最後に、次の画像のサイズ変更を開始できます。 ただし、キューが外部ではなくサイズ変更関数の内部で形成される場合は、より一般的なソリューションをお勧めします。 これにより、異なる場所からサイズ変更が同時に呼び出された場合でも、2つの画像が同時にサイズ変更されないことが保証されます。

完全な例は次のとおりです。第2部にあったすべての要素に加えて、長い操作の前のキューとタイムアウトの実装。 ページにひねりを加えたところ、ブラウザが動かなくなった場合、しばらくの間は明らかになりました。 モバイルデバイスでテストする時が来ました！

ここでは、モバイルSafari 8について余談にします（他のバージョンのデータはありません）。 その中で、入力で画像を選択すると、ブラウザが数秒間遅くなります。 これは、SafariがトリミングされたEXIFで写真のコピーを作成するか、入力内に直接表示される小さなプレビューを生成するためです。 1枚の写真が許容範囲内であり、目に見えない場合でも、複数選択を行うと地獄に変わる可能性があります（選択した写真の数によって異なります）。 この間、ページは写真が選択されていることを認識せず、ファイル選択ダイアログが通常開いていることもわかりません。

袖をまくり、iPhoneでページを開き、20枚の写真を選択しました。 少し考えて、Safariは喜んで報告しました。このWebページで問題が発生したため、再読み込みしました。 2回目の試行は同じ結果です。 親愛なる読者の皆さん、私はあなたがうらやましいです。なぜならあなたにとって次のパラグラフはすぐに飛んでくるでしょうが、私にとっては痛みと苦しみの夜だったからです。

そのため、Safariがクラッシュします。 開発者ツールを使用してデバッグすることはできません。メモリ消費については何もありません。 iOSシミュレーターでページを開くことを願っています-落ちません。 アクティビティモニターで確認しました-ああ、しかし、メモリはそれぞれの画像で成長しており、解放されていません。 まあ、少なくとも何か。 彼は実験を始めました。 シミュレーターでの実験の内容を理解できるように、1つの画像でメモリリークを確認することは不可能です。 4-5では難しいです。 20個を選択するのが最善で、「シフト」でドラッグまたは選択することはできないため、20回クリックする必要があります。 選択した後、タスクマネージャーを調べて推測する必要があります。メモリ消費量が50メガバイト減少するのはランダムな変動であるか、または私が正しいことをしました。

一般的に、多くの試行錯誤の後、私はシンプルだが非常に重要な結論に達しました：あなたはすべてを解放する必要があります。 可能な限り早急に、利用可能な手段で。 そして、できるだけ遅く割り当てます。 ガベージコレクションに完全に依存することはできません。 キャンバスを作成する場合、最後にズームする必要があります（1×1ピクセルにします）。画像が最後にある場合は、 src="about:blank"割り当ててアンロードする必要があります。 DOMから削除するだけでは十分ではありません。 URL.createObjectURLをURL.createObjectURLしてファイルを開く場合は、 URL.createObjectURLを使用してすぐに閉じる必要があります。

コードを強力に処理した後、512 MBのメモリを搭載した古いiPhoneは50枚以上の写真を消化し始めました。 AndroidのChromeとOperaの動作も大幅に改善されました。これまでにない160枚の20メガピクセルの写真が、ゆっくりとではあるが「途切れることなく」提供されました。 メモリ消費とデスクトップブラウザーへの同じ有益な効果-IE、Chrome、およびSafariは、動作中にタブごとに200メガバイト以下で安定して消費し始めました。 残念ながら、これはFirefoxの助けにはなりませんでした-彼は25枚のテスト画像のギガバイトを食べたので、彼は続けました。 AndroidでのモバイルFirefoxとDolphinについては何も言えません。複数のファイルを選択することは不可能です。

パート4.結論のようなもの

ご覧のとおり、クライアントで写真のサイズを変更するのは、わくわくし、苦痛です。 フランケンシュタインの一種であることが判明しました。不快なネイティブのサイズ変更は、少なくともある程度の品質を得るために繰り返し使用されます。 したがって、さまざまなプラットフォームの検出不可能な制限をバイパスする必要があります。 また、写真が石鹸っぽいまたはシャープすぎる場合、元のサイズと最終サイズのプライベートな組み合わせが多くあります。

ブラウザは狂ったようなリソースを食い尽くし、何も解放されず、魔法は機能しません。 この意味では、リソースを明示的に解放する必要があるコンパイル済み言語で作業する場合よりも、すべてが悪化します。 jsでは、第一に、何をリリースする必要があるかが明らかではありません。第二に、これは常に可能とはほど遠いです。 それでも、少なくともほとんどのブラウザーの食欲を抑えることは非常に現実的です。

舞台裏にはEXIFとの仕事がありました。 ほとんどすべてのスマートフォンとカメラは同じ方向でマトリックスから画像をキャプチャし、実際の方向はEXIFに記録されるため、この情報をサムネイルとともにサーバーに転送することが重要です。 幸いなことに、JPEG形式は非常に単純であり、私のプロジェクトでは、解析することなく、ソースファイルから最後のセクションにEXIFセクションを転送するだけです。

Uploadcareウィジェット用のファイルをアップロードする前に、サイズ変更を記述するプロセスでこのすべてを学び、測定しました。 この記事で引用したコードは、物語のロジックをより忠実にたどっていますが、エラー処理とブラウザーのサポートという点では、多くが欠落しています。 したがって、自分で使用したい場合は、ウィジェットのソースコードを確認することをお勧めします 。

ちなみに、ここにさらにいくつかの数字があります。この手法を使用すると、iPhone 5から80枚の写真が800×600の解像度に縮小され、3G経由で2分以内にダウンロードされます。 同じ元の写真の読み込みには26分かかる場合があります。 だからそれは価値があった。