Saltar al contenido
AZ Tools

Inspector de estructura JPEG

Recorre un JPEG como lo hace un descodificador, marcador a marcador desde SOI hasta EOI, e indica qué es cada segmento, dónde empieza y cuántos bytes ocupa. La cabecera de trama (SOFn) da las dimensiones, la precisión de muestra, el número de componentes y los factores de muestreo, y su número de marcador es también lo que decide si el archivo es baseline o progresivo: el navegador dibuja un baseline línea a línea y un progresivo como una imagen completa que se va afinando, una diferencia de representación que no se ve en ningún píxel. Los factores de muestreo se traducen a la notación habitual 4:4:4, 4:2:2 o 4:2:0 y se muestran también en crudo, de modo que una foto blanda puede atribuirse al color guardado a media resolución y no al ajuste de calidad. Las tablas de cuantización se comparan con las tablas de ejemplo del anexo K de la norma: cuando son esas tablas escaladas por libjpeg se recupera la calidad exacta que las generó, y cuando no lo son el número es un promedio y se etiqueta como estimación, porque MozJPEG, Photoshop y casi todos los firmwares de cámara escalan de otra manera o traen tablas propias. Los segmentos de aplicación aparecen con su tamaño, que suele ser donde está la sorpresa: un perfil ICC repartido en varios trozos APP2, un bloque EXIF con miniatura incluida, un paquete XMP de un editor o un bloque de recursos de Photoshop, todo contado en bytes y como porcentaje del archivo. Del EXIF solo se informa su presencia y su tamaño; las etiquetas se leen en el visor EXIF de este sitio. La sección de codificación añade el intervalo de reinicio, cuántas tablas Huffman hay, cuántos barridos tiene el archivo y qué parte son datos con codificación entrópica, que es lo único que una recompresión puede reducir. Por último dice si el archivo termina de verdad en EOI y cuántos bytes vienen después, algo invisible para cualquier descodificador y la forma habitual de convertir un JPEG en un políglota. Lo que no hace es descodificar píxeles ni juzgar la calidad visual, y un archivo cortado dentro del barrido se rechaza en lugar de leerse a medias, porque pasado ese punto ningún dato es fiable.

Cómo usar

  1. Suelta un .jpg en la caja o haz clic para elegirlo. No se sube nada: los bytes se leen en la propia página.
  2. Empieza por el resumen: dimensiones, baseline o progresivo, submuestreo de croma y calidad estimada.
  3. Mira la tabla de segmentos de aplicación cuando un archivo pese más de lo esperado; en imágenes pequeñas un perfil ICC o una miniatura EXIF pueden pesar más que la foto.
  4. Abre las tablas de cuantización para ver las matrices reales y si son las del anexo K o las propias del codificador.
  5. Repasa la lista de marcadores en busca de rarezas: falta de cabecera JFIF, un APPn extraño o bytes después del EOI.

Preguntas frecuentes

¿Baseline o progresivo? ¿Cómo lo sabe la herramienta y por qué importa?
Sale de un solo byte. Un archivo baseline tiene una cabecera de trama SOF0 y uno progresivo tiene SOF2, y la herramienta informa del marcador que encuentra en lugar de adivinarlo mirando la imagen. Importa por cómo se ve mientras carga: un JPEG baseline se descodifica en un único barrido de arriba abajo, así que se rellena línea a línea, mientras que uno progresivo guarda varios barridos que refinan toda la imagen, de modo que una versión borrosa aparece tras los primeros kilobytes. Los progresivos suelen ser un pequeño porcentaje más ligeros porque sus coeficientes se agrupan de forma más comprimible, pero cuestan más CPU y memoria al descodificar, por eso muchos flujos dejan en baseline las imágenes muy pequeñas y las miniaturas.
¿Por qué la calidad es solo una estimación?
Los archivos JPEG no guardan un número de calidad. Guardan tablas de cuantización, y el deslizador de calidad de un codificador no es más que una regla para generarlas. libjpeg toma las tablas de ejemplo del anexo K y escala todos sus coeficientes con un único factor derivado del deslizador, así que ese escalado se puede invertir: cuando las tablas coinciden exactamente con una tabla del anexo K escalada, la herramienta lo dice y el número recuperado es el valor que realmente se pasó a libjpeg. Photoshop, MozJPEG, Guetzli y casi todos los firmwares de cámara usan tablas o escalados propios, y entonces lo máximo que se puede hacer es un promedio, por eso la cifra se marca como estimación. Volver a guardar también rompe el vínculo: un archivo codificado a 90 y recodificado a 95 tiene las tablas de 95 y el detalle de 90.
Mi foto se ve blanda incluso con calidad alta. ¿Qué debo mirar?
El submuestreo de croma, que es una decisión independiente de la calidad. En 4:2:0 los dos canales de color se guardan a media anchura y media altura, así que una línea roja sobre fondo azul, un texto de color o el borde de un logotipo saturado se reconstruyen con la cuarta parte de las muestras de color y se ven emborronados por alta que sea la calidad. La herramienta lo deduce de los factores de muestreo de la cabecera de trama y enseña los números en crudo junto a la notación: luminancia 2×2 con croma 1×1 es 4:2:0, luminancia 2×1 es 4:2:2 y todo a 1×1 es 4:4:4. La mayoría de codificadores pasan a 4:4:4 automáticamente a partir de calidad 90 o así, y por eso una exportación a 95 puede verse más nítida de lo que explicaría la diferencia de cuantización.
El archivo pesa mucho más de lo que merece la imagen. ¿Adónde fueron los bytes?
Mira el total de segmentos de aplicación. Un perfil ICC es el culpable habitual: un perfil v4 completo ocupa decenas de kilobytes y, como un segmento JPEG solo admite 65.533 bytes, se reparte en varios trozos APP2 que la herramienta cuenta. Los bloques EXIF suelen llevar una miniatura incrustada, los paquetes XMP de los programas de edición pueden ser varios kilobytes de XML y el bloque APP13 de Photoshop guarda trazados y porciones que nunca usarás en la web. La cifra de datos entrópicos cuenta la otra mitad de la historia: si el barrido es solo el 40% del archivo, recomprimir la imagen no servirá de nada, pero limpiar los metadatos sí.
¿Qué es un intervalo de reinicio y para qué lo querría?
Un segmento DRI fija un intervalo de reinicio y el codificador escribe entonces un marcador RST cada N MCU y reinicia ahí el estado del codificador entrópico. Eso cuesta algo de tamaño y a cambio da dos cosas: un descodificador puede resincronizarse tras un byte corrupto en lugar de perder el resto de la imagen, y puede descodificar en paralelo los bloques entre reinicios. La mayoría de los JPEG de la web no tienen ningún intervalo; se ven en salidas de escáner y de difusión, y en archivos preparados para descodificadores por hardware. Cuando existe, esta herramienta informa del intervalo en MCU, y los propios marcadores RST se saltan como parte del barrido en vez de listarse como segmentos.
¿Por qué se rechaza un archivo que mi visor abre sin problemas?
Porque a un visor se le permite ser indulgente y a un informe de estructura no. Si el archivo termina sin marcador EOI, se cortó dentro de los datos comprimidos, y un descodificador te enseñará las filas que alcanzó a leer, pero la cadena de marcadores no tiene final, así que cualquier total que se imprimiera sería el total de un fragmento. Lo mismo ocurre cuando un segmento declara una longitud que se sale del archivo: todo lo que hay después es ilegible, y presentar los segmentos anteriores como si el archivo estuviera intacto sería peor que no decir nada. Ambos casos son errores con nombre propio aquí, igual que un archivo que ni siquiera empieza por el marcador SOI, cuya causa habitual es un PNG renombrado a .jpg.

Herramientas relacionadas