Les images SVG semblent-elles mieux réduites qu'un png, jpg ou gif haute résolution?


15

Je sais que si vous souhaitez agrandir une image, un SVG est un choix judicieux.

Cependant, ma situation est que j'ai des icônes que je veux que les utilisateurs puissent télécharger via un CMS. Les SVG sont juste un peu plus difficiles à créer, et donc jpg, gif ou png semble le format idéal pour les administrateurs.

S'ils sont téléchargés de la même taille ou plus grands que la taille d'affichage, et conservés dans le bon rapport, les fichiers jpgs, gifs ou pngs peuvent-ils être de la même qualité qu'un SVG lorsqu'ils sont réduits en taille?

Mon hypothèse serait que les navigateurs doivent également antialiase un svg en dessous d'une certaine taille, donc ils sont susceptibles de flouter autant que tout autre format, bien que les gifs semblent plus flous.


4
Une bonne question mais je crois que la réponse est "cela dépend du navigateur".
usr2564301

Réponses:


7

(Remarque: veuillez lire la propre réponse du PO avant celle-ci, car ma réponse est un commentaire sur l'enquête du PO)

Il s'agit d'un problème connu d'Android Chrome. Sur certaines de leurs versions, ils ont désactivé l'anti-crénelage, ce qui a rendu les formes vectorielles avec des bords nets. La raison en était de réduire la surcharge créée par les calculs d'anticrénelage. En raison de plaintes, ils ont publié une mise à jour qui aurait dû activer l'anti-aliasing.

Il existe plusieurs threads dans Stack Overflow traitant de ce problème. En voici un:
/programming/19875908/vectors-poorly-displayed-on-chrome-for-android-canvas

Je n'ai pas pu trouver de référence au même problème sur IPod Touch Safari, mais il est probablement sûr d'extrapoler et de supposer que le problème est le même.

Il existe des moyens d'essayer de forcer l'anti-aliasing même lorsqu'il est désactivé, comme cette astuce qui ajoute essentiellement un peu de remplissage autour de l'élément, ce qui oblige le navigateur à appliquer l'anti-aliasing pour une raison quelconque. Vous pouvez également essayer de définir l' attribut de rendu de forme de l'élément sur quelque chose de différent des bords nets et voir si le navigateur le respecte.


L'ajout de -webkit-backface-visibilité: caché signifie que les non-svgs se brouillent sur l'iPod exactement de la même manière que les svgs, et cela répond à ma question - c'est-à-dire qu'il n'est pas nécessaire de choisir l'un sur l'autre lors de la réduction. Curieusement, le correctif Android ne semble pas standardiser le comportement de rendu sur ma version d'Android Chrome / broswer natif, mais c'est un problème différent. Merci de votre aide.
Richard B

13

Je viens de lancer un test et la seule différence semble être sur les navigateurs mobiles.

J'ai créé une image 990 x 900px de l'icône Twitter (cette icône semble bien trop détaillée pour une bonne mise à l'échelle, donc bonne pour ce test). J'ai enregistré cela en SVG, JPG, GIF, GIF transparent (juste la forme de l'oiseau, pas de couleur d'arrière-plan, au lieu de cela avec CSS), PNG, PNG transparent.

J'ai ensuite réduit ces derniers à 15 pixels, 25 pixels, 50 pixels, 100 pixels et 150 pixels.

Voici les résultats dans Firefox: entrez la description de l'image ici

Voici les résultats dans Chrome: entrez la description de l'image ici

Si nous zoomons sur une capture d'écran des plus petits résultats afin que nous puissions voir quels pixels sont générés, Firefox (en haut) assombrit légèrement les bords des versions non transparentes, mais tous les autres résultats sont très similaires.

entrez la description de l'image ici

Cependant, sur un navigateur IPod Touch Safari, la version SVG semble assez floue et les autres assez pixélisées:

entrez la description de l'image ici

Un résultat similaire est également visible sur Android Chrome. Je n'ai pas pris de capture d'écran de cela.

Je me demande si cela pourrait être dû à la densité de pixels, qui est la principale différence d'affichage, bien que cela aurait plus de sens pour moi si toutes les images étaient gérées différemment sur mobile, plutôt que juste celle SVG.

Si quelqu'un peut expliquer pourquoi c'est le cas, alors je transférerai la réponse acceptée. Sinon, je pense que la réponse TL; DR est que cela dépend si vous préférez des icônes floues ou pixélisées (ou pour faire beaucoup d'icônes à des tailles parfaites de pixels pour vos points d'arrêt réactifs).

edit: J'ai depuis observé que les svgs sont généralement beaucoup plus clairs sur les appareils Apple - l'oiseau Twitter peut avoir été trop détaillé pour que cela apparaisse dans mes tests ci-dessus, alors sentez-vous qu'ils sont le bon format à utiliser pour les icônes.


Le SVG est rendu au moment de l'affichage et peut bénéficier de AA, les autres sont à résolution fixe et le seul AA qu'ils peuvent avoir est le rendu 2x; brouiller; et réduire, ce qui ne va pas vraiment aider sauf dans les situations de "détramage". Pour le SVG, une méthode AA fixe (comme le simple 4x FSAA sur toute la ligne) va être trop agressive lorsque vous n'aurez qu'une largeur de 8 pixels, et un sous-échantillonnage entraîne toujours un flou.
Yorik

Notez que le type de mise à l'échelle et de rééchantillonnage dépend de l'implémentation logicielle. La plupart optent pour "rapide" ou "équilibré" au lieu de la qualité.
Yorik

3

Il existe une distinction très importante entre les images vectorielles et les images bitmap. Les images vectorielles, si nous simplifions un peu, sont rendues par le client tandis que les images bitmap sont rendues par vous.

Cela signifie que l'application à laquelle vous envoyez l'image a plus à dire sur son comportement. Le résultat final est que vous avez les inconvénients suivants :

  • Il faut plus de ressources pour rendre l'image présentable
    • Dans ce cas, le rendu peut opter pour une baisse de qualité car il ne dispose pas de suffisamment de ressources pour le faire mieux.
  • Chaque système d'imagerie a son propre ensemble de bizarreries et de défauts
    • Rend plus difficile d'être cohérent
    • Vous obtenez les problèmes d'un programmeur

D'un autre côté, cela présente certains avantages :

  • L'image peut être mise à l'échelle librement et avoir plus d'options de manipulation.
    • Ceci est simplement le résultat du travail effectué à la fin des clients afin qu'ils puissent passer plus de temps sur le calcul des pixels pour obtenir une image plus grande si vous envoyez des éléments qu'il sait mettre à l'échelle.
  • Dans de nombreux cas, les données sont plus petites que l'image en pixels (bien que cela ne soit pas obligatoire)

Il n'y a pas grand-chose que vous puissiez faire si un système a un rendu buggy. Votre choix donne à l'application finale un choix et ils peuvent utiliser ce choix pour prendre de mauvaises décisions.

Ce qui est mieux

Cela dépend de la qualité du rendu de votre image et de la bande passante dont vous disposez. Il est certainement possible de faire un meilleur rendu que ce que font les navigateurs. Pas vraiment surprenant, on peut aussi faire un meilleur travail qu'Illustrator. Mais alors vous perdez tous les avantages d'avoir un rendu différé.

Il existe une troisième option.

Si vous n'êtes pas satisfait des résultats, vous pouvez toujours essayer de créer votre propre moteur de rendu. Avec des plateformes qui prennent en charge webgl, vous pouvez. Voir ici pour un exemple . Mais c'est assez hardcore et ne vous enregistre pas les détails de mise en œuvre du formulaire.


2

(Pas assez de points pour commenter directement la réponse de Richard B.)

Pour répondre à votre question Richard B, nous constatons souvent cet effet sur les éléments nécessitant un anti-aliasing sur du matériel de moindre puissance. Cela se produit même sur les éléments DOM aux coins arrondis, lorsque l'anticrénelage est réduit ou supprimé de ces environnements.

Dans notre entreprise, nous avons certains cas où nous utilisons du matériel de faible puissance et avons commencé à rencontrer ce problème de "formes à bords tranchants extrêmement". Nous avons désactivé / réduit la quantité d'anticrénelage pour améliorer les performances. C'est probablement la même raison pour laquelle vos tests sur mobile ont renvoyé les résultats qu'ils ont obtenus.


Est logique comme raison. Cependant, les SVG honteux ne semblent pas être cohérents avec les autres types d'images.
Richard B

1
@ RichardB, Eh bien, ils sont en quelque sorte différents des images ordinaires. Vous pouvez réellement interagir avec eux comme s'il s'agissait de nœuds DOM. Leurs chemins et formes reçoivent des événements et des propriétés CSS tout comme les vrais nœuds DOM, donc si ma compréhension est correcte, ils suivent le même chemin de rendu que les autres nœuds et cela a du sens dans ce contexte. Les images sont des cases tramées et passent par un canal de rendu différent, parfois même en créant de l'espace sur le GPU.
Brak
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.