¿Las imágenes SVG se ven mejor reducidas que un png, jpg o gif de alta resolución?


15

Sé que si quieres escalar una imagen, entonces un SVG es una buena elección.

Sin embargo, mi situación es que tengo iconos que quiero que los usuarios puedan cargar a través de un CMS. Los SVG son un poco más difíciles de crear, por lo que jpg, gif o png parece el formato ideal para los administradores.

Si se carga igual o más grande que el tamaño de la pantalla, y se mantiene en la proporción correcta, ¿pueden los jpgs, gifs o pngs ser tan de alta calidad como un SVG cuando se reduce su tamaño?

Mi suposición sería que los navegadores también necesitan antialiasar un svg por debajo de cierto tamaño, por lo que es probable que se desenfoquen tanto como cualquier otro formato, aunque los gifs aparentemente se desenfocan más.


44
Una buena pregunta pero creo que la respuesta es "depende del navegador".
usr2564301

Respuestas:


7

(Nota: lea la respuesta del OP antes de esta, ya que mi respuesta es un comentario sobre la investigación del OP)

Este es un problema conocido de Android Chrome. En algunas de sus compilaciones, deshabilitaron el suavizado, lo que hizo que las formas vectoriales se representaran con bordes nítidos. La razón de esto fue reducir la sobrecarga creada por los cálculos anti aliasing. Debido a las quejas, lanzaron una actualización que debería haber habilitado el anti aliasing.

Hay varios hilos en Stack Overflow que discuten este problema. Aquí está uno de ellos:
/programming/19875908/vectors-poorly-displayed-on-chrome-for-android-canvas

No pude encontrar una referencia al mismo problema en IPod Touch Safari, pero probablemente sea seguro extrapolar y asumir que el problema es el mismo.

Hay formas de intentar forzar el suavizado incluso cuando está desactivado, como este truco que básicamente agrega un poco de relleno alrededor del elemento que hace que el navegador, por algún motivo, aplique el suavizado. También puede intentar establecer el atributo de representación de formas del elemento en algo diferente a los bordes nítidos y ver si el navegador lo cumple.


Agregar -webkit-backface-visibilidad: oculto significa que los no svgs se difuminan en el iPod exactamente de la misma manera que los svgs, y eso responde a mi pregunta, es decir, no hay necesidad de elegir uno sobre el otro al reducir la escala. Curiosamente, la solución de Android no parece estandarizar el comportamiento de representación en mi versión de Android Chrome / Native Broswer, pero ese es un problema diferente. Gracias por tu ayuda.
Richard B

13

Acabo de ejecutar una prueba y la única diferencia parece estar en los navegadores móviles.

Creé una imagen de 990 x 900px del icono de Twitter (ese icono parece un diseño demasiado detallado para una buena escala, tan bueno para esta prueba). Lo guardé como SVG, JPG, GIF, GIF transparente (solo la forma del pájaro, sin color de fondo, en cambio agregué esto con CSS), PNG, PNG transparente.

Luego los reduje a 15 px, 25 px, 50 px, 100 px y 150 px.

Aquí están los resultados en Firefox: ingrese la descripción de la imagen aquí

Aquí están los resultados en Chrome: ingrese la descripción de la imagen aquí

Si hacemos zoom en una captura de pantalla de los resultados más pequeños para que podamos ver qué píxeles se están generando, entonces Firefox (arriba) oscurece ligeramente los bordes en las versiones no transparentes, pero todos los demás resultados son muy similares.

ingrese la descripción de la imagen aquí

Sin embargo, en un navegador IPod Touch Safari, la versión SVG parece bastante borrosa, y las otras bastante pixeladas:

ingrese la descripción de la imagen aquí

Un resultado similar también se ve en Android Chrome. No he tomado una captura de pantalla de esto.

Me pregunto si la razón de esto podría tener algo que ver con la densidad de píxeles, que es la principal diferencia en la visualización, aunque eso tendría más sentido para mí si todas las imágenes se manejan de manera diferente en el móvil, en lugar de solo la SVG.

Si alguien puede explicar por qué este es el caso, entonces transferiré la marca de respuesta aceptada. De lo contrario, supongo que la respuesta TL; DR es que depende si prefiere iconos borrosos o pixelados (o hacer muchos iconos en tamaños de píxeles perfectos para sus puntos de corte receptivos).

editar: desde entonces he observado que los svgs suelen ser mucho más claros en los dispositivos de Apple: el pájaro de Twitter puede haber sido demasiado detallado para que esto aparezca en mis pruebas anteriores, por lo que siento que son el formato correcto para usar para los iconos.


SVG se procesa en el momento de la visualización y puede beneficiarse de AA, los otros tienen una resolución fija y el único AA que pueden tener es renderizar 2x; difuminar; y reducir, lo que realmente no va a ayudar, excepto en situaciones de "eliminación de pantalla" Para el SVG, un método AA fijo (como el FSAA 4x simple en todos los ámbitos) será demasiado agresivo cuando solo tenga un ancho de 8px, y el muestreo descendente siempre produce algo de desenfoque.
Yorik

Tenga en cuenta que el tipo de escalado y remuestreo depende de la implementación del software. La mayoría opta por "rápido" o "equilibrado" en lugar de calidad.
Yorik

3

Hay una distinción muy importante entre las imágenes vectoriales y las imágenes de mapa de bits. Las imágenes vectoriales, si simplificamos un poco, son renderizadas por el cliente mientras usted renderiza las imágenes de mapa de bits.

Esto significa que la aplicación a la que está enviando la imagen tiene más voz sobre cómo se comporta. El resultado final es que tiene los siguientes inconvenientes :

  • Se necesitan más recursos para que la imagen sea presentable
    • En este caso, el renderizado podría optar por perder calidad porque no tiene suficientes recursos para hacerlo mejor.
  • Cada sistema de imágenes tiene su propio conjunto de peculiaridades y defectos
    • Hace que sea más difícil ser consistente
    • Tienes los problemas de un programador

Por otro lado, hay algunos beneficios de esto:

  • La imagen se puede escalar libremente y tener más opciones de manipulación.
    • Esto es simplemente el resultado del trabajo realizado al final de los clientes para que puedan dedicar más tiempo a calcular los píxeles para obtener una imagen más grande si envía elementos que sabe cómo escalar.
  • Los datos en muchos casos son más pequeños que la imagen de píxeles (aunque no tiene que ser así)

No hay mucho que pueda hacer si un sistema tiene un procesador defectuoso. Su aplicación final le da una opción y pueden usar esa opción para tomar malas decisiones.

Cual es mejor

Depende de qué tan bien puede renderizar su imagen y cuánto ancho de banda tiene a su disposición. Ciertamente es posible hacer un render mejor que el que hacen los navegadores. No es realmente sorprendente que uno pueda hacer un mejor trabajo que Illustrator también. Pero luego pierde todos los beneficios de tener una representación diferida.

Hay una tercera opción.

Si no está satisfecho con los resultados, siempre puede intentar crear su propio motor de renderizado. Con plataformas que admiten webgl puedes. Ver aquí para un ejemplo . Pero esto es bastante duro y no le guarda los detalles de la implementación del formulario.


2

(No hay suficientes puntos para comentar sobre la respuesta de Richard B directamente todavía).

Para responder a su pregunta Richard B, a menudo vemos este efecto en elementos que necesitan suavizado en hardware de baja potencia. Esto incluso ocurre en elementos DOM con esquinas redondeadas, cuando el suavizado se reduce o elimina de esos entornos.

En nuestra empresa, tenemos algunos casos en los que usamos hardware de menor potencia y comenzamos a encontrar este problema de "formas de bordes extremadamente irregulares". Deshabilitamos / redujimos la cantidad de suavizado para mejorar el rendimiento. Esta es probablemente la misma razón por la que sus pruebas en dispositivos móviles arrojaron los resultados que obtuvieron.


Tiene sentido como una razón. Sin embargo, los SVG de vergüenza no parecen tener consistencia con otros tipos de imágenes.
Richard B

1
@ RichardB, Bueno, son algo diferentes de las imágenes normales. En realidad, puede interactuar con ellos como si fueran nodos DOM. Sus rutas y formas reciben eventos y propiedades CSS al igual que los nodos DOM reales, por lo que si mi comprensión es correcta, siguen la misma ruta de representación que otros nodos y tiene sentido en este contexto. Las imágenes son cuadros rasterizados y pasan por un canal de representación diferente, a veces incluso creando espacio en la GPU.
Brak
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.