¿Existe algún beneficio en la calidad, el tamaño del archivo u otro beneficio en el hecho de que los tamaños JPEG sean múltiplos de 8 px o 16 px?

Question

El proceso de codificación de compresión JPEG divide una imagen determinada en bloques de 8x8 píxeles, trabajando con estos bloques en futuras compresiones con y sin pérdida. [fuente]

También se menciona que si la imagen es un bloque múltiple de 1MCU (definido como una unidad codificada mínima, "generalmente 16 píxeles en ambas direcciones"), se pueden realizar modificaciones sin pérdidas en un JPEG. [fuente]

Estoy trabajando con imágenes de productos y me gustaría saber si y cuánto beneficio se puede obtener al usar múltiplos de 16 en el tamaño de mi imagen final (por ejemplo, usar una imagen con un tamaño de 480 px por 360 px) vs.un no múltiplo de 16 (como 484x362).En este ejemplo no me interesan más modificaciones, ediciones o recompresión de la imagen final.

Para intentar acercarme a una respuesta específica donde sé que debe haber en gran medida generalidades:Dada una imagen de 480x360 de 64k y guardada con la máxima calidad en Photoshop [ejemplo]:

• ¿Puedo esperar alguna pérdida de calidad de una imagen de 484x362?
• ¿Qué cantidad de tamaño de archivo adicional puedo esperar (para este ejemplo, el espacio adicional serían píxeles blancos)?
• ¿Existen otras desventajas de crecer más allá de la cuadrícula de 8px?

Sé que es arbitrario usar ese ejemplo específico, pero aún así sería útil (para mí y potencialmente para cualquier otra persona que esté considerando el tamaño de una imagen) entender con qué nivel de compromiso estaría enfrentando al romper la cuadrícula que no es de 8px.

La cuestión clave aquí es un debate que he tenido sobre si las imágenes divisibles de 8 píxeles son de mayor calidad que las imágenes que no son divisibles por 8 píxeles.

Answer 1

8 píxeles es el límite.La razón es que las imágenes JPEG son simplemente una matriz de bloques DCT de 8x8;Si la resolución de la imagen no es mod8 en ambas direcciones, el codificador debe rellenar los lados hasta la siguiente resolución mod8.En la práctica, esto no es muy costoso en bits;Lo que es mucho peor son los casos en los que una imagen tiene líneas negras nítidas (como una imagen en forma de buzón) que no se encuentran en los límites de los bloques.Esto es especialmente problemático en la codificación de vídeo.La razón por la que esto es un problema es que la transformada de frecuencia de una línea definida es una distribución gaussiana de coeficientes, lo que da como resultado una enorme cantidad de bits para codificar.

Para aquellos curiosos, el método más común para rellenar bordes en compresión intra (como imágenes JPEG) es reflejar las líneas de píxeles antes del borde.Por ejemplo, si necesita rellenar tres líneas y la línea X es el borde, la línea X+1 es igual a la línea X, la línea X+2 es igual a la línea X-1 y la línea X+3 es igual a la línea X- 2.Esto minimiza de manera bastante efectiva el costo en coeficientes de transformación de las líneas adicionales.

Sin embargo, en la intercodificación, los algoritmos de relleno generalmente simplemente duplican la última línea, porque el método de espejo no funciona bien para la intercompresión, como en la compresión de video.

Answer 2

A veces es necesario utilizar límites de 16 píxeles en lugar de 8 debido al submuestreo;cada segundo píxel se desecha durante el proceso de codificación, y esos bloques DCT de 8x8 comenzaron como 16x16 y se decodificarán nuevamente a 16x16.Esto no será un problema en la configuración de calidad más alta.

Answer 3

El hecho de que las dimensiones de la imagen sean múltiplos de 8 o 16 no afectará mucho el tamaño en el disco, pero puede obtener ahorros espectaculares si puede alinear el contenido visual con la cuadrícula de 8x8 píxeles, como si hubiera un patrón repetido o textura en la imagen.

Answer 4

Un JPG con tamaños multiplicados por 8 también se puede rotar/voltear sin pérdida de calidad.Por ejemplo, gthumb puede hacer esto en Linux.

Answer 5

Qué Tometzky dicho.Si no tiene el múltiplo correcto, los algoritmos de giro y rotación sin pérdidas no funcionan.Esto se debe a que el relleno de la derecha/abajo que se puede ignorar con seguridad ahora termina en la izquierda/arriba, donde no se puede.