Herramienta de Compresión de Imágenes

La compresión de imágenes en línea reduce el tamaño de los archivos para que las páginas carguen más rápido, los envíos respeten límites de peso y las imágenes compartidas consuman menos ancho de banda. Los archivos se suben al servicio de conversión de ToolAct, se procesan con bibliotecas del lado del servidor (libvips, mozjpeg, libwebp) y el resultado comprimido se descarga de vuelta. Los originales se eliminan inmediatamente del servidor cuando termina la conversión: no se archivan ni se usan para entrenamiento. Según el formato, puede ajustar calidad, metadatos, color y detalles de codificación; una foto puede ocupar mucho menos sin que la pérdida sea evidente a tamaño normal. Es útil para blogs, fichas de producto, redes sociales, adjuntos de soporte y borradores que no requieren conservar cada píxel. Para impresión, archivo o revisión visual minuciosa conviene comprobar el resultado después de comprimir. Evita subir fotos con datos personales, documentos internos u otro material sensible.

La compresión de imágenes se divide limpiamente entre la frontera con pérdida/sin pérdida. Los formatos con pérdida (JPEG, WebP con pérdida) explotan los límites perceptivos humanos: el ojo es mucho menos sensible al croma de alta frecuencia que a la luminancia, por lo que los codificadores descartan pequeños detalles de color en bloques de 8x8 o 16x16 sin que la mayoría de los observadores lo noten. JPEG ha utilizado esta ruta basada en DCT desde 1992; las alternativas modernas son mozjpeg (~5-10% más pequeño que libjpeg con el mismo SSIM, codificador más lento), libwebp (códec de imagen VP8/VP8L de Google, 2010) y AVIF (Alliance for Open Media, AV1 intra, 2019). Los formatos sin pérdida (PNG, GIF, WebP sin pérdida) reducen bytes mediante codificación por entropía — diccionario de ventana deslizante LZ77 más codificación Huffman o aritmética — y nunca alteran un solo píxel. El pipeline que usa esta página es completamente del lado del servidor. El navegador empaqueta cada imagen en una subida multipart firmada al endpoint de compresión de ToolAct (/image/compress). El servidor valida la solicitud y entrega los bytes a libvips — una biblioteca de procesamiento de imágenes de alto rendimiento y bajo consumo de memoria — que decodifica el origen, opcionalmente redimensiona el lado más largo para limitar las dimensiones de salida y recodifica a través de mozjpeg para JPEG, libwebp para WebP o libpng/oxipng para PNG. Los bytes codificados se transmiten de vuelta al navegador como respuesta de descarga, y el archivo temporal subido se elimina del disco en cuanto se vacía la respuesta. No hay archivado, ni pipeline de entrenamiento, ni revisión humana de los contenidos. La cuantización JPEG es el corazón del formato: una calidad de 90 conserva casi todos los coeficientes DCT, 75 empieza a descartar los de frecuencia media (visible en texto rojo sobre amarillo), 50 es la zona claramente JPEG donde aparecen artefactos de bloque en degradados suaves, y 25 produce posterización visible en rostros. La compresión PNG se basa en niveles zlib (DEFLATE) 0-9; el nivel 1 es rápido pero genera archivos más grandes, el nivel 9 exprime los últimos bytes de banners de color plano a costa de CPU. Los metadatos EXIF, perfiles ICC, XMP e IPTC suelen eliminarse al recodificar porque el codificador reconstruye la cabecera del archivo desde cero — una razón real por la que una foto de cámara de 200 KB puede convertirse en una subida de 60 KB incluso con la misma resolución, y una razón por la que los metadatos de procedencia y gestión del color deben conservarse por separado si importan.

• libvips (John Cupitt, LGPL) es el motor de procesamiento de imágenes del lado del servidor: un pipeline en streaming, dirigido por demanda, que mantiene bajo el uso de memoria incluso con entradas de 100 MP, y es la base de Sharp, del delegado vips de IM7 en ImageMagick y de los endpoints de conversión detrás de esta herramienta.
• mozjpeg (Mozilla, bifurcación de libjpeg-turbo con mejores modelos psicovisuales) produce archivos 5-10% más pequeños que libjpeg estándar con el mismo SSIM, pero es aproximadamente 3-5x más lento para codificar — el compromiso detrás de los valores web predeterminados de calidad JPEG 80-85 desde 2017.
• PNG es LZ77 + Huffman: el codificador encuentra secuencias de bytes repetidas hasta 32 KB atrás (ventana deslizante), emite pares (distancia, longitud), luego codifica Huffman el resultado. WebP sin pérdida (VP8L) usa una idea similar más parches Local Palette, generalmente superando a PNG en un 20-26% con los mismos píxeles RGBA.
• libwebp es el codificador/decodificador de referencia WebP de Google; el lado del servidor lo usa para escribir VP8 con pérdida (calidad 0-100, croma 4:2:0 por defecto) o VP8L sin pérdida (la calidad controla el esfuerzo de compresión, nunca la fidelidad de píxeles). La decodificación WebP está ampliamente disponible (Chrome 32+ 2014, Firefox 65+ 2019, Safari 14+ 2020), por lo que un WebP convertido es seguro para casi cualquier navegador moderno.
• El submuestreo de croma 4:2:0 predeterminado en JPEG (dos muestras de croma por 4 de luminancia) es lo que hace que el texto rojo sobre fondo amarillo se vea borroso a calidad 60 — el detalle de croma se descarta antes que el detalle de luminancia. Cambia a 4:4:4 (sin submuestreo) para capturas de pantalla y capturas de UI donde los bordes del texto importan.
• EXIF (Exchangeable image file format, JEITA CP-3451) y los perfiles de color ICC se eliminan al recodificar de forma predeterminada, por lo que un JPEG de iPhone de 6.3 MB suele quedar en 1.8 MB después de que el servidor lo procese. Esa es la razón por la que los fotógrafos aficionados ven reducirse el tamaño de archivo tras cada pasada por una herramienta web. Un problema práctico en lote: cuando una carpeta mezcla iconos pequeños (menos de 200x200 px, PNG con alfa), capturas de UI de color plano (PNG, muy alta compresibilidad) y fotos de teléfono (JPEG, contenido mayormente similar a ruido), un único deslizador de calidad es incorrecto para los tres. Los iconos quieren PNG sin pérdida o WebP sin pérdida; las capturas quieren JPEG 4:4:4 a calidad 85-90; las fotos quieren WebP con pérdida a calidad 75-80. Comprimir todo a calidad 60 ahorra bytes pero introduce bordes rojos en iconos, artefactos de anillo alrededor de capturas y bandas en las fotos. El pipeline más inteligente ejecuta cada categoría a través de una ruta de codificación diferente, razón por la cual el endpoint permite anular el formato de destino por archivo incluso cuando el usuario elige un valor predeterminado. De cara al futuro, JPEG XL (ISO/IEC 18181, 2022) es el formato que Google y Cloudflare han promovido desde 2020 como sucesor de JPEG: ~20% más pequeño a la misma calidad, modo sin pérdida completo, sin submuestreo de croma, y decodificación progresiva amigable con redes lentas. El soporte del navegador es parcial (Chrome deshabilitó JPEG XL en Chrome 110), por lo que la ruta de migración práctica por ahora es WebP a calidad 80, AVIF para recursos principales que necesiten el ahorro extra de bytes, y mantener un fallback JPEG para Safari antiguo o clientes de correo más viejos. La página expone calidad, dimensión máxima y formato de destino como los tres controles que importan; todo lo demás es detalle de implementación.
• Ciclo de vida de la conversión del lado del servidor: cada archivo subido se mantiene solo el tiempo necesario para ejecutar la decodificación libvips + recodificación y transmitir el resultado de vuelta. El archivo temporal se elimina al cerrar la respuesta, independientemente de si la conversión tuvo éxito o falló. Un JPEG de 24 MP que habría bloqueado el hilo principal del renderizador durante 200-500 ms se procesa completamente fuera del dispositivo del usuario.
• Migración: AVIF es el objetivo de próxima generación (Alliance for Open Media, AV1 intra, soporta 10/12 bits, alfa, animación). La codificación AVIF del lado del servidor a través de libavif/aom sigue siendo 10-30x más lenta que WebP, por lo que la mayoría de las páginas se quedan con WebP a calidad 80 y reservan AVIF para fotos principales que se beneficien del ahorro extra del 15-20% en bytes.