Gráficos de red portátiles

Ajustar Compartir Imprimir Citar

Gráficos de red portátiles (PNG, oficialmente pronunciado PING, coloquialmente pronunciado PEE-en-JEE) es un formato de archivo de gráficos de trama que admite la compresión de datos sin pérdidas. PNG se desarrolló como un reemplazo mejorado, no patentado, del formato de intercambio de gráficos (GIF). Extraoficialmente, las iniciales PNG representaban el acrónimo recursivo "PNG's not GIF".

PNG admite imágenes basadas en paletas (con paletas de colores RGB de 24 bits o RGBA de 32 bits), imágenes en escala de grises (con o sin un canal alfa para la transparencia) y RGB o RGBA a todo color no basados en paletas. imágenes El grupo de trabajo de PNG diseñó el formato para transferir imágenes en Internet, no para gráficos impresos de calidad profesional; por lo tanto, no se admiten espacios de color que no sean RGB, como CMYK. Un archivo PNG contiene una sola imagen en una estructura extensible de trozos, codificando los píxeles básicos y otra información como comentarios textuales y controles de integridad documentados en RFC 2083.

Los archivos PNG usan la extensión de archivo PNG o png y se les ha asignado el tipo de medio MIME image/png. PNG se publicó como RFC 2083 informativo en marzo de 1997 y como norma ISO/IEC 15948 en 2004.

Historia y desarrollo

La motivación para crear el formato PNG fue darse cuenta de que, el 28 de diciembre de 1994, Unisys patentó el algoritmo de compresión de datos Lempel-Ziv-Welch (LZW) utilizado en el formato de intercambio de gráficos (GIF). La patente requería que todo el software compatible con GIF pagara regalías, lo que provocó una oleada de críticas por parte de los usuarios de Usenet. Uno de ellos fue Thomas Boutell, quien el 4 de enero de 1995 publicó un hilo de discusión preliminar en el grupo de noticias de Usenet "comp.graphics" en el que ideó un plan para una alternativa gratuita a GIF. Otros usuarios en ese hilo presentaron muchas propuestas que luego serían parte del formato de archivo final. Oliver Fromme, autor del popular visor de JPEG QPEG, propuso el nombre PING, que eventualmente se convirtió en PNG, un acrónimo recursivo que significa PING no es GIF, y también la extensión .png. Otras sugerencias que se implementaron más tarde incluyeron el algoritmo de compresión deflate y la compatibilidad con colores de 24 bits; la falta de este último en GIF también motivó al equipo a crear su formato de archivo. El grupo se conocería como PNG Development Group y, a medida que la discusión se expandió rápidamente, más tarde utilizó una lista de correo asociada con un foro de CompuServe.

La especificación completa de PNG se publicó con la aprobación de W3C el 1 de octubre de 1996 y, posteriormente, como RFC 2083 el 15 de enero de 1997. La especificación se revisó el 31 de diciembre de 1998 como versión 1.1, que abordaba problemas técnicos de gamma y color. corrección. La versión 1.2, lanzada el 11 de agosto de 1999, agregó el fragmento iTXt como único cambio en la especificación, y el 10 de noviembre de 2003 se lanzó una versión reformateada de 1.2 como una segunda edición del estándar W3C., y como norma internacional (ISO/IEC 15948:2004) el 3 de marzo de 2004.

Aunque GIF permite la animación, se decidió que PNG debería ser un formato de imagen única. En 2001, los desarrolladores de PNG publicaron el formato Gráficos de red de múltiples imágenes (MNG), con soporte para animación. MNG logró un soporte de aplicaciones moderado, pero no lo suficiente entre los principales navegadores web y ningún uso entre los diseñadores o editores de sitios web. En 2008, algunos desarrolladores de Mozilla publicaron el formato Animated Portable Network Graphics (APNG) con objetivos similares. APNG es un formato compatible de forma nativa con los navegadores web basados en Gecko y Presto y también se usa comúnmente para miniaturas en el sistema PlayStation Portable de Sony (usando la extensión de archivo PNG normal). En 2017, los navegadores basados en Chromium adoptaron la compatibilidad con APNG. En enero de 2020, Microsoft Edge pasó a estar basado en Chromium, por lo que heredó la compatibilidad con APNG. Con esto, todos los principales navegadores ahora son compatibles con APNG.

Grupo de Trabajo PNG

La especificación PNG original fue creada por un grupo ad hoc de entusiastas y expertos en gráficos por computadora. Las discusiones y decisiones sobre el formato se realizaron por correo electrónico. Los autores originales enumerados en RFC 2083 son:

Formato de archivo

La imagen PNG PNG-Gradient.png visto con una aplicación de editor de hex para Ubuntu.

Encabezado del archivo

Un archivo PNG comienza con una firma de 8 bytes (consulte la imagen del editor hexadecimal a la derecha):

Valores (hex) Propósito
89Tiene el conjunto de bits altos para detectar sistemas de transmisión que no soportan datos de 8 bits y reducir la posibilidad de que un archivo de texto se interprete erróneamente como un PNG, o viceversa.
50 4E 47En ASCII, las cartas PNG, permitiendo a una persona identificar el formato fácilmente si se ve en un editor de texto.
0D 0AUna línea de estilo DOS termina (CRLF) para detectar la conversión final de línea DOS-Unix de los datos.
1AUn byte que detiene la visualización del archivo bajo DOS cuando se ha utilizado el tipo de comando: el carácter final de archivo.
0AUna línea de estilo Unix termina (LF) para detectar la conversión final de línea Unix-DOS.

"Trozos" dentro del archivo

Después del encabezado, viene una serie de fragmentos, cada uno de los cuales transmite cierta información sobre la imagen. Los fragmentos se declaran a sí mismos como críticos o auxiliares, y un programa que encuentra un fragmento auxiliar que no comprende puede ignorarlo con seguridad. Esta estructura de capa de almacenamiento basada en fragmentos, similar en concepto a un formato de contenedor o al IFF de Amiga', está diseñada para permitir que el formato PNG se amplíe manteniendo la compatibilidad con versiones anteriores; proporciona compatibilidad con versiones posteriores, y esta misma estructura de archivo (con diferentes firmas y fragmentos) se usa en los formatos asociados MNG, JNG y APNG.

Un fragmento consta de cuatro partes: longitud (4 bytes, big-endian), tipo/nombre del fragmento (4 bytes), datos del fragmento (bytes de longitud) y CRC (código de redundancia cíclica/suma de comprobación; 4 bytes). El CRC es un CRC-32 de orden de bytes de red calculado sobre el tipo de fragmento y los datos del fragmento, pero no la longitud.

Duración Tipo de torta Datos de tracción CRC
4 bytes 4 bytes Duración bytes 4 bytes

Los tipos de fragmentos reciben un tipo/nombre ASCII de cuatro letras que distingue entre mayúsculas y minúsculas; comparar FourCC. El caso de las diferentes letras en el nombre (bit 5 del valor numérico del carácter) es un campo de bit que proporciona al decodificador cierta información sobre la naturaleza de los fragmentos que no reconoce.

El caso de la primera letra indica si el fragmento es crítico o no. Si la primera letra está en mayúscula, el fragmento es crítico; si no, el trozo es auxiliar. Los fragmentos críticos contienen información necesaria para leer el archivo. Si un decodificador encuentra un fragmento crítico que no reconoce, debe cancelar la lectura del archivo o proporcionar al usuario una advertencia adecuada.

El caso de la segunda letra indica si el fragmento es "público" (ya sea en la especificación o el registro de fragmentos públicos de propósito especial) o "privado" (no estandarizado). Las mayúsculas son públicas y las minúsculas son privadas. Esto garantiza que los nombres de fragmentos públicos y privados nunca entren en conflicto entre sí (aunque dos nombres de fragmentos privados podrían entrar en conflicto).

La tercera letra debe estar en mayúsculas para cumplir con la especificación PNG. Está reservado para futuras ampliaciones. Los decodificadores deben tratar un fragmento con una tercera letra minúscula igual que cualquier otro fragmento no reconocido.

El caso de la cuarta letra indica si el fragmento es seguro para ser copiado por editores que no lo reconozcan. Si está en minúsculas, el fragmento se puede copiar de forma segura independientemente del alcance de las modificaciones en el archivo. Si está en mayúsculas, solo se puede copiar si las modificaciones no han tocado ningún fragmento crítico.

Porciones críticas

Un decodificador debe poder interpretar fragmentos críticos para leer y representar un archivo PNG.

Como se indica en el World Wide Web Consortium, la profundidad de bits se define como "la cantidad de bits por muestra o por índice de paleta (no por píxel)".

La porción PLTE es esencial para el tipo de color 3 (color indexado). Es opcional para los tipos de color 2 y 6 (truecolor y truecolor con alfa) y no debe aparecer para los tipos de color 0 y 4 (escala de grises y escala de grises con alfa).

Porciones auxiliares

Otros atributos de imagen que se pueden almacenar en archivos PNG incluyen valores gamma, color de fondo e información de metadatos textuales. PNG también admite la gestión del color mediante la inclusión de perfiles de color ICC.

La primera letra minúscula de estos fragmentos indica que no son necesarios para la especificación PNG. La última letra minúscula en algunos fragmentos indica que es seguro copiarlos, incluso si la aplicación en cuestión no los comprende.

Formato de píxeles

Combinaciones de tipo de color y profundidad de bits
Tipo de color Canales Bits por canal
124816
Índice 1 1248
Grayscale 1 124816
Grayscale y alfa 2 1632
Truecolor 3 2448
Truecolor y alfa 4 3264

Los píxeles en las imágenes PNG son números que pueden ser índices de datos de muestra en la paleta o los datos de muestra en sí. La paleta es una tabla separada contenida en el fragmento PLTE. Los datos de muestra para un solo píxel consisten en una tupla de entre uno y cuatro números. Ya sea que los datos de píxeles representen índices de paleta o valores de muestra explícitos, los números se denominan canales y cada número en la imagen se codifica con un formato idéntico.

Los formatos permitidos codifican cada número como un valor entero sin signo utilizando un número fijo de bits, denominado en la especificación PNG como profundidad de bits. Tenga en cuenta que esto no es lo mismo que la profundidad de color, que se usa comúnmente para referirse al número total de bits en cada píxel, no en cada canal. Las profundidades de bits permitidas se resumen en la tabla junto con el número total de bits utilizados para cada píxel.

El número de canales depende de si la imagen es en escala de grises o en color y si tiene un canal alfa. PNG permite las siguientes combinaciones de canales, denominadas tipo de color.

Una demostración de la profundidad de color en un archivo PNG, en bits por canal. Izquierda: 8 bits, derecha: 16 bits. Tenga en cuenta los artefactos, contraste ajustado para la claridad.
0 (000)2)grayscale
2 (0102)rojo, verde y azul: rgb/truecolor
3 (0112)indexado: canal que contiene índices en una paleta de colores
4 (100)2)grayscale y alfa: nivel de opacidad para cada pixel
6 (110)2)rojo, verde, azul y alfa

El tipo de color se especifica como un valor de 8 bits; sin embargo, solo se utilizan los 3 bits inferiores y, aun así, solo se permiten las cinco combinaciones enumeradas anteriormente. Siempre que el tipo de color sea válido, se puede considerar como un campo de bits, como se resume en la tabla adyacente:

Tipos de color PNG
Color
Tipo
Nombre binario Máscaras
ACP
0Grayscale 0000
2Truecolor 0010 color
3Índice 0011 color, paleta
4Grayscale y alfa 0100 alfa
6Truecolor y alfa 0110 alfa, color

Con imágenes de color indexadas, la paleta siempre almacena colores tricromáticos a una profundidad de 8 bits por canal (24 bits por entrada de paleta). Además, se puede incluir una lista opcional de valores alfa de 8 bits para las entradas de la paleta; si no se incluye, o si es más corto que la paleta, se supone que las entradas restantes de la paleta son opacas. La paleta no debe tener más entradas de las que permite la profundidad de bits de la imagen, pero puede tener menos (por ejemplo, si una imagen con píxeles de 8 bits solo usa 90 colores, entonces no necesita entradas de paleta para los 256 colores). La paleta debe contener entradas para todos los valores de píxeles presentes en la imagen.

El estándar permite que los PNG de color indexados tengan 1, 2, 4 u 8 bits por píxel; las imágenes en escala de grises sin canal alfa pueden tener 1, 2, 4, 8 o 16 bits por píxel. Todo lo demás usa una profundidad de bits por canal de 8 o 16. Las combinaciones que esto permite se dan en la tabla anterior. El estándar requiere que los decodificadores puedan leer todos los formatos de color admitidos, pero muchos editores de imágenes solo pueden producir un pequeño subconjunto de ellos.

Transparencia de imagen

PNG ofrece una variedad de opciones de transparencia. Con imágenes de color verdadero y escala de grises, se puede declarar un solo valor de píxel como transparente o se puede agregar un canal alfa (lo que permite usar cualquier porcentaje de transparencia parcial). Para las imágenes con paleta, se pueden agregar valores alfa a las entradas de la paleta. El número de dichos valores almacenados puede ser menor que el número total de entradas de la paleta, en cuyo caso las entradas restantes se consideran totalmente opacas.

Se supone que el escaneo de los valores de píxeles para la transparencia binaria debe realizarse antes de cualquier reducción de color para evitar que los píxeles se vuelvan transparentes involuntariamente. Lo más probable es que esto plantee un problema para los sistemas que pueden decodificar imágenes de 16 bits por canal (como se requiere para cumplir con la especificación) pero solo emiten a 8 bits por canal (la norma para todos excepto los sistemas de gama alta).

Almacenamiento alfa se puede "asociar" ("premultiplicado") o "no asociado", pero PNG estandarizado en "no asociado" ("no premultiplicado") alfa, lo que significa que las imágenes no están codificadas en alfa; las emisiones representadas en RGB no son las emisiones a nivel de píxel. Esto significa que la sobreoperación multiplicará las emisiones RGB por el alfa y no puede representar la emisión y la oclusión correctamente.

Compresión

Ejemplo con varios tipos de contenido de imagen
Representación del costo del bit por píxel por encima del archivo PNG (red=expensive, blue=cheap)

PNG utiliza un proceso de compresión de dos etapas:

PNG utiliza DEFLATE, un algoritmo de compresión de datos sin pérdidas no patentado que implica una combinación de codificación LZ77 y Huffman. Las implementaciones DEFLATE con licencia permisiva, como zlib, están ampliamente disponibles.

En comparación con los formatos con compresión con pérdida, como JPEG, elegir una configuración de compresión más alta que el promedio retrasa el procesamiento, pero a menudo no da como resultado un tamaño de archivo significativamente más pequeño.

Filtrado

El método filtrante de PNG 0 puede utilizar los datos en píxeles A, B y C para predecir el valor de X.
Un PNG con 256 colores, que es sólo 251 bytes grandes con pre-filtro. La misma imagen que un GIF sería más de trece veces mayor.

Antes de aplicar DEFLATE, los datos se transforman a través de un método de predicción: se usa un único método de filtro para toda la imagen, mientras que para cada línea de imagen, un tipo de filtro se elige para transformar los datos para hacerlos más eficientemente comprimibles. El tipo de filtro utilizado para una línea de exploración se antepone a la línea de exploración para habilitar la descompresión en línea.

Solo hay un método de filtro en la especificación PNG actual (indicado como método 0) y, por lo tanto, en la práctica, la única opción es qué tipo de filtro aplicar a cada línea. Para este método, el filtro predice el valor de cada píxel en función de los valores de los píxeles vecinos anteriores y resta el color predicho del píxel del valor real, como en DPCM. Una línea de imagen filtrada de esta manera a menudo es más comprimible que la línea de imagen sin procesar, especialmente si es similar a la línea anterior, ya que las diferencias de la predicción generalmente se agruparán alrededor de 0, en lugar de distribuirse entre todos los valores de imagen posibles. Esto es particularmente importante al relacionar filas separadas, ya que DEFLATE no comprende que una imagen es una entidad 2D y, en cambio, solo ve los datos de la imagen como un flujo de bytes.

Hay cinco tipos de filtro para el método de filtro 0; cada tipo predice el valor de cada byte (de los datos de la imagen antes del filtrado) en función del byte correspondiente del píxel de la izquierda (A), el píxel de arriba (B), y el píxel arriba ya la izquierda (C) o alguna combinación de los mismos, y codifica la diferencia entre el valor predicho y el valor real. Los filtros se aplican a valores de bytes, no a píxeles; los valores de píxel pueden ser uno o dos bytes, o varios valores por byte, pero nunca cruzar los límites de byte. Los tipos de filtro son:

Tipo byteNombre del filtroValor predecido
0NingunoCero (para que el valor de byte crudo pase sin alterar)
1SubsidioByte A (a la izquierda)
2ArribaByte B (arriba)
3PromedioSignificado de bytes A y B, redondeado
4PaethA, B, o C, lo que sea más cercano a p = A + BC

El filtro Paeth se basa en un algoritmo de Alan W. Paeth. Compare con la versión de DPCM utilizada en JPEG sin pérdida y con la transformada de wavelet discreta usando ventanas de 1 × 2, 2 × 1 o (para el predictor de Paeth) 2 × 2 y wavelets de Haar.

La compresión se mejora aún más al elegir los tipos de filtro de forma adaptativa línea por línea. Esta mejora, y un método heurístico para implementarla comúnmente utilizado por el software de escritura PNG, fueron creados por Lee Daniel Crocker, quien probó los métodos en muchas imágenes durante la creación del formato; la elección del filtro es un componente de la optimización del tamaño del archivo, como se explica a continuación.

Si se utiliza el entrelazado, cada etapa del entrelazado se filtra por separado, lo que significa que la imagen se puede renderizar progresivamente a medida que se recibe cada etapa; sin embargo, el entrelazado generalmente hace que la compresión sea menos efectiva.

Entrelazado

Una ilustración de Adam7 entrelazando sobre una imagen de 16×16.

PNG ofrece un esquema de entrelazado bidimensional de 7 pasos opcional: el algoritmo Adam7. Esto es más sofisticado que el esquema de 4 pasos unidimensional de GIF y permite que una imagen de baja resolución más clara sea visible antes en la transferencia, especialmente si se utilizan algoritmos de interpolación como la interpolación bicúbica.

Sin embargo, el esquema de 7 pasos tiende a reducir la compresibilidad de los datos más que los esquemas más simples.

Animación

Un archivo APNG (animado PNG) (displays como imagen estática en algunos navegadores web)

PNG en sí mismo no admite animación. MNG es una extensión de PNG que lo hace; fue diseñado por miembros del Grupo PNG. MNG comparte la estructura y los fragmentos básicos de PNG, pero es significativamente más complejo y tiene una firma de archivo diferente, lo que automáticamente lo vuelve incompatible con los decodificadores PNG estándar. Esto significa que la mayoría de los navegadores web y las aplicaciones nunca admitieron MNG o dejaron de admitirlo.

La complejidad de MNG llevó a la propuesta de APNG por parte de los desarrolladores de la Fundación Mozilla. Se basa en PNG, admite animación y es más simple que MNG. APNG ofrece un respaldo a la visualización de una sola imagen para los decodificadores PNG que no admiten APNG. Hoy en día, el formato APNG es compatible con todos los principales navegadores web. APNG es compatible con Firefox 3.0 y versiones posteriores, Pale Moon (todas las versiones) y Safari 8.0 y versiones posteriores. Chromium 59.0 agregó compatibilidad con APNG, seguida de Google Chrome. Opera admitía APNG en las versiones 10 a 12.1, pero el soporte caducó en la versión 15 cuando cambió al motor de renderizado Blink; el soporte se volvió a agregar en Opera 46 (heredado de Chromium 59). Microsoft Edge es compatible con APNG desde la versión 79.0, cuando cambió a un motor basado en Chromium.

El Grupo PNG decidió en abril de 2007 no adoptar APNG. Se discutieron varias alternativas, incluidas ANG, aNIM/mPNG, "PNG en GIF" y su subconjunto "RGBA en GIF". Sin embargo, actualmente solo APNG tiene un amplio apoyo.

Ejemplos

Estructura de un archivo PNG muy simple
89 50 4E 47 0D 0A 1A 0A
PNG signature
IHDR
encabezado de imagen
IDAT
Datos de imagen
IEND
Final de la imagen
Contenido de un archivo PNG mínimo que representa un píxel rojo
Hex Como personajes

89 50 4E 47 0D 0A 1A 0A 00 00 00 00 0D 49 48 44 52
00 00 00 00 01 00 00 01 08 02 00 00 00 00 90 77 53
DE 00 00 00 00 10 49 44 41 54 08 D7 63 F8 CF C0 00
00 03 01 00 18 DD 8D B0 00 00 00 00 00 49 45 4E
44 AE 42 60 82

. PNG.......IHDR
......
....
......
D.B.

IHDR Chunk
Offset en chunk Valor Hex Valor decimal Texto Significado
0 0x0D 13 El trozo de IHDR tiene 13 bytes de contenido
4 0x49484452 IHDR Identifica un pedazo de cabecera
8 0x01 1 Imagen 1 píxel ancho
12 0x01 1 Imagen es 1 pixel alto
16 0x08 8 8 bits por pixel (por canal)
17 0x02 2 Color tipo 2 (RGB/truecolor)
18 0x00 0 Método de compresión 0 (valor solo aceptado)
19 0x00 0 Método de filtro 0 (valor solo aceptado)
20 0x00 0 No se entrelazó
21 0x907753DE CRC del tipo y el contenido del trozo (pero no la longitud)
IDAT Chunk
Offset en chunk Valor Hex Significado
0 0x10 IDAT chunk tiene 16 bytes de contenido
4 0x49444154 Identifica un fragmento de datos
8 0x08 Método de compresión DEFLATE utilizando una ventana de 256 bytes
9 0xD7 Valor ZLIB FCHECK, sin diccionario utilizado, algoritmo de compresión máxima
10 0x63F8CFC00000 Un bloque DEFLATE comprimido usando el código estático Huffman que decodifica a 0x00 0xFF 0x00 0x00
16 0x03010100 El valor de verificación ZLIB: la suma de comprobación Adler32 de los datos no comprimidos
20 0x18DD8DB0 CRC del tipo y el contenido del trozo (pero no la longitud)

Se muestra a la manera de los editores hexadecimales, con valores de byte en el lado izquierdo que se muestran en formato hexadecimal, y en el lado derecho sus caracteres equivalentes de ISO-8859-1 con caracteres de control y no reconocidos reemplazados por puntos. Además, la firma PNG y los fragmentos individuales están marcados con colores. Tenga en cuenta que son fáciles de identificar debido a sus nombres de tipos legibles por humanos (en este ejemplo, PNG, IHDR, IDAT e IEND).

Ventajas

Las razones para usar esta Norma Internacional pueden ser:

Comparación con otros formatos de archivo

Formato de intercambio de gráficos (GIF)

Las imágenes PNG son menos compatibles con los navegadores más antiguos. En particular, IE6 tiene soporte limitado para PNG.

JPEG

Imagen compuesta que compara la compresión perdida en JPEG con compresión sin pérdidas en PNG: los artefactos JPEG pueden ser fácilmente visibles en el fondo de este tipo de datos de imagen, donde la imagen PNG tiene un color sólido.

El formato JPEG (Grupo conjunto de expertos en fotografía) puede producir un archivo más pequeño que PNG para imágenes fotográficas (y similares a fotografías), ya que JPEG utiliza un método de codificación con pérdida diseñado específicamente para datos de imágenes fotográficas, que suele estar dominado por transiciones de bajo contraste y una cantidad de ruido o estructuras irregulares similares. El uso de PNG en lugar de JPEG de alta calidad para tales imágenes daría como resultado un gran aumento en el tamaño del archivo con una ganancia insignificante en calidad. En comparación, cuando se almacenan imágenes que contienen texto, arte lineal o gráficos (imágenes con transiciones nítidas y grandes áreas de color sólido), el formato PNG puede comprimir los datos de la imagen más que JPEG. Además, PNG no tiene pérdidas, mientras que JPEG produce artefactos visuales alrededor de áreas de alto contraste. (Dichos artefactos dependen de la configuración utilizada en la compresión JPG; pueden ser bastante perceptibles cuando se utiliza una configuración de baja calidad [alta compresión].) Cuando una imagen contiene transiciones nítidas y partes fotográficas, se debe elegir entre los dos efectos. JPEG no admite transparencia.

La compresión con pérdida de JPEG también sufre la pérdida de generación, donde la decodificación y recodificación repetidas de una imagen para guardarla nuevamente provoca una pérdida de información cada vez, degradando la imagen. Debido a que PNG no tiene pérdidas, es adecuado para almacenar imágenes para editar. Si bien PNG es razonablemente eficiente cuando se comprimen imágenes fotográficas, existen formatos de compresión sin pérdidas diseñados específicamente para imágenes fotográficas, WebP sin pérdidas y Adobe DNG (negativo digital), por ejemplo. Sin embargo, estos formatos no son ampliamente compatibles o son propietarios. Una imagen puede almacenarse sin pérdidas y convertirse a formato JPEG solo para su distribución, de modo que no haya pérdida de generación.

Si bien la especificación PNG no incluye explícitamente un estándar para incrustar datos de imagen Exif de fuentes como cámaras digitales, el método preferido para incrustar datos EXIF en un PNG es utilizar la etiqueta de fragmento auxiliar no crítica eXIf< /código>.

Los primeros navegadores web no admitían imágenes PNG; JPEG y GIF fueron los principales formatos de imagen. JPEG se usaba comúnmente al exportar imágenes que contenían degradados para páginas web, debido a la profundidad de color limitada de GIF. Sin embargo, la compresión JPEG hace que un degradado se desenfoque ligeramente. Un formato PNG reproduce un degradado con la mayor precisión posible para una profundidad de bits determinada, manteniendo un tamaño de archivo pequeño. PNG se convirtió en la opción óptima para imágenes con gradientes pequeños a medida que mejoró la compatibilidad del navegador web con el formato. No se necesitan imágenes para mostrar gradientes en los navegadores modernos, ya que los gradientes se pueden crear usando CSS.

JPEG-LS

JPEG-LS es un formato de imagen creado por el Joint Photographic Experts Group, aunque es mucho menos conocido y admitido que el otro formato JPEG con pérdida mencionado anteriormente. Es directamente comparable con PNG y tiene un conjunto estándar de imágenes de prueba. En el Waterloo Repertoire ColorSet, un conjunto estándar de imágenes de prueba (no relacionado con el conjunto de pruebas de conformidad JPEG-LS), JPEG-LS generalmente funciona mejor que PNG, en un 10-15%, pero en algunas imágenes PNG funciona sustancialmente mejor, en el orden de 50-75%. Por lo tanto, si ambos formatos son opciones y el tamaño del archivo es un criterio importante, se deben considerar ambos, dependiendo de la imagen.

TIFF

El formato de archivo de imagen etiquetada (TIFF) es un formato que incorpora una gama extremadamente amplia de opciones. Si bien esto hace que TIFF sea útil como un formato genérico para el intercambio entre aplicaciones profesionales de edición de imágenes, hace que agregar soporte a las aplicaciones sea una tarea mucho más grande y, por lo tanto, tiene poco soporte en aplicaciones que no se ocupan de la manipulación de imágenes (como los navegadores web). El alto nivel de extensibilidad también significa que la mayoría de las aplicaciones proporcionan solo un subconjunto de funciones posibles, lo que puede generar confusión en el usuario y problemas de compatibilidad.

El algoritmo de compresión sin pérdidas de propósito general más común que se usa con TIFF es Lempel-Ziv-Welch (LZW). Esta técnica de compresión, que también se usa en GIF, estuvo protegida por patentes hasta 2003. TIFF también es compatible con el algoritmo de compresión que usa PNG (es decir, la etiqueta de compresión 000816 'estilo Adobe') con un uso medio y soporte de aplicaciones. TIFF también ofrece algoritmos de compresión sin pérdidas para propósitos especiales, como CCITT Group IV, que puede comprimir imágenes de dos niveles (por ejemplo, faxes o texto en blanco y negro) mejor que el algoritmo de compresión PNG.

PNG solo admite alfa no premultiplicado, mientras que TIFF también admite archivos "asociados" (premultiplicado) alfa.

Soporte de software

La implementación de referencia oficial del formato PNG es la biblioteca de programación libpng. Se publica como software libre bajo los términos de una licencia permisiva de software libre. Por lo tanto, generalmente se encuentra como una biblioteca de sistema importante en los sistemas operativos libres.

Compatibilidad con el editor de gráficos de mapa de bits para PNG

El formato PNG es ampliamente compatible con programas gráficos, incluidos Adobe Photoshop, Corel's Photo-Paint y Paint Shop Pro, GIMP, GraphicConverter, Helicon Filter, ImageMagick, Inkscape, IrfanView, Pixel image editor, Paint. NET y Xara Photo & Diseñador Gráfico y muchos otros. Algunos programas incluidos con los sistemas operativos populares que admiten PNG incluyen Microsoft's Paint y Apple's Photos/iPhoto and Preview, y GIMP también se incluye a menudo con las distribuciones populares de Linux.

Adobe Fireworks (anteriormente por Macromedia) utiliza PNG como su formato de archivo nativo, lo que permite que otros editores de imágenes y utilidades de vista previa vean la imagen plana. Sin embargo, Fireworks también almacena metadatos de forma predeterminada para capas, animaciones, datos vectoriales, texto y efectos. Dichos archivos no deben distribuirse directamente. En cambio, Fireworks puede exportar la imagen como PNG optimizado sin los metadatos adicionales para usar en páginas web, etc.

Soporte de navegador web para PNG

La compatibilidad con PNG apareció por primera vez en 1997, en Internet Explorer 4.0b1 (32 bits solo para NT) y en Netscape 4.04.

A pesar de las llamadas de la Free Software Foundation y el World Wide Web Consortium (W3C), herramientas como gif2png y campañas como Burn All GIFs, la adopción de PNG en los sitios web fue bastante lenta debido a la compatibilidad tardía y con errores en Internet Explorer. particularmente en lo que respecta a la transparencia.

Los navegadores compatibles con PNG incluyen: Apple Safari, Google Chrome, Mozilla Firefox, Opera, Camino, Internet Explorer 7 (todavía numerosos problemas), Internet Explorer 8 (todavía algunos problemas), Internet Explorer 9 y muchos otros. Para ver la comparación completa, consulte Comparación de navegadores web (compatibilidad con formato de imagen).

Especialmente, las versiones de Internet Explorer (Windows) anteriores a la 9.0 (lanzadas en 2011) tienen numerosos problemas que impiden que se representen correctamente las imágenes PNG.

Soporte del sistema operativo para iconos PNG

Los íconos PNG han sido compatibles con la mayoría de las distribuciones de Linux desde al menos 1999, en entornos de escritorio como GNOME. En 2006, se introdujo en Windows Vista la compatibilidad con iconos PNG de Microsoft Windows. Los iconos PNG también son compatibles con AmigaOS 4, AROS, macOS, iOS y MorphOS. Además, Android hace un uso extensivo de PNG.

Tamaño de archivo y software de optimización

El tamaño del archivo PNG puede variar significativamente dependiendo de cómo esté codificado y comprimido; esto se discute y se dan varios consejos en PNG: La guía definitiva.

Comparado con GIF

En comparación con los archivos GIF, un archivo PNG con la misma información (256 colores, sin fragmentos ni metadatos auxiliares), comprimido con un compresor eficaz, normalmente es más pequeño que una imagen GIF. Según el archivo y el compresor, PNG puede variar desde algo más pequeño (10 %) a significativamente más pequeño (50 %) o algo más grande (5 %), pero rara vez es significativamente más grande para imágenes grandes. Esto se atribuye al rendimiento de DEFLATE de PNG en comparación con LZW de GIF, y porque la capa de precompresión agregada de los filtros predictivos de PNG tiene en cuenta la estructura de imagen bidimensional para comprimir aún más los archivos; Como los datos filtrados codifican diferencias entre píxeles, tenderán a agruparse más cerca de 0, en lugar de distribuirse entre todos los valores posibles y, por lo tanto, DEFLATE los comprimirá más fácilmente. Sin embargo, algunas versiones de Adobe Photoshop, CorelDRAW y MS Paint brindan una compresión PNG deficiente, lo que crea la impresión de que GIF es más eficiente.

Factores de tamaño de archivo

Los archivos PNG varían en tamaño debido a varios factores:

profundidad de color
La profundidad de color puede variar de 1 a 64 bits por pixel.
trocitos auxiliares
PNG admite metadatos, esto puede ser útil para la edición, pero innecesario para la visualización, como en sitios web.
interlacionamiento
Como cada paso del algoritmo Adam7 se filtra por separado, esto puede aumentar el tamaño del archivo.
filtro
Como etapa de precompresión, cada línea es filtrada por un filtro predictivo, que puede cambiar de línea a línea. A medida que el último paso DEFLATE opera en los datos filtrados de toda la imagen, no se puede optimizar esta fila por hoja; la elección de filtro para cada fila es por lo tanto potencialmente muy variable, aunque existen heurísticas.
compresión
Con computación adicional, los compresores DEFLATE pueden producir archivos más pequeños.

Por lo tanto, existe una compensación de tamaño de archivo entre alta profundidad de color, metadatos máximos (incluida la información del espacio de color, junto con información que no afecta la visualización), entrelazado y velocidad de compresión, que producen archivos grandes, con menos color. profundidad, menos o ningún fragmento auxiliar, sin entrelazado y filtrado y compresión ajustados pero computacionalmente intensivos. Para diferentes propósitos, se eligen diferentes compensaciones: un archivo máximo puede ser mejor para archivar y editar, mientras que un archivo simplificado puede ser mejor para usar en un sitio web, y de manera similar, se prefiere una compresión rápida pero pobre cuando se edita y guarda repetidamente un archivo. mientras que se prefiere una compresión lenta pero alta cuando un archivo es estable: al archivar o publicar. El entrelazado es una compensación: acelera drásticamente la renderización temprana de archivos grandes (mejora la latencia), pero puede aumentar el tamaño del archivo (disminuir el rendimiento) con poca ganancia, especialmente para archivos pequeños.

Compresión PNG con pérdida

Aunque PNG es un formato sin pérdidas, los codificadores de PNG pueden preprocesar datos de imágenes con pérdidas para mejorar la compresión PNG. Por ejemplo, cuantificar un PNG de color verdadero a 256 colores permite usar el tipo de color indexado para una probable reducción del tamaño del archivo.

Software de edición de imágenes

Algunos programas son más eficientes que otros al guardar archivos PNG, esto se relaciona con la implementación de la compresión PNG utilizada por el programa.

Muchos programas de gráficos (como el software de vista previa de Apple) guardan archivos PNG con grandes cantidades de metadatos y datos de corrección de color que generalmente no son necesarios para la visualización web. Los archivos PNG no optimizados de Adobe Fireworks también son notorios por esto, ya que contienen opciones para hacer que la imagen sea editable en editores compatibles. Además, CorelDRAW (al menos la versión 11) a veces produce archivos PNG que Internet Explorer no puede abrir (versiones 6 a 8).

El rendimiento de Adobe Photoshop en archivos PNG ha mejorado en CS Suite cuando se utiliza la función Guardar para Web (que también permite el uso explícito de PNG/8).

Adobe's Fireworks guarda archivos PNG más grandes que muchos programas de forma predeterminada. Esto se deriva de la mecánica de su formato Guardar: las imágenes producidas por Fireworks' La función de guardar incluye fragmentos grandes y privados que contienen información completa de capas y vectores. Esto permite una mayor edición sin pérdidas. Cuando se guarda con la opción Exportar, Fireworks' Los PNG son competitivos con los producidos por otros editores de imágenes, pero ya no se pueden editar como nada más que mapas de bits aplanados. Fireworks no puede guardar archivos PNG editables con vectores de tamaño optimizado.

Otros ejemplos notables de compresores PNG deficientes incluyen:

La mala compresión aumenta el tamaño del archivo PNG pero no afecta la calidad de la imagen ni la compatibilidad del archivo con otros programas.

Cuando la profundidad de color de una imagen de color verdadero se reduce a una paleta de 8 bits (como en GIF), los datos de la imagen resultante suelen ser mucho más pequeños. Por lo tanto, un PNG de color verdadero suele ser más grande que un GIF de color reducido, aunque PNG podría almacenar la versión de color reducido como un archivo paletizado de tamaño comparable. Por el contrario, algunas herramientas, al guardar imágenes como PNG, las guardan automáticamente como color verdadero, incluso si los datos originales usan solo color de 8 bits, lo que infla el archivo innecesariamente. Ambos factores pueden llevar a la idea errónea de que los archivos PNG son más grandes que los archivos GIF equivalentes.

Herramientas de optimización

Hay varias herramientas disponibles para optimizar los archivos PNG; hacen esto por:

Lista de herramientas

A continuación se muestra una comparación simple de sus características.

OptimizadorRetiradaReducción del colorFiltroReutilización del filtroMúltiples ensayos en filtros en una sola carreraDeflater
advpngSí.No0NoN/A(multiple)
advdefNoNoReutiliza el filtro anteriorSiempreN/A(multiple)
pngcrushSí.Sí.0-4 o adaptableNoSí.zlib
PngoutSí.Sí.0-4 o adaptableSí.Nokzip
zopflipngSí.Sí.0-4 o adaptable con 2 algoritmos diferentes, o con una forma brutaSí.Sí.zopfli

Antes de que zopflipng estuviera disponible, una buena manera práctica de realizar una optimización de png es usar una combinación de 2 herramientas en secuencia para una compresión óptima: una que optimiza los filtros (y elimina fragmentos auxiliares) y otra que optimiza DEFLATE. Aunque pngout ofrece ambos, solo se puede especificar un tipo de filtro en una sola ejecución, por lo tanto, se puede usar con una herramienta de envoltura o en combinación con pngcrush, actuando como un desinflador, como advdef.

Eliminación de fragmentos auxiliares

Para eliminar fragmentos auxiliares, la mayoría de las herramientas de optimización de PNG tienen la capacidad de eliminar todos los datos de corrección de color de los archivos PNG (gamma, balance de blancos, perfil de color ICC, perfil de color RGB estándar). Esto a menudo da como resultado tamaños de archivo mucho más pequeños. Por ejemplo, las siguientes opciones de línea de comando logran esto con pngcrush:

pngcrush -rem gAMA -rem cHRM -rem iCCP -rem sRGB InputFile.png OutputFile.png

Optimización de filtros

pngcrush, pngout y zopflipng ofrecen opciones que aplican uno de los tipos de filtro 0–4 globalmente (usando el mismo tipo de filtro para todas las líneas) o con un "pseudofiltro" (numerado 5), que para cada línea elige uno de los tipos de filtro 0–4 utilizando un algoritmo adaptativo. Zopflipng ofrece 3 métodos adaptativos diferentes, incluida una búsqueda de fuerza bruta que intenta optimizar el filtrado.

pngout y zopflipng brindan una opción para conservar/reutilizar el conjunto de filtros línea por línea presente en la imagen de entrada.

pngcrush y zopflipng brindan opciones para probar diferentes estrategias de filtro en una sola ejecución y elegir la mejor. La versión gratuita de línea de comandos de pngout no ofrece esto, pero la versión comercial, pngoutwin, sí.

Optimización DEFLATE

Zopfli y LZMA SDK brindan implementaciones DEFLATE que pueden producir índices de compresión más altos que la implementación de referencia zlib a costa del rendimiento. advpng y advdef de AdvanceCOMP pueden usar cualquiera de estas bibliotecas para volver a comprimir archivos PNG. Además, PNGOUT contiene su propia implementación DEFLATE patentada.

advpng no tiene una opción para aplicar filtros y siempre usa el filtro 0 globalmente (dejando los datos de la imagen sin filtrar); por lo tanto, no debe usarse cuando la imagen se beneficia significativamente del filtrado. Por el contrario, advdef del mismo paquete no se ocupa de la estructura PNG y actúa solo como un desinflador, conservando cualquier configuración de filtro existente.

Optimización de iconos

Dado que los íconos diseñados para Windows Vista y versiones posteriores pueden contener subimágenes PNG, las optimizaciones también se pueden aplicar a ellos. Al menos un editor de íconos, Pixelformer, puede realizar un pase de optimización especial mientras guarda archivos ICO, reduciendo así su tamaño. FileOptimizer (mencionado anteriormente) también puede manejar archivos ICO.

Los iconos para macOS también pueden contener subimágenes PNG, pero no existe tal herramienta disponible.

Notas explicativas

  1. ^ El filtrado se utiliza para aumentar la similitud con los datos, aumentando así la relación de compresión. Sin embargo, teóricamente no hay fórmula para la similitud, ni relación absoluta entre la similitud y el compresor, por lo tanto, a menos que se haga la compresión, no se puede decir un conjunto de filtros es mejor que otro.
  2. ^ a b c d Utilice pngout -f6 para reutilizar el filtro anterior conjunto
  3. ^ Las herramientas que ofrecen tal característica podrían actuar como un re-deflater puro a los archivos PNG.
  4. ^ zlib, la aplicación desinflada de referencia, la compresión es suboptimal incluso al nivel máximo. Ver Zopfli, formato zip en 7-zip y pngout.
  5. ^ No sólo advpng no soporta la reducción del color, también falla en imágenes con un espacio de color reducido.
  6. ^ Advpng sólo puede aplicar el filtro 0 globalmente, por lo que no es sí o no, pero N/A.
  7. ^ [pngcrush imperpngout] -f OR zopflipng --filters
  8. ^ zopflipng --filters=p
  9. ^ El diálogo de configuración de Pngoutwin para la optimización ofrece al usuario una selección de estrategias de filtro.