SVG画像は、高解像度のpng、jpg、gifよりも縮小されたように見えますか？

画像を拡大したい場合は、SVGが賢明な選択であることを知っています。

ただし、私の状況では、ユーザーがCMS経由でアップロードできるようにするアイコンがあります。SVGは作成するのが少し難しいため、jpg、gif、またはpngは管理者にとって理想的な形式のようです。

ディスプレイサイズと同じかそれよりも大きいサイズでアップロードし、適切な比率を維持すると、サイズを縮小したときにjpg、gif、またはpngがSVGと同じくらい高品質になりますか？

私の仮定は、彼らはおそらくGIFファイルがないものの、他のフォーマットと同じように多くをぼかすあるのでブラウザは、あまりにも一定の大きさ以下のSVGをantialiaseする必要があるということでしょう一見よりぼやけます。

（注：私の答えはOPの調査に関するコメントなので、この前にOPの答えを読んでください）

これはAndroid Chromeの既知の問題です。一部のビルドでは、アンチエイリアシングを無効にして、ベクターシェイプを鮮明なエッジでレンダリングしました。これは、アンチエイリアシング計算によって生じる過負荷を軽減するためです。苦情のために、彼らはアンチエイリアシングを有効にすべきアップデートをリリースしました。

Stack Overflowには、この問題を議論するスレッドがいくつかあります。それらの1つを次に示します。https :
//stackoverflow.com/questions/19875908/vectors-poorly-displayed-on-chrome-for-android-canvas

私はIPod Touch Safariで同じ問題への参照を見つけることができませんでしたが、おそらく外挿して問題が同じであると仮定しても安全です。

アンチエイリアシングが無効になっている場合でも、強制的にアンチエイリアシングを試みる方法があります。たとえば、何らかの理由でブラウザにアンチエイリアシングを適用させる要素の周りに少しパディングを追加するこのトリックなどです。また、要素のシェイプレンダリング属性をクリスプエッジとは異なるものに設定して、ブラウザがそれを尊重するかどうかを確認することもできます。

私はちょうどテストを実行しましたが、唯一の違いはモバイルブラウザでのようです。

Twitterアイコンの990 x 900ピクセルの画像を作成しました（このアイコンは、スケーリングのためにはデザインがあまりにも詳細すぎると思われるため、このテストに適しています）。これをSVG、JPG、GIF、透明GIF（鳥の形のみ、背景色なし、代わりにCSSで追加）、PNG、透明PNGとして保存しました。

次に、これらを15px、25px、50px、100px、および150pxに縮小しました。

Firefoxでの結果は次のとおりです。

Chromeでの結果は次のとおりです。

最小の結果のスクリーングラブにズームインして、生成されているピクセルを確認できる場合、Firefox（上）は不透明バージョンのエッジをわずかに暗くしていますが、他の結果はすべて非常に似ています。

ただし、IPod Touch Safariブラウザーでは、SVGバージョンはかなりぼやけているように見え、他のバージョンはかなりピクセル化されています。

Android Chromeでも同様の結果が見られます。私はこれのスクリーンショットを撮りませんでした。

この理由はディスプレイの主な違いであるピクセル密度に関係しているのではないかと思いますが、すべての画像がSVGのものではなく、モバイル上で異なる方法で処理された場合、より理にかなっています。

誰かがこれが事実である理由を説明できれば、受け入れられた答えの目盛りを転送します。それ以外の場合、TL; DRの答えは、ぼやけたアイコンまたはピクセル化されたアイコンを好むかどうか（またはレスポンシブなブレークポイントのためにピクセル完璧なサイズで多くのアイコンを作るかどうかに依存するということです）。

編集：私はそれ以来、svgsは通常Appleデバイスではるかに明確であることを観察しました-twitterの鳥は上記の私のテストでこれを表示するには詳細すぎるかもしれないので、アイコンに使用するのに適切な形式であると感じます。

ベクター画像とビットマップ画像の間には非常に重要な違いがあります。ベクトル画像は、ビットを単純化すると、クライアントによってレンダリングされますが、ビットマップ画像はユーザーによってレンダリングされます。

これは、画像を送信するアプリケーションがその動作についてより多くの発言権を持っていることを意味します。最終的な結果は、次の欠点があります。

• イメージを表示可能にするためにより多くのリソースが必要です
  • この場合、レンダリングを行うのに十分なリソースがないため、レンダリングの品質が低下する可能性があります。
• 各イメージングシステムには、独自の癖と欠陥があります。
  • 一貫性を保つのが難しくなります
  • プログラマーの問題を取得します

一方、これにはいくつかの利点があります。

• 画像は自由に拡大縮小でき、より多くの操作オプションがあります。
  • これは単にクライアント側で行われたジョブの結果であるため、スケーリング方法を知っている要素を送信すると、ピクセルの計算により多くの時間を費やしてより大きな画像を得ることができます。
• 多くの場合、データはピクセルイメージよりも小さい（ただし、そうである必要はない）

システムにバグのあるレンダラーがある場合、できることはあまりありません。最終アプリケーションに選択肢を与えると、彼らはその選択を使用して悪い判断を下すことができます。

どちらが良いですか

それは、イメージをどれだけうまくレンダリングできるかと、自由に使える帯域幅の量に依存します。ブラウザーが行うよりも優れたレンダリングを行うことは確かに可能です。イラストレーターよりも優れた仕事をすることができるのは、それほど驚くことではありません。しかし、その後、遅延レンダリングを行うことの利点をすべて失います。

3番目のオプションがあります。

結果に満足できない場合は、いつでも独自のレンダリングエンジンを作成することができます。webglをサポートするプラットフォームを使用すると、できます。例についてはこちらをご覧ください。しかし、これはかなりハードコアであり、フォームの実装の詳細を保存しません。

（リチャードBの答えに直接コメントするのに十分なポイントがまだありません。）

リチャードBの質問に答えるために、低電力ハードウェアでアンチエイリアシングを必要とする要素にこの効果がよく見られます。角の丸いDOM要素でも、アンチエイリアスが削減されるか、これらの環境から削除されると、これが発生します。

当社では、低消費電力のハードウェアを使用する場合があり、この「極端にギザギザのエッジ形状」問題に遭遇し始めました。パフォーマンスを改善するために、アンチエイリアスの量を無効化/削減しました。これはおそらく、モバイルでのテストで結果が返されたのと同じ理由です。