Compresión de imágenes en detalle: Formatos, ajustes de calidad y tamaño de archivo
1. ¿Qué formato y calidad elegir? Respuesta rápida
La selección idónea de formato y factor de calidad depende de la naturaleza visual de la imagen y de sus requisitos de distribución:
- Fotografías y escenas con gradientes continuos: WebP (calidad 75% – 80%) o JPEG (calidad 75% – 80%). En este intervalo, el tamaño de archivo se reduce entre un 80% y un 95% sin pérdidas perceptibles para el ojo humano.
- Gráficos con fondo transparente, iconos y logotipos: WebP (canal alfa totalmente conservado, 75% – 80%) o PNG (completamente sin pérdidas). Nunca guarde imágenes transparentes en formato JPEG; JPEG no admite transparencia y convierte los píxeles transparentes en un fondo blanco opaco.
- Capturas de pantalla, diagramas y tipografía nítida: PNG o WebP sin pérdidas. El algoritmo JPEG genera artefactos de oscilación (ringing) y efecto halo alrededor de caracteres y contornos de alto contraste.
¿Por qué cambia el tamaño de archivo sin modificar la resolución en píxeles? Aunque el número de píxeles (ancho × alto) permanezca idéntico, los códecs con pérdida (JPEG DCT, WebP VP8) eliminan frecuencias cromáticas imperceptibles para la visión humana mediante matrices de cuantización, almacenando la información mediante codificación entrópica en muchos menos bytes. Los formatos sin pérdidas (PNG) preservan el valor exacto de cada píxel, comprimiendo únicamente redundancias matemáticas. En archivos diminutos, la sobrecarga obligatoria de las cabeceras del contenedor puede superar los bytes eliminados, haciendo que el archivo aumente de tamaño (+%X).
2. Matriz comparativa de formatos
Formatos de salida disponibles y su comportamiento operativo en el Compresor de Imágenes de GoToolstack:
| Formato | Tipo de compresión | Canal alfa (Transparencia) | Efecto del control de calidad | Caso de uso recomendado |
|---|---|---|---|---|
| WebP (.webp) | Con pérdida (VP8) y Sin pérdida (VP8L) | Compatible (Conserva totalmente el canal alfa) | Determina el tamaño y cuantización en modo con pérdida | Sitios web modernos, portadas de blog, comercio electrónico |
| JPEG (.jpg) | Con pérdida (Transformada de Coseno Discreta / DCT) | No compatible (Las zonas transparentes se rellenan con blanco) | Regula la fidelidad y peso en el rango 0.10 – 1.00 | Fotografías, imágenes con gradientes continuos |
| PNG (.png) | Sin pérdida (DEFLATE / LZ77) | Compatible (Alfa de 8 y 24 bits) | Ignorado por la API Canvas (siempre sin pérdida) | Logotipos, capturas de interfaz, diagramas técnicos |
| AVIF (.avif) | Con y sin pérdida (AV1) | Compatible (Conserva canal alfa) | Ajusta el factor de cuantización si hay soporte | Navegadores modernos con compatibilidad nativa AVIF |
3. Cuatro diferencias técnicas determinantes
1. Fotografías frente a gráficos con texto
La norma JPEG (ITU-T T.81) divide la imagen en bloques de 8×8 píxeles y aplica la Transformada de Coseno Discreta (DCT). En capturas fotográficas con transiciones suaves de tono, las divisiones de bloque pasan inadvertidas. No obstante, en contornos nítidos como caracteres tipográficos, códigos de barras o bordes de botones, eliminar coeficientes de alta frecuencia provoca evidentes artefactos de oscilación (efecto halo) y difuminado local. Los gráficos con texto exigen PNG o WebP sin pérdidas.
2. Transparencia alfa y la trampa del JPEG
El formato JPEG no contempla canales de transparencia. Si un archivo PNG con fondo transparente se exporta a JPEG, el contexto 2D de HTML5 Canvas rellena automáticamente los píxeles transparentes con color blanco opaco (#ffffff). Para preservar la transparencia es indispensable seleccionar WebP o PNG.
3. Redimensionamiento frente a reducción de calidad
El redimensionamiento cambia el conteo de píxeles espaciales (por ejemplo, reducir de 4000×3000 px a 1200×900 px). Achicar la cuadrícula de píxeles ofrece el mayor ahorro de bytes posible. Reducir la calidad, en cambio, mantiene inalteradas las dimensiones en píxeles y solo relaja la matriz de cuantización para sintetizar la precisión del color. El Compresor de Imágenes de GoToolstack no altera la resolución en píxeles, sino que recodifica el archivo según el formato y el factor de cuantización indicados.
4. Rendimiento con y sin pérdidas por formato (Datos de Google WebP)
Según los estudios analíticos publicados por Google Developers:
- WebP sin pérdidas: Logra archivos un 26% más pequeños que un PNG idéntico gracias a transformaciones espaciales avanzadas y codificación entrópica optimizada (Fuente: Google Developers, Comparative Study of WebP, JPEG and PNG).
- WebP con pérdida: Ocupa entre un 25% y un 34% menos de espacio que un JPEG equivalente con idéntico Índice de Similitud Estructural (SSIM). La intra-predicción VP8 proyecta la dirección cromática a partir de macrobloques vecinos, evitando almacenar datos redundantes.
4. Mediciones empíricas con la API Canvas en navegador
Para comprobar cuantitativamente los resultados, evaluamos los archivos sintéticos de prueba del repositorio en un motor Chromium 154 (Chrome Headless) utilizando la API estándar HTML5 Canvas 2D toBlob(). Todas las pruebas se efectuaron con archivos sintéticos generados sin incorporar imágenes externas ni datos personales.
Metodología y reproducibilidad: Los valores indicados a continuación se obtuvieron procesando directamente los archivos tests/fixtures/image-800x600-opaque.png y tests/fixtures/image-800x600-transparent.png en la herramienta. Los datos reflejan patrones geométricos y tipográficos controlados. Dado que las fotografías reales presentan una entropía cromática distinta, las tasas de compresión varían; estos valores representan puntos de referencia reproducibles y no una garantía universal absoluta.
Escenario A: Imagen sintética opaca (800×600 px PNG, Tamaño original: 297.270 bytes / 290,3 KB)
| Formato destino | Nivel de calidad | Tamaño resultante | Ahorro medido | Evaluación visual |
|---|---|---|---|---|
| WebP | 80% (Recomendado) | 8.300 bytes (8,1 KB) | -97,2% ahorro | Contornos nítidos, pérdida cromática imperceptible |
| WebP | 60% | 6.716 bytes (6,6 KB) | -97,7% ahorro | Suavizado leve en transiciones de alto contraste |
| JPEG | 80% | 13.871 bytes (13,5 KB) | -95,3% ahorro | Tonos naturales, ligera matriz de bloques |
| JPEG | 60% | 10.863 bytes (10,6 KB) | -96,3% ahorro | Ligera pérdida de nitidez en líneas finas |
| PNG (Recodificado) | 100% Sin pérdida | 297.270 bytes (290,3 KB) | 0,0% variación | Correspondencia matemática exacta píxel por píxel |
Escenario B: Imagen sintética transparente (800×600 px PNG, Tamaño original: 28.766 bytes / 28,1 KB)
| Formato destino | Nivel de calidad | Tamaño resultante | Ahorro medido | Transparencia y fidelidad |
|---|---|---|---|---|
| WebP | 80% (Recomendado) | 8.474 bytes (8,3 KB) | -70,5% ahorro | Transparencia alfa íntegra, sin artefactos |
| WebP | 60% | 7.664 bytes (7,5 KB) | -73,4% ahorro | Transparencia alfa íntegra, suavizado leve |
| JPEG | 80% | 14.343 bytes (14,0 KB) | -50,1% ahorro | Transparencia eliminada: Fondo rellenado con blanco (#ffffff) |
| PNG (Recodificado) | 100% Sin pérdida | 28.716 bytes (28,0 KB) | -0,2% variación | Transparencia alfa y colores perfectamente preservados |
5. Causas del aumento de tamaño (+%X) en archivos pequeños
Al intentar comprimir un icono de dimensiones mínimas (menos de 1–2 KB) o una ilustración con escasa variedad tonal, es frecuente que el archivo resultante sea más pesado (+10% a +40%) que el original. Esto obedece a razones técnicas estructurales:
- Las especificaciones JPEG y WebP exigen cabeceras obligatorias, tablas de frecuencias Huffman, paletas y matrices de cuantización.
- Si la imagen de entrada contiene un volumen mínimo de información visual, la sobrecarga fija de estos metadatos supera los bytes eliminados en la compresión.
- El Compresor de Imágenes de GoToolstack detecta esta situación, muestra un aviso destacado en rojo con el porcentaje
+%Xy proporciona como opción predeterminada el botónDescargar original.
6. Capacidades de la herramienta y límites técnicos en el navegador
El Compresor de Imágenes de GoToolstack opera por completo en el lado del cliente. Sus archivos no se transfieren a ningún servidor y se procesan exclusivamente en el hardware de su propio dispositivo.
Límite de resolución Canvas: Las transformaciones se ejecutan a través de HTML5 Canvas. En dispositivos móviles (especialmente con iOS Safari), imágenes de gran tamaño que superen los 16,7 megapíxeles (aproximadamente 4096×4096 px) pueden agotar los límites de memoria gráfica asignados al navegador. En estos casos se recomienda reducir la resolución antes del procesamiento.
- Funciones compatibles: Carga de archivo individual, selección de salida en JPEG, WebP, PNG y AVIF, regulador de calidad continuo de 0.10 a 1.00, cálculo inmediato de ahorro y botones independientes para descargar el original o la versión procesada.
- Funciones no disponibles: La herramienta no incluye empaquetado en lotes ZIP, control deslizante de comparación interactiva (split slider), codificación JPEG progresiva ni vectorización SVG.
- Metadatos EXIF: La exportación mediante Canvas descarta de forma predeterminada los metadatos EXIF de la cámara (coordenadas GPS, modelo de cámara, apertura), resguardando la privacidad del usuario y aligerando la carga.
- Profundidad de color: La API Canvas opera en espacio de color sRGB estándar de 8 bits por canal; perfiles HDR RAW de 10 o 12 bits se adaptan a la escala estándar de 8 bits.
7. Normas técnicas y referencias
- Google Developers (2025/2026): Comparative Study of WebP, JPEG and PNG y WebP Compression Techniques. Fundamentos de intra-predicción VP8 y arquitectura WebP sin pérdidas.
- Recomendación ITU-T T.81 / ISO/IEC 10918-1: Information Technology – Digital Compression and Coding of Continuous-tone Still Images (Estándar DCT JPEG y restricciones del canal alfa).
- Recomendación W3C: Portable Network Graphics (PNG) Specification (Second Edition) / ISO/IEC 15948 (Algoritmo DEFLATE sin pérdidas y transparencia alfa).
- Estándar WHATWG: HTML Living Standard – HTMLCanvasElement toBlob() (Especificación para exportación y serialización de imágenes en el cliente).
