Si una imagen se gira sin pérdidas, ¿por qué cambia el tamaño del archivo?

Estaba buscando métodos de rotación de imágenes sin pérdida y encontré esta pregunta que lo explica bastante bien:

¿Las rotaciones de "Windows Photo Viewer" son sin pérdida?

Así que creé un JPEG de 256 × 256 con píxeles aleatorios (filtro de nube de Photoshop) y luego lo roté usando Windows Picture Viewer. Después de la rotación, el tamaño del archivo en realidad aumentó, pero solo en la primera rotación. Cada rotación posterior a partir de entonces, el tamaño del archivo permaneció estático. Sé que está girando sin pérdidas porque lo he girado varias veces sin pérdida de calidad notable, mientras que una imagen de 257 × 257 que gira 20 veces se ha vuelto muy con pérdida.

Esto es probablemente causado por la codificación de entropía , que es la etapa final sin pérdidas de la compresión JPEG, después de que los datos de la imagen se hayan cuantificado para reducir su tamaño.

Cuando una imagen JPEG se gira sin pérdidas, esta capa de codificación final sin pérdidas debe deshacerse, los coeficientes DCT desempaquetados se mezclan, y luego los coeficientes barajados deben codificarse nuevamente en entropía. Dado que la eficiencia de la capa de codificación de entropía depende del orden de los coeficientes DCT dentro de cada bloque, que al girar la imagen cambiará, no debería sorprender que el archivo de imagen girado sea un poco más pequeño o más grande que el original.

También hay varias formas diferentes en que se puede realizar el paso de codificación de entropía, por lo que es muy posible que el tamaño del archivo de la misma imagen JPEG exacta pueda variar según el software que realiza la codificación. Algunas de las posibles diferencias entre codificadores incluyen:

• elección de codificación aritmética (rara pero potencialmente más eficiente, solía estar patentada) frente a codificación Huffman (más simple, estándar);
• elección de secuencial (cada bloque de 8x8 píxeles se codifica uno a la vez) frente a progresivo (los componentes de baja frecuencia de todos los bloques se codifican antes del orden de codificación de los componentes de mayor frecuencia, generalmente un poco más compacto);
• elección de usar las tablas de símbolos estándar de Huffman (más rápido, más simple, puede ser más eficiente para imágenes muy pequeñas) frente a tablas personalizadas optimizadas para cada imagen (generalmente más eficiente para imágenes grandes, más lenta y más compleja de codificar);
• si se usan tablas Huffman personalizadas, diferentes codificadores pueden generar tablas diferentes para los mismos datos de imagen;
• Varios detalles de bajo nivel del proceso de codificación en sí, como si incluir marcadores de reinicio en el flujo de datos y cuándo, también pueden variar entre codificadores.

Además, los "archivos JPEG" con los que la gente normalmente trabaja en realidad contienen datos de imagen comprimidos JPEG envueltos en un contenedor JFIF o Exif , que combina los datos de imagen con uno o más bloques de metadatos e introduce su propio conjunto de complicaciones. Incluso si el software que rota la imagen en realidad no realiza ningún cambio sustancial en los metadatos JFIF / Exif, simplemente reorganizar los datos podría afectar el tamaño del archivo en unos pocos bytes.

En particular, los metadatos JFIF / Exif pueden contener una o más miniaturas de la imagen a tamaño completo, y el software que rota las imágenes realmente debería regenerar (¡o también rotar sin pérdidas!) Las miniaturas para que coincidan con la nueva orientación de la imagen completa. tamaño de la imagen Esto solo podría explicar fácilmente la diferencia de tamaño observada.

Seguí adelante y repetí el experimento para ver si podía descubrir qué estaba pasando.

Procedimiento

Generé una imagen RGB aleatoria de 256 por 256 píxeles usando el filtro "Ruido sólido" en GIMP (Filtros> Renderizar> Nubes> Ruido sólido ...) usando la configuración predeterminada (que se muestra a continuación):

Y el resultado:

Luego guardé la imagen como JPEG usando la configuración predeterminada:

Luego transfirí la imagen a Windows y abrí la imagen con Windows Photo Viewer haciendo clic derecho en la imagen en el Explorador de archivos y seleccionando Vista previa en el menú. Luego giré la imagen usando los botones en la parte inferior, y guardé la imagen navegando a la siguiente imagen usando las teclas de flecha.

Para cada una de las pruebas a continuación, comencé con una copia de la imagen original y giré (hice clic en el botón de girar) el número correspondiente de veces antes de guardar. Aquí están los tamaños reslting ( ls -l -r):

                    size in bytes    last-modified date 
                          VVVVV        VVVVV
-rwxrwx--- 1 root vboxsf   6258 Nov  8 11:24 original.jpg
-rwxrwx--- 1 root vboxsf  23645 Nov  8 11:30 cw.jpg
-rwxrwx--- 1 root vboxsf  23636 Nov  8 11:30 cw-cw.jpg
-rwxrwx--- 1 root vboxsf  23649 Nov  8 11:30 cw-cw-cw.jpg
-rwxrwx--- 1 root vboxsf   6258 Nov  8 11:27 cw-cw-cw-cw.jpg
-rwxrwx--- 1 root vboxsf  23649 Nov  8 11:31 cw-cw-cw-cw-cw.jpg
-rwxrwx--- 1 root vboxsf  23649 Nov  8 11:29 ccw.jpg
-rwxrwx--- 1 root vboxsf  23636 Nov  8 11:29 ccw-ccw.jpg
-rwxrwx--- 1 root vboxsf  23645 Nov  8 11:29 ccw-ccw-ccw.jpg
-rwxrwx--- 1 root vboxsf   6258 Nov  8 11:27 ccw-ccw-ccw-ccw.jpg
-rwxrwx--- 1 root vboxsf  23649 Nov  8 11:30 ccw-ccw-ccw-ccw-ccw.jpg

Observaciones inmediatas

• Windows Photo Viewer (WPV) aumenta el tamaño dramáticamente; ¡La cantidad de aumento es alrededor de cuatro veces en esta prueba!
• Todas las imágenes nuevas aumentan aproximadamente al mismo tamaño, pero no son idénticas.
• WPV no vuelve a codificar ni a volver a guardar la imagen cuando la gira un múltiplo de 360 ​​grados. (La marca de tiempo, 11:27, es cuando los archivos se copiaron por primera vez).

El uso cmp -len archivos que deben tener contenido idéntico nos permite ver en qué difieren los archivos.

robert@unity ../jpeg-rotate-test % cmp -l cw.jpg ccw-ccw-ccw.jpg
 2223  63  62
 2224  60  71
 2226  60  64
 2227  60  66
robert@unity ../jpeg-rotate-test % cmp -l cw-cw.jpg ccw-ccw.jpg
 2223  63  62
 2224  60  71
 2226  60  64
 2227  62  64
robert@unity ..jpeg-rotate-test % cmp -l ccw.jpg cw-cw-cw.jpg
 2223  62  63
 2224  71  60
 2226  64  60
 2227  61  64
robert@unity ../jpeg-rotate-test % cmp -l cw.jpg cw-cw-cw-cw-cw.jpg
 2221  60  61
 2223  63  61
 2224  60  66
 2226  60  61
 2227  60  61
robert@unity ../jpeg-rotate-test % cmp -l ccw.jpg ccw-ccw-ccw-ccw-ccw.jpg
 2223  62  63
 2224  71  60
 2226  64  65
 2227  61  64

Estos archivos difieren en solo cuatro bytes (en realidad en una marca de tiempo), lo que significa que WPV está haciendo lo mismo cada vez; ahora solo necesitamos descubrir qué es eso.

Observaciones detalladas

Para esto utilicé JPEGsnoop para ver exactamente qué había en las imágenes.

Como los resultados son bastante largos, los he vinculado como una esencia . Aquí hay un resumen de las diferencias:

• GIMP usa solo un segmento APP0(JFIF) y COM(comentario) para los metadatos. WPV deja el APP0segmento intacto, pero curiosamente agrega un byte nulo al comentario (de modo que está terminado en nulo).

• WPV agrega dos APP1segmentos, que son metadatos Exif y XMP. Estos segmentos son 4286 y 12726 bytes, respectivamente. Juntos representan casi todo el aumento en el tamaño del archivo.

• GIMP produce un JPEG progresivo, mientras que WPV produce un JPEG de referencia (no progresivo). Por esta razón, la imagen de GIMP tiene múltiples segmentos de escaneo, mientras que la imagen de WPV tiene solo uno. En mi experiencia, la imagen progresiva es a veces ligeramente más pequeña.

• GIMP usó submuestreo de croma 1 × 1, mientras que WPV usó submuestreo 2 × 2. Esto me lleva a creer que WPV no está usando la rotación sin pérdidas "verdadera", a menos que de alguna manera pueda detectar que se trata de una imagen en blanco y negro.

Para resolver estos problemas, realicé una segunda prueba.

Procedimiento

Seguí pasos similares a la primera prueba. Creé una imagen aleatoria de 256 × 256 RGB usando el filtro de ruido RGB (Filtros> Nariz> Nariz RGB ...) con la siguiente configuración:

Aquí está el resultado:

Exporté el archivo como JPEG usando la siguiente configuración:

Progressive se ha desactivado, pero Submuestreo todavía está configurado en 4: 4: 4 (que es otro nombre para submuestreo 1 × 1). La calidad se incrementa a 98.

Copié la imagen y giré la copia en sentido horario; luego copié la versión girada y giró esa copia en sentido antihorario, para que podamos comparar directamente la calidad entre el original y la copia procesada por WPV.

Resultados

-rwxrwx--- 1 root vboxsf 159774 Nov  8 16:21 original-random.jpg
-rwxrwx--- 1 root vboxsf 222404 Nov  8 16:24 cw-random.jpg
-rwxrwx--- 1 root vboxsf 222467 Nov  8 16:24 cw-ccw-random.jpg

Aunque el aumento este tiempo es menor en términos relativos (alrededor del 40%), el aumento absoluto es aún mayor: alrededor de 62 kB. Esto sugiere que WMV está utilizando una codificación menos eficiente.

Voy a usar ImageMagick para comparar las dos imágenes:

robert@unity ../jpeg-rotate-test % compare -verbose -metric AE original-random.jpg cw-ccw-random.jpg null:
original-random.jpg JPEG 256x256 256x256+0+0 8-bit sRGB 160KB 0.000u 0:00.009
cw-ccw-random.jpg JPEG 256x256 256x256+0+0 8-bit sRGB 222KB 0.010u 0:00.010
Image: original-random.jpg
  Channel distortion: AE
    red: 0
    green: 0
    blue: 0
    all: 0
original-random.jpg=> JPEG 256x256 256x256+0+0 8-bit sRGB 0.050u 0:00.020

Hay cero píxeles diferentes entre el original y la copia girada. Por lo tanto, incluso si WPV no está usando una rotación sin pérdidas "verdadera", está haciendo un trabajo lo suficientemente bueno. Sospecho que sé lo que está sucediendo, y para explicarlo me desviaré un poco en las matemáticas detrás de la compresión JPEG.

El algoritmo de compresión JPEG divide una imagen en bloques de 8 × 8 píxeles. Cada uno de estos bloques se somete a una Transformación discreta de coseno (DCT) . Los coeficientes DCT resultantes describen el bloque como una suma de ondas de frecuencia diferente. El algoritmo luego "arroja" cierta información en las ondas de alta frecuencia que corresponden al ruido y a los detalles muy pequeños. El proceso de decodificación invierte el DCT, sumando las ondas almacenadas para recuperar el bloque.

Es posible rotar las "ondas" de DCT sin deshacer y rehacer la transformación (básicamente, convierte todas las ondas horizontales en ondas verticales y viceversa). Lo que creo que sucede en WPV es que la imagen se decodifica, gira y luego se vuelve a codificar. Durante el proceso de recodificación, dado que el tamaño de nuestra imagen es un múltiplo de 8 en ambas dimensiones, cada uno de los nuevos bloques corresponde a uno de los bloques originales. Es importante destacar que, dado que cada bloque no tiene componentes de alta frecuencia, el algoritmo no arroja ninguna información, y encuentra exactamente los componentes DCT correctos que tendría una rotación "verdadera" sin pérdidas.

Por último, volveré a ver los componentes de los archivos JPEG. Los resultados están nuevamente vinculados como lo esencial . Comparando los dos:

• La imagen WPV contiene 4286 + 2 bytes adicionales de metadatos Exif, 1 byte adicional en el comentario y 12,726 + 2 bytes de metadatos XMP. Esto es un total de 17,017 bytes de metadatos adicionales. ¿Para qué se utilizan todos esos datos? Me asomé al archivo con mi confiable editor hexadecimal y una copia de los estándares relevantes:

  • Los metadatos Exif están estructurados como una imagen TIFF, que contiene una serie de etiquetas (hay mucha más complejidad, pero pasaré por alto). La mayoría de los bytes en el segmento Exif están contenidos en dos etiquetas idénticas con un número de etiqueta EA1C(59,932 decimal). Ese número de etiqueta no está documentado en ningún lugar que pueda encontrar. Ambas etiquetas contienen 2060 bytes de tipo "indefinido", que son todos bytes nulos, excepto los primeros seis ( 1C EA 00 00 00 08). No tengo idea de cuáles son estas etiquetas, por qué hay dos y por qué deben ser de 2 kB cada una.

  • Los metadatos XMP son en realidad un documento XML incrustado completo con espacios de nombres y UUID largos, que solo contiene la cadena de versión de WPV (que ya estaba en los metadatos Exif). Sin embargo, eso solo representa alrededor de 400 bytes. El resto del segmento son 122 repeticiones de 100 espacios seguidos de una nueva línea . Eso es más de 12,000 bytes de espacio totalmente desperdiciado.

• Al igual que la prueba anterior, tanto GIMP como WPV usan las mismas tablas de cuantificación DCT. Esto significa que deberían estar calculando exactamente los mismos coeficientes DCT, razón por la cual las imágenes son exactamente iguales. No estoy seguro de si WPV utiliza las mismas tablas de cuantificación o si copia las tablas de la entrada.

• A diferencia de la prueba anterior, esta vez WPV utiliza submuestreo 1 × 1, por lo que en realidad puede detectar que se trata de una imagen en color (o al menos que se necesitan muestras más altas para volver a codificar la imagen sin pérdidas).

• GIMP y WPV usan diferentes tablas de Huffman (parte del paso de codificación de entropía). Las tablas para WPV son más grandes por un total de 279 bytes, y en un caso contienen 7 veces más códigos.

  Mirando las estadísticas de JPEGsnoop, podemos ver que algunos de estos códigos rara vez se usan. Por ejemplo, en la ID: 1, Class: ACtabla, de los 119 códigos de 16 bits definidos, solo 23 se utilizan realmente. En general, el segmento de escaneo real es 28.5% más grande en la versión WPV.

Resumen

• WPV puede no estar haciendo rotaciones "verdaderas" sin pérdidas, pero las rotaciones parecen ser prácticamente sin pérdidas.

• El tamaño adicional se debe en parte a una cantidad fija de metadatos agregados, y en parte a una codificación de entropía menos eficiente.

Información de versión:

• SO (Linux) ( uname -a):

  Linux unity 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u1 (2016-09-03) x86_64 GNU/Linux
  

• SO (Windows):

  

• GIMP (Linux): 2.8.14 (del paquete gimp, versión 2.8.14-1+deb8u1)

  

• Window Photo Viewer (según los metadatos de la imagen):

  Microsoft Windows Photo Viewer 10.0.10586.0
  

^{EDITAR : Esta respuesta se publicó antes de que supiera que los archivos habían aumentado de tamaño en alrededor de 9 KiB (9055 bytes para la imagen de 256 × 256, 9612 KiB para la imagen de 512 × 512).}

Con toda probabilidad, cuando giró la imagen por primera vez, Windows Picture Viewer hizo una (o ambas) de las siguientes cosas:

1. Se agregó una etiqueta EXIF ​​que no estaba en la imagen JPEG original (quizás la etiqueta Orientación);
2. Información modificada / agregada a una etiqueta que ya existía (quizás etiquetas de software de procesamiento o software de imagen).

Esto aumentó el tamaño del archivo debido a la etiqueta EXIF ​​adicional (y / o datos adicionales a las etiquetas existentes).

Las rotaciones posteriores no aumentaron el tamaño del archivo porque todas las etiquetas y / o datos de etiquetas que WPV habría agregado / modificado ya estaban allí. Solo cambió el valor de la etiqueta de orientación (y quizás también los valores de la etiqueta de fecha / hora).

EDITAR : es casi seguro que esta explicación no puede representar alrededor de 9 KiB de datos adicionales en el archivo. Además, en ausencia de otras razones para el aumento de tamaño, esta explicación esperaría que el aumento de tamaño fuera más o menos constante (módulo de algunas diferencias de longitud entre representaciones de cadena de datos numéricos, probablemente unos pocos bytes). Obviamente, eso no es lo que está sucediendo aquí, al menos no la explicación completa.

Sin ingeniería inversa el jpeg en / decoder es imposible decirlo con certeza. En realidad, hay una serie de estándares JPEG y, contrariamente a la creencia popular, no todos pueden modificarse sin volver a codificar.

Es posible que el primer guardado sea una reescritura con pérdidas en su sabor jpeg favorito y las rotaciones posteriores son un simple ajuste de metadatos o una operación directamente en la tabla DCT (que es posible para algunos esquemas de codificación).

El aumento en el tamaño del archivo también puede incluir algunos metadatos adicionales, aunque 9k parece mucho, es posible. El aumento también puede explicarse mediante la adición de una miniatura que puede no haber estado presente en la salida de GIMP. Es posible que podamos obtener más información de los archivos directamente (antes de WPV y después).

En cualquier caso, tratar de trabajar sin problemas con jpeg es realmente una tontería, ya que solo es útil con ciertos tamaños de imagen, no todos los decodificadores y codificadores son idénticos y requiere que esos editores trabajen directamente con el contenido jpeg en el que no puede confiar para ser el caso ... Solo porque lo haga ahora no significa que continuará en el futuro.

Su mejor opción es trabajar con un formato sin pérdidas y evitar el dolor por completo.

La rotación JPEG sin pérdida solo es posible sin la introducción de artefactos de límite si las dimensiones de la imagen son múltiplos del tamaño del bloque (generalmente [/ siempre?] 8). Consulte la página de manual de jpegtran (lo siento, no tengo un buen enlace canónico para ello; siéntase libre de editar si encuentra uno) para obtener detalles sobre lo que implica:

La transformación de transposición no tiene restricciones con respecto a las
dimensiones de la imagen . Las otras transformaciones funcionan de manera bastante extraña si las dimensiones de la imagen no son múltiplos del tamaño de la iMCU (generalmente 8 o 16 píxeles), porque solo pueden transformar bloques completos de datos del coeficiente DCT de la manera deseada.

El comportamiento predeterminado de jpegtran al transformar una imagen de tamaño impar
está diseñado para preservar la reversibilidad exacta y la
coherencia matemática del conjunto de transformación. Como se indicó, la transposición
puede voltear toda el área de la imagen. La duplicación horizontal deja intacta cualquier columna parcial de iMCU en el borde derecho, pero puede voltear todas las filas de la imagen. Del mismo modo, la duplicación vertical deja intacta cualquier fila parcial de iMCU en el borde inferior, pero puede voltear todas las columnas. Las otras transformaciones se pueden construir como secuencias de operaciones de transposición y volteo; para mantener la coherencia, sus acciones en los píxeles de borde se definen para que sean las mismas que el resultado final de la secuencia de transposición y volteo correspondiente.

Para un uso práctico, puede preferir descartar los
píxeles de borde no transformables en lugar de tener una tira de aspecto extraño a lo largo de los
bordes derecho o inferior de una imagen transformada. Para hacer esto, agregue el modificador -trim:

Sospecho que Windows Photo Viewer está evitando este problema al realizar la descompresión y la recompresión de alta calidad extrema para simular un comportamiento sin pérdidas cuando las dimensiones de la imagen no son múltiplos de 8, en lugar de realizar una rotación sin pérdidas. Una buena utilidad solo haría artefactos reales sin pérdidas y todo, o soltaría unos pocos píxeles, en lugar de arruinar la calidad de toda la imagen (y aumentar el tamaño del archivo).

No tengo una respuesta definitiva, pero algunas teorías posibles de por qué sucedió eso. Algunos tipos de archivos funcionan de tal manera que dos códigos diferentes para una imagen de ese tipo de archivo no necesariamente producen imágenes diferentes. Por ejemplo, el tipo de archivo PNG funciona de esa manera porque permite un fondo transparente pero una imagen con un fondo transparente y una que es igual excepto que el mismo fondo es blanco aparece exactamente de la misma manera. Se dice que un archivo de imagen está comprimido si ocupa menos de 3 bytes de memoria por píxel. Creo que, excepto los que tienen un fondo transparente, no hay dos archivos PNG que generen exactamente la misma imagen. Cuando guarda una imagen como PNG, la convierte en un código que genera la imagen original y, a excepción de imágenes muy inusuales, como una en la que cada píxel es un color aleatorio de los 2 ^ 24 colores, el código ocupará menos memoria que 3 bytes por píxel, por lo que guardar como PNG se dice que es una compresión sin pérdidas. Por otro lado, para ahorrar memoria, solo se pueden generar ciertas imágenes mediante el código de un archivo de imagen JPEG. Probablemente haya más de un tipo de archivo JPEG y no sé si alguno de ellos tiene la propiedad de que dos imágenes diferentes de ese tipo de archivo puedan generar exactamente la misma imagen. Supongo que muchas veces simplemente giró una imagen y luego la guardó como JPEG y le dará una explicación de lo que sucedió bajo el supuesto de que eso fue lo que hizo, lo que no sé si es cierto. Una rotación que realizó no tiene pérdidas si hay una manera de recuperar exactamente el mismo código de archivo de imagen que tenía antes de rotarlo y guardarlo. Es posible que no esté en lo correcto al decir que realmente hizo una rotación sin pérdidas. Si realmente no tuvo pérdidas,

Las razones detrás de esto son algunas

la forma en que las imágenes se codifican y comprimen cambiará el tamaño simplemente debido al algoritmo de compresión. puede probar esto guardándolo como un mapa de bits y luego girándolo. En ese formato o en cualquier formato sin formato, el tamaño debe permanecer igual. Si no es así, el programa que guarda la imagen está agregando nuevos datos, posiblemente algunos metadatos o algo así.

Pero, ¿por qué giras un JPEG 20 veces?

Por cómo funciona la compresión de imágenes . Cualquier formato como PNG o JPG en general no conserva el tamaño del archivo después de la rotación.

Para el compresor, la imagen rotada es solo una imagen diferente, debido a cómo funciona la heurística de compresión no hay garantía de que comprimirá una imagen rotada de la misma manera .

Por supuesto, si la compresión no tiene pérdidas, si gira la imagen 4 veces la cuarta vez, la imagen volverá a ser la misma (girada hasta que se incline como original): en ese caso, debería volver a tener el mismo tamaño comprimido, de lo contrario se debe a una de las siguientes razones :

• Metadatos agregados : el programa agregó un fragmento de texto por alguna razón
• Compresor cambiado: el programa puede optar por volver a guardar la imagen como original si no hay cambios, pero si aplica algún cambio (incluso 4 rotaciones de 90 grados) puede decidir volver a comprimir la imagen nuevamente usando la suya propia. compresor (el programa ya no sabe que sigue siendo la misma imagen).
• En general, el mismo compresor (libPNG o libJPG) produce resultados muy diferentes en diferentes implementaciones, diferentes versiones de la misma biblioteca y con diferentes parámetros de compresión (también el sistema operativo y el compilador hacen la diferencia aquí a veces).

La compresión de imágenes funciona al comprimir imágenes en trozos 4x4 u otros tamaños. En general, un compresor ve una imagen rotada como una imagen diferente, sin embargo, dado que un trozo de píxeles comprimido es solo una descomposición lineal, si los trozos de la imagen son iguales, es posible simplemente Transponer / Reflejar las matrices de descomposición lineal manteniendo efectivamente la misma calidad:

Tenga en cuenta que esto debe implementarse en función de cada característica , y eso también explica el aumento inicial de tamaño => en la primera rotación, solo intenta comprimir la imagen en trozos que son giratorios:

• Si no lo hace: la calidad de la imagen se degrada

• Si tiene éxito, aumenta el tamaño solo una vez, luego cada rotación mantiene la misma calidad.

• Esa operación es exitosa solo si la imagen está hecha por partes iguales. (el tamaño de la imagen es múltiplo del tamaño del fragmento).

La respuesta de scottbb es incorrecta y puedes hacer una prueba simple:

• Abra la imagen original: captura de pantalla
• Rotar la imagen 4 veces con WPV: captura de pantalla
• Compara las 2 capturas de pantalla

Verá que la imagen cambia (se vuelve a comprimir en la primera rotación). Sin embargo, ese cambio es limitado en el tiempo, ahora puede rotarlo nuevamente sin pérdida de calidad (si la imagen tiene un tamaño que es un múltiplo de 8)

Para responder directamente a OP:

Sé que está girando sin pérdidas

No está girando sin pérdidas, pierde calidad al menos una vez (en la primera rotación: porque primero debe comprimirlo de una manera que pueda rotarse), luego mantiene su calidad.