Gráficos de red portátiles

format_list_bulleted Contenido keyboard_arrow_down
ImprimirCitar

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:

  • Editor: Thomas Boutell
  • Distribuidor: Tom Lane
  • Autores (en orden alfabético por apellido): Mark Adler, Thomas Boutell, Christian Brunschen, Adam M. Costello, Lee Daniel Crocker, Andreas Dilger, Oliver Fromme, Jean-loup Gailly, Chris Herborth, Aleks Jakulin, Neal Kettler, Tom Lane, Alexander Lehmann, Chris Lilley, Dave Martindale, Owen Mortensen, Keith S. Pickens, Robert P.

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.

  • IHDR debe ser el primer trozo; contiene (en este orden) la imagen
    • ancho (4 bytes)
    • altura (4 bytes)
    • profundidad de bit (1 byte, valores 1, 2, 4, 8 o 16)
    • tipo de color (1 byte, valores 0, 2, 3, 4 o 6)
    • método de compresión (1 byte, valor 0)
    • método de filtro (1 byte, valor 0)
    • método interlace (1 byte, valores 0 "no interlace" o 1 "Adam7 interlace") (13 bytes de datos totales).

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)".

  • PLTE contiene la paleta: una lista de colores.
  • IDAT contiene la imagen, que puede dividirse entre múltiples pedazos de IDAT. Tal división aumenta el tamaño de archivos ligeramente, pero hace posible generar un PNG de una manera de streaming. El trozo IDAT contiene los datos de imagen reales, que es el flujo de salida del algoritmo de compresión.
  • IEND marca el extremo de la imagen; el campo de datos del trozo IEND tiene 0 bytes/es vacío.

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.

  • bKGD da el color de fondo predeterminado. Está pensado para su uso cuando no hay mejor opción disponible, como en los espectadores de imagen independientes (pero no navegadores web; ver a continuación para más detalles).
  • cHRM da las coordenadas de cromaticidad de la pantalla primaries y punto blanco.
  • dSIG es para almacenar firmas digitales.
  • eXIf tiendas Exif metadata.
  • gAMA especifica gamma. El trozo de gAMA contiene sólo 4 bytes, y su valor representa el valor gamma multiplicado por 100.000; por ejemplo, el valor gamma 1/3.4 calcula a 29411.7647059 ((1/3.4)*(100,000) y se convierte en un entero (29412) para almacenamiento.
  • hIST puede almacenar el histograma, o la cantidad total de cada color en la imagen.
  • iCCP es un perfil de color ICC.
  • iTXt contiene una palabra clave y texto UTF-8, con codificación para la posible compresión y traducciones marcadas con etiqueta de lenguaje. La plataforma de metadatos extensibles (XMP) utiliza este trozo con una palabra clave 'XML:com.adobe.xmp '
  • pHYs mantiene el tamaño de píxel previsto (o relación de aspecto píxel); el pHY contiene "Pixels por unidad, eje X" (4 bytes), "Pixels por unidad, eje Y" (4 bytes), y "Especificador Unit" (1 byte) por un total de 9 bytes.
  • sBIT (bits significativos) indica la exactitud del color de los datos fuente; este trozo contiene un total de entre 1 y 5 bytes, dependiendo del tipo de color.
  • sPLT sugiere una paleta para usar si la gama completa de colores no está disponible.
  • sRGB indica que se utiliza el espacio estándar de color sRGB; el trozo sRGB contiene sólo 1 byte, que se utiliza para "render la intención" (4 valores —0, 1, 2, y 3— se definen para la intención de renderizar).
  • sTER indicador de imagen estéreo para imágenes estereoscópicas.
  • tEXt puede almacenar texto que se puede representar en ISO/IEC 8859-1, con un par de valor clave para cada pedazo. El "key" debe tener entre 1 y 79 caracteres de largo. El separador es un personaje nulo. El "valor" puede ser cualquier longitud, incluyendo cero hasta el tamaño máximo permisible del trozo menos la longitud de la palabra clave y separador. Ni "key" ni "valor" pueden contener carácter nulo. También se disuelven los espacios de dirección o de seguimiento.
  • tIME almacena el tiempo que la imagen fue cambiada por última vez.
  • tRNS contiene información de transparencia. Para imágenes indexadas, almacena valores de canal alpha para una o más entradas de paleta. Para verdaderas imágenes de color y grayscale, almacena un único valor de pixel que se debe considerar totalmente transparente.
  • zTXt contiene texto comprimido (y un marcador de método de compresión) con los mismos límites tEXt.

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
  • bit value 1: los datos de imagen almacena índices de paleta. Esto sólo es válido en combinación con el valor de bit 2;
  • valor de bit 2: las muestras de imagen contienen tres canales de datos de codificación de colores tricromáticos, de lo contrario las muestras de imagen contienen un canal de luminancia relativa de codificación de datos,
  • bit value 4: las muestras de imagen también contienen un canal alfa expresado como una medida lineal de la opacidad del píxel. Esto no es válido en combinación con valor de bit 1.

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:

  • pre-compresión: filtrado (predicción)
  • compresión: DEFLATE

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:

  • Portabilidad: Transmisión es independiente de la plataforma de software y hardware.
  • Completeness: es posible representar imágenes de color verdadero, color indexado y escala gris.
  • Codificación y decodificación de series: permite generar y leer flujos de datos en serie, es decir, el formato de la secuencia de datos se utiliza para la generación y visualización de imágenes en este momento a través de la comunicación serial.
  • Presentación progresiva: ser capaz de transmitir flujos de datos que son inicialmente una aproximación de toda la imagen y progresivamente mejoran a medida que se recibe el flujo de datos.
  • Sonido a errores de transmisión: detecta correctamente los errores de transmisión del flujo de datos.
  • Pérdida: Sin pérdida: filtrar y compresión conserva toda la información.
  • Eficiencia: cualquier presentación, compresión y filtrado de imagen progresiva busca una decodificación y presentación eficientes.
  • Compresión: las imágenes pueden ser comprimidas de manera eficiente y consistente.
  • Fácil: la implementación de la norma es fácil.
  • Intercambiabilidad: cualquier decodificador PNG que siga los estándares puede leer todos los flujos de datos PNG.
  • Flexibilidad: permite futuras extensiones y adiciones privadas sin afectar el punto anterior.
  • Libertad de restricciones jurídicas: los algoritmos utilizados son gratuitos y accesibles.

Comparación con otros formatos de archivo

Formato de intercambio de gráficos (GIF)

  • En imágenes pequeñas, GIF puede lograr una mayor compresión que PNG (ver la sección en tamaño de archivos, abajo).
  • En la mayoría de las imágenes, excepto en el caso anterior, un archivo GIF tiene un tamaño mayor que una imagen PNG indexada.
  • PNG ofrece una gama mucho más amplia de opciones de transparencia que GIF, incluyendo la transparencia del canal alfa.
  • Mientras que GIF está limitado a 8 bits de color indexado, PNG ofrece una gama mucho más amplia de profundidades de color, incluyendo 24-bit (8 bits por canal) y 48 bits (16 bits por canal) verdaderocolor, permitiendo mayor precisión de color, más suaves, etc. Cuando se agrega un canal alfa, hasta 64 bits por pixel (antes de la compresión) son posibles.
  • Al convertir una imagen del formato PNG a GIF, la calidad de la imagen puede sufrir debido a la posterización si la imagen PNG tiene más de 256 colores.
  • GIF apoya intrínsecamente imágenes animadas. PNG admite la animación sólo mediante extensiones no oficiales (ver la sección sobre animación, arriba).

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.

  • 4.0 se estrella en grandes pedazos de PNG.
  • 4.0 no incluye la funcionalidad a ver. png archivos, pero hay una solución de registro.
  • 5.0 y 5.01 han roto el soporte OBJECT.
  • 5.01 imprime imágenes de paleta con fondo negro (o gris oscuro) bajo Windows 98, a veces con colores radicalmente alterados.
  • 6.0 no muestra imágenes PNG de 4097 o 4098 bytes de tamaño.
  • 6.0 no puede abrir un archivo PNG que contenga uno o más trozos de IDAT de longitud cero. Esta cuestión se fijó por primera vez en la actualización de seguridad 947864 (MS08-024). Para obtener más información, consulte este artículo en la base de conocimientos de Microsoft: 947864 MS08-024: Actualización de seguridad acumulativa para Internet Explorer.
  • 6.0 a veces pierde completamente la capacidad de mostrar PNGs, pero hay varias correcciones.
  • 6.0 y abajo han roto el soporte de transparencia alfa-canal (se mostrará el color de fondo predeterminado en su lugar).
  • 7.0 y abajo no pueden combinar transparencia alfa de 8 bits Y opacidad de elementos (CSS – filtro: Alpha (opacity=xx)) sin llenar secciones parcialmente transparentes con negro.
  • 8.0 y abajo tienen soporte gamma inconsistente/rojo.
  • 8.0 y abajo no tienen soporte de corrección de color.

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:

  • Pintura de Microsoft para Windows XP
  • Microsoft Picture It! Foto Premium 9

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:

  • (opcionalmente) eliminación de pedazos auxiliares,
  • reducir la profundidad de color, ya sea:
    • utilizar una paleta (en lugar de RGB) si la imagen tiene 256 o menos colores,
    • utilizar una paleta más pequeña, si la imagen tiene 2, 4, o 16 colores, o
    • (optionally) descarte algunos de los datos en la imagen original,
  • optimizando la elección de filtros line-by-line, y
  • optimizar la compresión DEFLATE.

Lista de herramientas

  • pngcrush es el más antiguo de los populares optimizadores PNG. Permite múltiples ensayos en la selección de filtros y argumentos de compresión, y finalmente elige el más pequeño. Este modelo de trabajo se utiliza en casi cada optimizador de png.
  • advpng y la utilidad advdef similar en el paquete AdvanceCOMP recompress the PNG IDAT. Las diferentes implementaciones DEFLATE se aplican dependiendo del nivel de compresión seleccionado, negociando entre velocidad y tamaño de archivo: zlib a nivel 1, libdeflate a nivel 2, LZMA DEFLATE de 7-zip a nivel 3, y zopfli a nivel 4.
  • pngout fue hecho con el propio deflater del autor (igual a la utilidad zip del autor, kzip), manteniendo todas las instalaciones de reducción de color / filtrado. Sin embargo, el pngout no permite utilizar varios ensayos en filtros en una sola carrera. Se sugiere utilizar su versión comercial GUI, pngoutwin, o se utiliza con un envoltorio para automatizar los ensayos o para recomprimir usando su propio deflater mientras mantiene la línea de filtro por línea.
  • zopflipng también se hizo con un deflater auto-propietario, zopfli. Tiene todas las características de optimización que pngcrush tiene (incluyendo ensayos de automatización) al tiempo que proporciona un deflater muy bueno, pero lento.

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.

Contenido relacionado

Filtro de ponderación

Un filtro de ponderación se utiliza para enfatizar o suprimir algunos aspectos de un fenómeno en comparación con otros, con fines de medición u...

Corporación Oracle

Oracle Corporation es una corporación multinacional estadounidense de tecnología informática con sede en Austin, Texas. En 2020, Oracle fue la tercera...

Escritura

La escritura es un medio de comunicación humana que involucra la representación de un lenguaje a través de un sistema de símbolos físicamente inscritos...
Más resultados...
Tamaño del texto:
undoredo
format_boldformat_italicformat_underlinedstrikethrough_ssuperscriptsubscriptlink
save