11

Web でプログレッシブJPEGの表示が許可されているかどうかを理解しようとしています。

サーバーがあると仮定します (プログレッシブ jpegを参照):

$ identify /var/www/test.jpg
/var/www/test.jpg JPEG 2048x1080 2048x1080+0+0 8-bit DirectClass 129KB 0.020u 0:00.019
$ identify -verbose /var/www/test.jpg | grep Inter
  Interlace: JPEG

次の HTML ドキュメントを配置すると、次のようになります。

$ cat /var/www/test.html
<!DOCTYPE html>
<html>
<head><title>jpg test</title></head>
<body>
<p><img src="test.jpg" width="256" height="128"></p>
</body>
</html>

( img 要素に よると)2048x1080レンダリング領域が256x128.

または逆に、User Agentはレンダリング領域を考慮することが許可されているため、プログレッシブJPEG256x128の一部しか処理できないと推測します。画像に詳細を追加しないため、フル解像度を使用しても意味がないことを知っています（技術的には、高品質のレイヤーは低解像度でも影響するはずです。これは単純化のためです）。

通常、Googleマップなどのアプリケーション内で、ユーザーエージェントが現在表示されている画像の取得を中止（一時停止？）できるかどうかを知りたい. （JPEG全体はまだユーザー側にはありません）。

更新: Web はloading、HTML の属性を使用して、ここで別のアプローチを試みていることがわかりました。

<img src="example.jpg" loading="lazy" alt="example" />
4

4 に答える 4

7

Web サイトでプログレッシブ JPEG を使用するという考えは、帯域幅を節約することとはあまり関係がなく、より早くエンド ユーザーに何かを表示することと関係があります。ブラウザーは何があっても完全な画像をダウンロードしますが、プログレッシブ JPEG を使用すると、ユーザーは以前に何かが起こっていることを確認できます。

JPEGのW3 ページには次のように書かれています。

プログレッシブ JPEG は、小さな部分だけがダウンロードされた後、画像全体のぼやけたビューが表示されるように、情報の順序を変更する手段です。

通常、IMG タグを含めることは、ブラウザにそのアセットをダウンロードさせることを意味するため、ダウンロードが「十分」であると判断されたからといって、途中で中止することはありません。また、ブラウザは、後で画像をどうしようとしているのかを認識していません。後でズームするか、後で別のサイズで表示する必要があるかもしれません。一度部分的にダウンロードすると、ブラウザは後で再度ダウンロードする必要がある場合があります。

また、 JPEG に関するウィキペディアの記事では、次のように指摘されています。

ただし、プログレッシブ JPEG はそれほど広くサポートされておらず、[要出典]、それらをサポートしている一部のソフトウェア (Windows 7 より前のバージョンの Internet Explorer など)[12] でさえ、完全にダウンロードされた後にのみ画像を表示します。

したがって、一部のブラウザーが「十分な」ダウンロード後にこれらの接続を中止したとしても、最初からそれらを使用することを検討するほどのサポートを提供するブラウザーは十分ではありません。

于 2013-04-03T15:41:04.383 に答える
0

img簡単に言えば、ページを離れたり中止したり、タグの src を変更したりせずに（プログレッシブまたはその他の方法で）中止する標準的な方法はありません（これにより部分的な画像が削除されます）。それを行うハックも知りません。

これは便利な機能のように思えますが、次のような一般的なケースでは、既存の Web サイトでは問題になる可能性があります。

  • 大きなプログレッシブ画像をサムネイル + プリロードとして使用する画像ギャラリー (つまり、Galleriaがこれを行います)
  • 画像のイベントに依存する Web サイトonloadはありますか (中止/一時停止できる場合、半分レンダリングされた画像はどの時点で「読み込まれた」と見なされますか)?

これらの理由だけでも、属性として仕様に追加しない限り、それは悪い考えです (非推奨の属性や、この動作を明示的に要求するlowsrcある種の属性など)。allowpartialWHATWG の議論を追ってきた者として言えることは、フリンジの問題を解決するために複雑さが増すという単純な理由で、ほぼ確実に完全に拒否されるということです。この機能が本当に必要であるとすれば、ブロードバンドがほぼ普遍的になる何年も前に需要があったでしょう。ゲームのこの時点では、Javascript やサムネイルの巧妙な使用により、本質的に冗長になっています。

于 2013-04-08T00:54:54.370 に答える