Con pérdida vs sin pérdida: por qué los formatos de imagen olvidan a propósito

Toma la misma foto de 12 MP (4000 x 3000 píxeles) y guárdala dos veces. Una vez como PNG: 24 MB. Otra como JPEG con calidad 90: 3,4 MB. Ponlas una al lado de la otra en la pantalla y no las distinguirás. Haz zoom al 400% y por fin asoman las diferencias: un ligero suavizado en el pelo y el césped, unos halos tenues en los bordes más nítidos.

Dos archivos, una imagen, una diferencia de tamaño de 7x. Ninguno está dañado. Es que cada uno se compromete a algo distinto. PNG se compromete a conservar cada bit. JPEG, a conservar todo lo que notarías. Casi todo lo que hay que saber de los formatos de imagen se deduce de cuál de esos dos compromisos elige cada formato.

Por qué la compresión se dividió en dos bandos

En 1948, Claude Shannon publicó "A Mathematical Theory of Communication" y fijó el límite teórico de la compresión. Su teorema de codificación de fuente dice que no se pueden representar datos sin pérdida por debajo de su entropía, es decir, el contenido medio de información por símbolo. Una imagen perfectamente aleatoria no se comprime nada. Una imagen completamente blanca se comprime hasta casi desaparecer. Toda imagen real cae en algún punto de esa escala, y ningún algoritmo sin pérdida puede bajar de ahí.

La compresión con pérdida existe porque ese límite tiene una laguna: se aplica a los datos que tienes, no a los que conservas. Si primero sustituyes la imagen por otra ligeramente distinta, una con menos entropía, el límite baja con ella. Ese es todo el truco: cambia los datos y luego empaquétalos. La verdadera pregunta de ingeniería es qué cambios son aceptables.

La respuesta depende de dos cosas. La primera es el contenido. Una captura de un panel de ajustes es casi todo color plano y formas repetidas: poca entropía, fácil de predecir. Una foto de un bosque, a nivel de píxel, es ruido de disparo de los fotones y ruido de lectura del sensor: mucha entropía, difícil de predecir. La segunda es quién va a mirar el archivo. Un programa necesita los bits exactos. Una persona llega con una tolerancia al error de fábrica: poca agudeza espacial para el color, escasa sensibilidad a la textura fina de alta frecuencia y una percepción del brillo que sigue proporciones en vez de valores absolutos (la ley de Weber, saltos de luminancia de entre el 1 y el 2% aproximadamente).

De ahí la división. Si tu contenido es predecible y quien lo consume es una máquina, o una persona de esas que miran los píxeles con lupa, ve a sin pérdida. Si tu contenido es ruidoso y quien lo mira es una persona a un brazo de distancia, puedes permitirte olvidarte de cosas.

Cómo funciona la compresión con pérdida

Se suele decir que los códecs con pérdida "tiran datos", y es verdad a medias. Tiran datos muy concretos, elegidos por un modelo de la visión humana. El proceso tiene estas etapas:

1. Convierte RGB a un espacio de color luma-croma (YCbCr en JPEG; otros códecs hacen divisiones parecidas). El ojo distingue el detalle de brillo mucho mejor que el de color, así que los canales de croma se pueden guardar a un cuarto de resolución (submuestreo 4:2:0). Solo este paso recorta los datos brutos en torno a un 50%, y en la mayoría de las fotos es invisible.

2. Transforma cada bloque en frecuencias. JPEG usa la transformada discreta del coseno sobre bloques de 8 x 8. JPEG 2000 usa wavelets. AV1 y HEVC usan transformadas más grandes y de tamaño variable. El resultado siempre tiene la misma pinta: unos pocos coeficientes grandes que describen las formas generales, y muchos coeficientes pequeños que describen la textura fina.

3. Cuantiza. Divide cada coeficiente entre un tamaño de paso y redondea al entero. Los coeficientes pequeños se convierten en cero. Es el único paso con pérdida de todo el proceso, y el ajuste de calidad de tu codificador no es más que un multiplicador sobre esos tamaños de paso. Calidad 95 usa pasos pequeños y conserva casi todo. Calidad 30 usa pasos grandes y manda a cero buena parte de la textura fina.

4. Aplica codificación entrópica a lo que sobrevive. Escaneo en zigzag, codificación de longitud de carrera, Huffman o codificación aritmética. Esta etapa es sin pérdida: solo empaqueta los números ya cuantizados.

Fíjate bien en la lista. Los pasos 1, 2 y 4 son pura reordenación reversible de los datos. El paso 3 es donde la imagen se destruye de verdad: a propósito y un error de redondeo cada vez.

Esa destrucción deja una huella característica. Baja demasiado la calidad y aparecen el bloqueo (blocking: se ven los bordes de la cuadrícula de 8 x 8 en cielos y paredes), el ringing (halos alrededor del texto y de los bordes de alto contraste) y el banding (los degradados suaves colapsan en escalones). Y si vuelves a guardar un archivo con pérdida, todo el proceso se ejecuta otra vez sobre datos ya dañados; por eso la pérdida generacional se acumula: la décima vez que guardas un JPEG parece una acuarela de la primera.

Cómo funciona la compresión sin pérdida

Los códecs sin pérdida no se permiten esas libertades. El archivo decodificado tiene que coincidir con el original bit a bit, así que solo les queda modelar y empaquetar. La receta habitual tiene dos etapas.

Primera etapa: eliminar la correlación. PNG filtra cada línea de la imagen antes de comprimirla. Para cada fila, el codificador elige uno de cinco predictores (None, Sub, Up, Average, Paeth) y guarda la diferencia entre el píxel real y la predicción. Una fila completamente blanca se convierte en un píxel blanco seguido de miles de ceros. Un degradado suave se convierte en residuos pequeños que varían despacio. En ambos casos los números se hacen pequeños y se apiñan cerca de cero, que es justo lo que necesita la etapa siguiente.

Segunda etapa: codificación entrópica. PNG usa DEFLATE, el mismo algoritmo de gzip y zip, montado sobre dos ideas de los años 70. LZ77 busca secuencias de bytes repetidas y sustituye cada repetición por un puntero (distancia, longitud) a los 32 KB anteriores del archivo. Después, la codificación de Huffman asigna códigos cortos a los valores frecuentes y códigos largos a los raros. Ninguno de los dos pasos pierde nada: a partir del flujo comprimido siempre se pueden reconstruir los bytes originales.

Por eso PNG brilla con las capturas de pantalla y fracasa con las fotos. Los gráficos de interfaz se repiten sin parar: filas idénticas, iconos repetidos, largas secuencias de color plano. LZ77 encuentra coincidencias por todas partes, y los filtros reducen lo que queda a residuos casi nulos. Una fotografía no repite nada. El ruido hace que cada píxel sea un poco distinto de sus vecinos, así que los predictores fallan, los residuos siguen siendo grandes y aleatorios, y LZ77 no encuentra nada a lo que apuntar. Con una foto de 12 MP, PNG suele conseguir entre 1,3:1 y 1,6:1 sobre los píxeles brutos. JPEG, con una calidad visualmente parecida, llega a 10:1.

A cambio de esos archivos más grandes obtienes una garantía absoluta: abre un PNG, calcula el hash de los píxeles y coincidirá con el original todas las veces. Para capturas que van a pasar por un OCR, escaneos que se van a reeditar, imágenes médicas o científicas que pueden acabar en un artículo o en un juicio, esa garantía es exactamente lo que se busca.

Por qué JPEG apostó por la compresión con pérdida en 1992

El Joint Photographic Experts Group empezó a trabajar en 1986, y las limitaciones de la época explican cada decisión de diseño. Un disco duro de 20 MB costaba cientos de dólares. Un disquete de 1,44 MB era la manera normal de mover archivos. Los módems iban a 14,4 kbps si tenías suerte: descargar una sola foto VGA sin comprimir, 921 KB, llevaba unos nueve minutos. La versión con pérdida a 10:1 llegaba en menos de un minuto. La sin pérdida a 2:1 seguía tardando más de cuatro.

Las propias pruebas del comité les dijeron que el sin pérdida no daba más de sí. El contenido fotográfico, el objetivo declarado del grupo ("imágenes de tono continuo"), simplemente no tiene suficiente redundancia. Con esos números sobre la mesa, diseñaron en torno al único margen que quedaba: el espectador.

Lo que casi nunca se cuenta es que el estándar publicado en 1992 (ISO/IEC 10918-1) sí incluye un modo sin pérdida. Se salta la DCT por completo, predice cada píxel a partir de hasta tres vecinos con uno de siete predictores fijos y aplica codificación entrópica a los residuos: en esencia, el mismo truco que PNG usaría tres años después. Casi nadie lo implementó. Los decodificadores lo ignoraron, los codificadores lo ignoraron, y cuando la imagen médica necesitó de verdad un JPEG sin pérdida, terminó con un estándar propio (JPEG-LS, ISO/IEC 14495, 1999).

El comité también tuvo que esquivar patentes. La opción de codificación aritmética de JPEG venía lastrada por las patentes del Q-coder de IBM, así que la línea base libre de regalías se quedó con Huffman, y la mayoría de las implementaciones ni tocaron la vía aritmética. Que el miedo a las patentes moldeara el diseño de un códec no era nuevo en 1992. Y lo que estaba por venir era mucho peor.

En el fondo, JPEG era una apuesta psicovisual: el último 5x de compresión no son matemáticas, es biología.

Por qué PNG apostó por la compresión sin pérdida en 1995

PNG no nació como un proyecto de ingeniería. Nació como una emergencia legal.

En diciembre de 1994, Unisys anunció que cobraría licencias por el software que usara GIF, porque la compresión de GIF se apoyaba en el algoritmo LZW, cubierto por una patente de 1985 que Unisys había heredado. CompuServe, el creador de GIF, pactó con Unisys y trasladó el coste a los desarrolladores. Las comunidades de gráficos de Usenet montaron en cólera: GIF llevaba siete años siendo gratis y, de la noche a la mañana, todas las imágenes y herramientas de la web temprana descansaban sobre terreno patentado.

En unas semanas, a principios de enero de 1995, Thomas Boutell colgó el primer borrador de un sustituto. Un grupo de voluntarios fue cerrando el diseño por listas de correo en pocos meses. PNG 1.0 llegó en octubre de 1996 como recomendación del W3C, y después como RFC 2083 en marzo de 1997.

Hubo dos requisitos que nunca se discutieron. Todos los algoritmos tenían que estar limpios de patentes, lo que apuntaba a DEFLATE (la combinación de LZ77 y Huffman del PKZIP de Phil Katz, implementada en zlib por Jean-loup Gailly y Mark Adler). Y el formato tenía que ser sin pérdida, sin más. La comunidad estaba reemplazando GIF: un sustituto que degradara las imágenes habría nacido muerto, y además la limpieza de patentes no dejaba sitio para los trucos perceptuales que hacían funcionar a JPEG.

El tipo de contenido pesaba igual. PNG se diseñó para lo que GIF de verdad transportaba: logotipos, diagramas, ilustraciones de línea, iconos, capturas de pantalla. Bordes nítidos y color plano, justo el contenido donde el ringing de JPEG más se nota. Ir a por las fotos habría significado reinventar la DCT y competir con un JPEG ya asentado y libre de regalías. PNG eligió la batalla que podía ganar, y la ganó con creces. La patente de GIF expiró en 2003 (2004 fuera de EE. UU.), pero para entonces PNG ya le había quitado el puesto.

Por qué la compresión con pérdida ganó el mercado aun así

PNG se quedó con su nicho. JPEG se quedó con el mundo.

La razón es el volumen. Las imágenes de la web son en su inmensa mayoría fotografías, y para una fotografía la compresión con pérdida no es una concesión: es la herramienta correcta. El Web Almanac 2025 sitúa a JPEG en torno al 57% de todas las imágenes servidas, tres décadas después. Redes sociales, fotografía de prensa, fotos de producto, anuncios de pisos: todo es contenido de tono continuo, donde una codificación con pérdida a calidad 75 es visualmente indistinguible del original en las pantallas que la gente usa de verdad.

Los costes tiran en la misma dirección. El almacenamiento y el ancho de banda se facturan por byte, y 10:1 frente a 2:1 no es un margen: es una diferencia de 5x en el coste de entrega a una calidad aceptable. La velocidad de una página depende del peso de sus archivos, y el peso depende de la compresión. Todas las cámaras y todos los móviles traen de serie un formato con pérdida (JPEG o HEIC). Todos los CMS generan miniaturas con pérdida. Las plataformas sociales recodifican cada subida, en parte por el tamaño y en parte para quitar metadatos y cualquier cosa maliciosa que se esconda en ellos. Un fotógrafo puede subir un TIFF impecable; lo que llega al timeline es un JPEG de calidad 85.

La compresión sin pérdida no perdió exactamente: se replegó a los terrenos donde su garantía importa. Capturas de pantalla y recursos de interfaz, donde los artefactos se ven al instante y el contenido comprime bien de todos modos. Masters dentro de un flujo de edición, donde cada generación con pérdida se suma a la anterior. Imagen médica, legal y científica, donde "casi igual" no vale como prueba. En esos nichos, PNG y TIFF no tienen rival. Simplemente no están donde está el tráfico.

Dónde acabaron los formatos

Saltan a la vista dos tendencias. Los códecs nuevos ya no eligen bando: WebP, HEIC, AVIF y JPEG XL traen modos con pérdida y sin pérdida en una misma especificación, y JPEG 2000 ya lo hacía en el año 2000. La pregunta dejó de ser "qué formato" para pasar a ser "qué modo". Y la frontera entre los dos enfoques sigue moviéndose: JPEG XL puede recomprimir un JPEG existente sin pérdida hasta dejarlo en torno al 80% de su tamaño, algo que solo es posible porque los dos bandos llevan treinta años estudiando las matemáticas del otro.

Cómo elegir en la práctica

El árbol de decisión es corto:

• ¿Vas a publicar una foto? Con pérdida. JPEG si importa la compatibilidad; WebP o AVIF si importa el tamaño.
• ¿Guardas una captura de pantalla, un logotipo o cualquier cosa con texto y color plano? Sin pérdida. PNG.
• ¿Vas a editar? Conserva el master sin pérdida, exporta copias con pérdida y no vuelvas a guardar nunca un archivo con pérdida en el mismo formato. Cada generación se suma al daño.
• ¿Vas a convertir? Piensa en el destino, no en el origen. Una captura PNG que va a una galería de fotos debería acabar en JPEG o WebP. Un JPEG que entra en un archivo de diseño debería pasar a PNG, no porque vaya a ganar calidad (imposible), sino porque deja de perderla.

Con ese último punto se lía mucha gente con las fotos de iPhone. HEIC ya es compresión HEVC con pérdida. Convertir de HEIC a PNG no recupera nada: congela el estado actual y garantiza que no habrá más pérdidas, lo cual sigue siendo útil si piensas editar. Si es para compartir, convertir directamente a JPEG es lo sensato. Nuestros conversores de HEIC a JPG, HEIC a PNG y HEIC a WebP hacen la conversión en tu propio navegador, así que el archivo no sale de tu dispositivo.

La misma lógica sirve para el resto de la matriz. ¿Pasas un JPEG a un flujo de edición sin pérdida? JPG a PNG. ¿Quieres aligerar una captura PNG para la web? PNG a JPG, o PNG a WebP si buscas archivos más pequeños sin perder la transparencia. En la dirección contraria, WebP a PNG y WebP a JPG devuelven la compatibilidad con software antiguo. Si te ves con escaneos BMP sin comprimir, BMP a JPG, BMP a PNG y BMP a WebP te dan la misma elección entre con pérdida y sin pérdida en un paso. Hasta exportar documentos acaba en la misma disyuntiva: sacar una página de PDF como imagen significa elegir entre PDF a JPG para páginas fotográficas y PDF a PNG cuando el texto tiene que quedar nítido.

Treinta años después, los formatos que sobrevivieron son los que tuvieron claro de qué podían prescindir los ojos de sus usuarios, y de qué no.