JPEGs que empeoran a propósito

Si alguna vez comparaste dos versiones de la misma foto y la segunda se veía peor, no fue necesariamente un error. A veces, el formato, la cadena de procesamiento o una decisión de diseño aceptan perder calidad a cambio de otra cosa: menos bytes, menos CPU, menos latencia o una decodificación más simple. Ese intercambio es bastante común en media y web, y el proyecto Regressive JPEGs lo lleva al extremo para que lo veas sin anestesia.

La idea es incómoda pero útil: en vez de pelear contra los artefactos, el formato los usa como parte de su estrategia. Para quien trabaja con pipelines de imagen, esto sirve como recordatorio de que “calidad” no es una propiedad absoluta. Depende del contexto, del dispositivo, de la red y de cuánto estás dispuesto a sacrificar en cada paso.

Qué son los Regressive JPEGs y por qué importan

Regressive JPEGs es un experimento de Maurycyz que toma el JPEG, un formato que ya conocemos por su compresión con pérdida, y lo empuja hacia una idea más rara: que la imagen pueda ir empeorando de forma controlada según avanza la transmisión o la carga. No se trata solo de comprimir más. Se trata de decidir qué tan útil puede ser una imagen parcial mientras todavía no llegó completa.

En web eso tiene sentido. No siempre necesitas la foto final a máxima fidelidad en el primer instante. A veces te basta con una versión aproximada para que el layout se vea estable, para que el usuario entienda el contenido o para que una galería responda rápido. El problema es que JPEG tradicional no fue pensado con esa lógica de “degradación progresiva de calidad” como objetivo principal, aunque sí existe el progressive JPEG.

La diferencia aquí es conceptual. El experimento juega con la regresión visual como una característica deliberada, casi como si el formato dijera: “te doy algo útil primero, y luego te cobro con más error si eso me ayuda a ser más eficiente”. Para devs de media y frontend, eso abre una pregunta que vale oro: ¿cuándo conviene aceptar una imagen imperfecta si eso mejora la experiencia real?

JPEG tradicional vs progressive JPEG

JPEG clásico codifica la imagen en bloques de 8x8 píxeles y aplica transformadas y cuantización para reducir información. El resultado es conocido: menos peso, pero también ringing, banding y bloques visibles cuando la compresión aprieta demasiado. En progressive JPEG, la imagen puede aparecer en varias pasadas, primero borrosa y luego más detallada.

Eso ya mejora la percepción del usuario, porque ves una versión del contenido antes de tener el archivo completo. Según la documentación de MDN, progressive JPEG se usa para mostrar una vista previa más temprana, aunque no siempre es la opción más eficiente para todos los casos. Puedes revisar la referencia oficial en MDN sobre JPEG.

Regressive JPEGs toma esa idea y la vuelve más explícita: la degradación no es un accidente, sino una forma de estructurar el archivo. Para quien trabaja en pipelines, eso es una pista clara de diseño. No todo formato debe optimizar solo para la imagen final. También puede optimizar para el camino hasta llegar ahí.

Cómo funciona la compresión cuando aceptas perder detalle

JPEG se apoya en varias decisiones matemáticas que, en conjunto, reducen información. Primero, suele convertir la imagen de RGB a un espacio de color más eficiente para compresión. Luego divide la imagen en bloques, transforma cada bloque y cuantiza los coeficientes. La cuantización es la parte donde realmente se pierde detalle: ciertos valores se redondean o se descartan.

Ese proceso explica por qué las imágenes JPEG pueden verse bien a tamaños moderados y muy mal cuando fuerzas demasiado la compresión. Los detalles finos desaparecen primero. Los bordes empiezan a mostrar halos. Las áreas planas pueden llenarse de parches. Y si recodificas varias veces, el daño se acumula.

Regressive JPEGs usa esa realidad a su favor. En lugar de ocultarla, la organiza. El archivo puede estar construido para que las primeras partes decodificables den una versión útil, aunque incompleta, y las partes posteriores aporten refinamiento o, en esta propuesta, un tipo de regresión controlada que hace visible la lógica interna del formato.

Bloques, cuantización y ruido visible

Si trabajas con imágenes en producción, ya conoces el costo de ignorar estas etapas. Un banner con texto pequeño en JPEG puede salir mal porque la cuantización destruye bordes finos. Una foto de producto con fondo liso puede mostrar banding. Una imagen reescalada varias veces puede terminar con artefactos más notorios que el archivo original.

Aquí conviene pensar en números concretos. En muchos pipelines, pasar de PNG a JPEG puede reducir el peso de una imagen fotográfica en 30% a 80%, dependiendo del contenido y del quality factor. Pero ese ahorro no es gratis. Si el contenido tiene logos, UI, tipografía o líneas duras, el JPEG puede ser la peor opción.

La lección de Regressive JPEGs no es “usa JPEG para todo”. Es más bien la contraria: entiende qué tipo de degradación estás permitiendo. Si el formato ya tolera pérdida, entonces puedes diseñar alrededor de esa pérdida en vez de pelearte con ella después.

Qué enseña este experimento a devs de web y media

Para frontend, backend o equipos de media, el valor del experimento está en que te obliga a pensar en la imagen como un flujo, no como un archivo estático. Una imagen puede pasar por captura, edición, compresión, CDN, resize, cache y render. En cada paso hay decisiones que afectan calidad, peso y tiempo de entrega.

Muchas veces el cuello de botella no es el algoritmo, sino el contexto. Una foto de portada en una landing puede cargar en 2.5 segundos en una red móvil si pesa demasiado. En cambio, una versión progresiva o una representación intermedia puede dar feedback visual antes de que termine la descarga. Eso cambia la percepción del usuario aunque el archivo final sea el mismo.

También hay un aprendizaje práctico para equipos que procesan media en batch. Si produces miles de imágenes al día, cada byte y cada milisegundo cuentan. Un pipeline que recodifica sin control puede introducir degradación acumulada. Un pipeline que decide bien cuándo usar JPEG, WebP, AVIF o PNG puede ahorrar ancho de banda y evitar tickets de soporte por imágenes borrosas.

Casos reales donde sí te afecta

• E-commerce: fotos de producto con fondo blanco y texto incrustado. JPEG agresivo puede dejar bordes sucios y afectar percepción de calidad.
• CMS editorial: imágenes de portada recortadas y reescaladas varias veces. Si el editor sube un archivo ya comprimido, una segunda compresión puede empeorarlo bastante.
• Apps móviles: galería con previews. Una versión intermedia rápida puede mejorar la experiencia en conexiones lentas.
• Dashboards y reportes: capturas con tablas y texto pequeño. A menudo conviene PNG o WebP lossless antes que JPEG.

Si administras un pipeline, vale la pena medir. No asumas. Compara peso, tiempo de codificación, tiempo de decodificación y calidad visual en dispositivos reales. En equipos con usuarios en Ecuador, México, Colombia o Perú, donde la red móvil sigue siendo variable, el costo de una mala decisión se nota rápido.

Decisiones de diseño que cambian la experiencia

El punto más interesante de Regressive JPEGs no es solo técnico. Es de producto. Un formato de imagen puede favorecer velocidad, robustez, simplicidad de decodificación o calidad final. No siempre puedes tener las cuatro cosas al mismo tiempo. Cuando eliges una, estás dejando otra en segundo plano.

Eso también aplica a tu stack. Si usas una CDN que transforma imágenes al vuelo, si tu backend genera thumbnails, o si tu frontend depende de imágenes responsivas, tienes varios lugares donde una mala decisión se replica. Un error pequeño en el origen puede terminar multiplicado por caches, variantes y recodificaciones.

La buena noticia es que hay herramientas para controlar esto. Puedes definir límites de calidad, evitar recomprimir archivos ya comprimidos, y servir formatos distintos según el caso. La mala noticia es que muchas veces el problema aparece tarde, cuando el usuario ya vio la imagen borrosa y no le importa tu explicación técnica.

Qué medir antes de elegir formato

1. Peso final en bytes para 3 resoluciones típicas: móvil, tablet y desktop.
2. Tiempo de codificación si generas imágenes en runtime o en build.
3. Tiempo de decodificación en dispositivos de gama media.
4. Presencia de texto, líneas, logos o UI dentro de la imagen.
5. Calidad percibida después de una compresión adicional en CDN o editor.

Si quieres una referencia técnica seria sobre formatos y compresión, la documentación de Web.dev sobre imágenes explica muy bien cómo pensar en formatos, tamaños y carga. No te da una receta única, pero sí un marco útil para tomar decisiones sin improvisar.

Cómo aplicar esta idea en tu pipeline

La parte práctica es separar el problema en etapas. No trates la imagen como un bloque monolítico. Pregúntate qué necesita cada paso: almacenamiento, entrega, render y edición. Un archivo maestro puede vivir en alta calidad, mientras que las derivaciones para web pueden usar distintos niveles de compresión según el contexto.

Si tu pipeline hace resize, crop y encode, revisa si estás reencodificando más veces de las necesarias. Cada pasada puede sumar artefactos. Si recibes imágenes de usuarios, define si vas a aceptar JPEG, PNG, WebP o AVIF, y qué transformación harás antes de servirlas. No es lo mismo optimizar una foto de portada que una captura de pantalla.

También conviene pensar en observabilidad. Si no mides el peso promedio de las imágenes, el percentil 95 y la tasa de errores de procesamiento, vas a descubrir problemas demasiado tarde. Un cambio pequeño en el encoder puede duplicar el tamaño de algunas piezas sin que nadie lo note hasta producción.

Checklist operativo

• Guarda siempre un master sin recomprimir si el flujo lo permite.
• Evita encadenar JPEG sobre JPEG salvo que no haya otra opción.
• Usa PNG o WebP lossless para capturas, UI y texto pequeño.
• Prueba progressive JPEG solo donde la percepción de carga temprana aporte valor real.
• Mide en red móvil, no solo en Wi-Fi de oficina.
• Revisa el impacto de resize y sharpening antes de codificar.

Un detalle útil: si sirves imágenes desde un CDN, revisa si está recomprimiendo por defecto. Algunos servicios hacen optimización automática y eso puede ser bueno, pero también puede chocar con tu intención original. Lee la documentación del proveedor y prueba con archivos reales, no con ejemplos sintéticos.

Tabla resumen

La idea central es simple: si eliges un formato, también eliges una forma de error. JPEG no solo comprime. También define cómo se rompe la imagen cuando aprietas demasiado. Regressive JPEGs hace visible esa tensión y te recuerda que el diseño de formatos no es neutral.

Para devs de media, web y procesamiento de imágenes, esa lección vale bastante. Te ayuda a mirar el pipeline completo en vez de obsesionarte con un solo ajuste de quality. Y te obliga a preguntar algo más útil que “¿qué formato pesa menos?”: “¿qué tipo de degradación puedo tolerar sin arruinar la experiencia?”