Según parece, Google está utilizando un algoritmo de compresión de vídeo (códec VP8 liberado por la propia Google hace poco) para sus imágenes WebP y ahora lo que queda esperar es que los usuarios y empresas lo empiecen a utilizar como un estándar. A mí se me antoja algo difícil, ya que hace años que apareció el formato PNG y sigue sin emplearse masivamente hoy día, a pesar de sus múltiples ventajas sobre el JPG.
De acuerdo a la presentación oficial, el 65 por ciento de los bytes transferidos en la carga de una página web son consumidos por imágenes (y los protocolos aún más, pero eso ya lo tocaremos otro día). Esto puede llevar a una lentitud no deseada, y aunque los efectos tal vez no sean del todo perceptibles en conexiones de alta velocidad, se vuelven mucho más tangibles en conexiones más modestas. La navegación móvil también puede verse perjudicada por un alto contenido de imágenes, ya que además de ofrecer una experiencia lenta, más bytes cargados significan más bytes consumidos en conexiones medidas.
Ahora mismo Google tiene varias imágenes de ejemplo en su web con conversiones directas de archivos JPG con pérdida. Por tanto, los WebP existentes oficialmente ya están contaminados con pérdidas JPG, aunque es un ejemplo real de la utilidad que tienen para Google al ser usados en las miniaturas que muestra en sus búsquedas.
Sin embargo, en EnglishHard, ha aparecido una comparación propia con imágenes de alta calidad comprimidas a los dos formatos (WebP y JPG) con una idea: mantener el peso de las imágenes para comprobar las diferencias de calidad. Y vaya si las hay... Lo copio a continuación: (igual encuentras algo raro, utilicé de base el traductor de Google aunque lo he re-traducido para que pueda entenderse. PErsonalmente, prefiero el artículo original en inglés).
Prueba n º 1 - "High Class" por Erik Anderson
Esta imagen en 3D tiene algunos aspectos agradables en él para el análisis de imágenes - los gradientes suaves en el fondo llevará a cabo todas las cuestiones de bandas que webp o experiencia jpg, y los bordes duros de las copas de martini con claridad que nos muestran los artefactos.
Resultados:
webp:
jpg: EDITADO: Desplácese hacia abajo para una versión actualizada
Esta fue la primera prueba que me encontré y dejé que el convertidor WebP decidiera automáticamente la calidad de la imagen. He descubierto que, sobretodo en las últimas pruebas, a menudo se establece la calidad de imagen muy baja cuando se hicieron las conversiones. No porque no fuera una imagen aceptable sino simplemente porque a menudo se encuentran dificultades para obtener el equivalente jpg hasta que la calidad deje de ser una imagen aceptable. Esto no quiere decir que WebP sea automáticamente un formato mejor, pero para los tamaños de archivo más pequeño parece comportarse muy bien (al menos en esta prueba). Pase el ratón sobre los dos imágenes anteriores el mapa con una mayor diferencia. Este mapa fue hecho simplemente tomando la diferencia de la imagen comprimida y la imagen sin pérdida original en GIMP, para a continuación, ejecutar un ajuste de la curva para llevar a cabo estas sutiles diferencias. Si la imagen es idéntica la capa de diferencia será completamente negra. Además, cuanto más colorida sea la imagen, mayor es el tono que difiere entre la imagen comprimida y la original.
En este caso, parece que la compresión jpg produce algunos cambios muy grandes en la luminancia de la imagen. La imagen webp tiene menos problema de luminancia, pero a costa del tono/color. Tenga en cuenta que algunos de los colores de la difracción de los cristales se han perdido en los dos algoritmos de compresión en esta calidad.
actualización de la muestra jpg
Michael Terretta tuvo la amabilidad de enviarme una muestras usando Photoshop "Guardar para Web". Como se señaló en las noticias de hackers , puede muy bien ser un problema del JPG con la codificación de GIMP, que agrava los problemas de bandas. John Millikin señala además que el formato JPG es también el almacenamiento de algunos otros datos EXIF, que reduce la cantidad de espacio que el JPG tiene que almacenar los datos de imagen comprimida si se está comparando el mismo tamaño. De cualquier manera, aquí está la información de la versión de Michael:
jpg:
Prueba # 2 - Negro y blanco
Las disparidades de croma que aparecen en el primer set me tenían un poco preocupado de cómo se había que actuar en una situación de escala de grises. El problema dio vuelta para arriba, aunque no como yo esperaba. Cuando ejecuté el script de conversión tuve este error:
j@saunders:~$ ./webpconv IMG_0380.png j @ Saunders: ~ $ / webpconv IMG_0380.png.
processing IMG_0380.png
Output file IMG_0380.webp
libpng error: Read Error
Error in pixReadStreamPng: internal png error
Error in pixReadStream: png: no pix returned
Error in pixGetInputFormat: pix not defined
Error in pixRead: image not returned
Failed to read image
Como resultado, webp aun no soporta perfiles de color. Esta imagen en particular fue creado a escala de grises por razones obvias, así que lo convierte a sRGB antes de hacer la carrera webp.
Resultados:
webp:
jpg:
| webp | jpg | |
|---|---|---|
| Resolución: | 600×900 | 600×900 |
| Calidad: | 76KB | 72KB |
| Diferencia de medias de valor: | 0.5% | 0.7% |
Estas dos imágenes tenían su calidad establecida bastante alta para y mostrar los resultados. Me sorprendió lo bien que webp lo hizo al no esconder ningún color y mi temor de que se mostraban objetos de color fué derribado. Se realiza maravillosamente aquí, aunque visualmente es bastante indistinguible de jpg a esta calidad. Sólo los mapas dan una diferencia mayor al mostrar su ligera ventaja. En cuanto a los números, tenga en cuenta que a medida que se trata de una imagen en escala de grises no hay diferencia RGB. También es interesante que esta es la única prueba en la que la superó el formato jpg a webp en la diferencia de valor medio. Cabe señalar, sin embargo, la desviación estándar en él, aunque - 1.16 para la webp, y 1.96 para jpg (o en la llanura , aunque ambos esquemas están cerca en los resultados de la compresión JPG es más irregular).
Prueba # 3 - Todos los colores
Funcionó bien con la falta extrema de colores así que vamos a probar con el otro extremo aquí. En la imagen siguiente hay dispuestos un millón de colores estratégicamente. Cortesía de la Wikipedia, la enciclopedia libre , esta imagen es a menudo utilizada para las pruebas de calibración y siento que voy a hacer un trabajo decente en las pruebas de estrés de los algoritmos de compresión
Resultados:
webp:
jpg:
| webp | jpg | |
|---|---|---|
| Resolución: | 1000×1000 | 1000×1000 |
| Calidad: | 32KB | 33KB |
| Diferencia de medias RGB: | 0.5% | 2.3% |
| Diferencia de medias de valor: | 0.4% | 2.0% |
Los resultados aparecidos aquí son probablemente la diferencia más sorprendente entre los dos algoritmos de compresión. Sin lugar a dudas supera webp a jpg aquí, pero esto no quiere decir que sea perfecto. Empezando a notar los sombreados en las huellas de los artefactos típicos, aunque más sutil que en el jpg. Tenga en cuenta también que esto no es ni de lejos un caso del mundo real, esta prueba es estrictamente de carácter técnico. Usted nunca codificará una imagen como ésta normalmente. Sospecho que mucho de ello tiene que ver con Webp tendencia a difuminar las imágenes en lugar de crear un jpg como el bloqueo, ya que su uso original fue en el video donde la confusión no se notaría junto con el movimiento.
Prueba n º 4 - Alta resolución
Google afirma que webp fue desarrollado para ser un algoritmo de compresión para archivos de baja resolución, por lo que será interesante ver cómo se comporta en una resolución más alta. Erik tuvo la gentileza de proporcionarme algunas de sus imágenes de alta resolución para llevar a cabo esta prueba. Esta toma de exposición larga de noche en 5616 × 3744 (21 MP) es una candidata perfecta para una prueba de alta resolución y una excelente fotografía en sí misma. Yo recomendaría le echara un vistazo a la fuente de resolución de expedientes completos si está interesado en ver los artefactos detallados.
Resultados:
webp:
jpg:
| webp | jpg | |
|---|---|---|
| Resolución: | 5616×3744 | 5616×3744 |
| Calidad: | 562KB | 568KB |
| Diferencia de medias RGB: | 0.7% | 0.8% |
| Diferencia de medias de valor: | 0.6% | 0.8% |
Las imágenes de mayor resolución parece que incluso el campo de juego un poco. Si ve la imagen en tamaño completo, te darás cuenta de que los mayores problemas están en el fondo. Tanto el sombreado y la compresión JPG están presentes si se mira lo suficientemente cerca en el bokeh (desenfoque del fondo), y es más obvio en la banda del cielo nocturno de la versión jpg. Yo diría que los artefactos bokeh se acercan a la par con los demás, pero la banda en el cielo nocturno hace a webp el ganador.
Prueba # 5 - Retrato
Vamos a hacer una pruebacon un caso bastante común en mundo real. Una hermosa imagen de un hombre bien desarrollado con las buenas costumbres, un amor sano de las puertas hacia fuera y esperar ... eh, me refiero a un simple retrato con iluminación decente, un buen enfoque, y un archivo de entrada de tamaño medio. Vamos directos a ella.
Resultados:
webp:
jpg:
| webp | jpg | |
|---|---|---|
| Resolución: | 562×375 | 562×375 |
| Calidad: | 14KB | 14KB |
| Diferencia de medias RGB: | 0.8% | 0.8% |
| Diferencia de medias de valor: | 0.7% | 0.8% |
Al igual que en la imagen de la BMW, ambas versiones tienen artefactos en el fondo desenfocado. Sin embargo, la versión en jpg también en gran medida muestra artefactos de compresión en la cara del sujeto. Curiosamente, webp hizo lo contrario - en lugar de la zona facial, en realidad suavizó la piel en comparación con el original . Mientras que el efecto es bueno en este caso, no estoy seguro de que generalizar lo sea siempre.
Conclusión
En definitiva, yo diría que las afirmaciones de Google son válidas - que es un esquema de compresión que parece superar a jpg. ¿Así que todos debemos saltar del barco y no tocar nunca jpg otra vez? No, absolutamente no. Webp se encuentra en una fase alpha en este momento, y no existe todavía un navegador (o un visor de imágenes para el caso) que lo soporte. También faltan algunas características claves tales como los perfiles de color y canales alfa. Cuando se reúnen esas cosas y añade algunas polaco, que será un fuerte contendiente en el mundo de las imágenes en la web. Sin embargo, aun así, tendrá un largo camino por delante - la compatibilidad hacia atrás es un gran problema aquí, y yo no los veo que se pueda obtener de Microsoft para incluir soporte para bastante tiempo (¿recuerdas el tiempo que tardó para conseguir el apoyo PNG con transparencia alfa por defecto?). Sin embargo, para dispositivos móviles creo que tiene un fuerte caso de negocios - menos datos mediante la página carga más rápido, lo cual es crucial en las conexiones móviles con ancho de banda limitado. Difícil camino por delante de Google no se encuentra en la mejora del algoritmo ya decente, sino en llegar, la comisión aprobó.
No hay comentarios:
Publicar un comentario