Quels facteurs provoquent ou empêchent la «perte générationnelle» lorsque les fichiers JPEG sont recompressés plusieurs fois?

Pendant des années, j'ai cru que recompresser des fichiers JPEG plusieurs fois dégraderait progressivement sa qualité jusqu'à ce qu'ils soient un gâchis méconnaissable, comme le fait la photocopie de photocopies. Cela a un sens intuitif car JPEG est un format avec perte. Il existe également d'autres questions et réponses qui affirment qu'il en est ainsi:

• Quelle qualité d'image est perdue lors de la ré-enregistrement d'une image JPEG dans MS Paint?

• L'ouverture et la fermeture d'un fichier JPEG diminuent-elles simplement la qualité de l'image?

Cependant, j'ai également lu que la recompression des JPEG au même niveau de qualité ne dégradera pas la qualité de l'image. Cela va à l'encontre de la dégradation progressive décrite ailleurs.

Que se passe- t-il techniquement lorsqu'un JPEG est recompressé?  Qu'est-ce qui se perd et comment? L'image se transformera- t-elle vraiment en désordre neigeux qui apparaissait à la télévision? Qu'en est-il de ces vidéos montrant des images qui se désagrègent après avoir été recompressées plusieurs fois?

(Veuillez ne pas simplement faire signe de la main et faire appel au concept général de perte.)

(Cette question et les réponses qu'elle a suscitées jusqu'à présent se concentrent sur les facteurs techniques (paramètres spécifiques et manipulations d'image) qui provoquent ou empêchent la dégradation de l'image lorsqu'un fichier JPEG est recompressé plusieurs fois.)

Presque toutes les pertes de qualité d'image se produisent la première fois qu'une image est compressée au format JPEG. Quel que soit le nombre de fois où un JPEG est recompressé avec les mêmes paramètres , les pertes générationnelles sont limitées à une erreur d'arrondi.

• Les limites du MCU restent intactes (blocs 8x8).

• Le sous-échantillonnage de chrominance est désactivé.

• DQT constant (même réglage de qualité).

Cependant, les erreurs d'arrondi peuvent être importantes pour chaque itération si les critères ci-dessus ne sont pas remplis, et il est prudent de conserver des sauvegardes de tous les fichiers d'origine.

L'algorithme de compression JPEG

1. Convertissez l'espace colorimétrique. Si vous le souhaitez, sous-échantillonnez les informations de couleur (sous-échantillonnage de chrominance) (avec perte) . Si elle n'est pas sous-échantillonnée, la perte d'informations est le résultat d'une erreur d'arrondi .

2. Segmentation. Divisez chaque canal en blocs 8x8 (MCU = unité de codage minimale). (Sans perte)

   Remarque: Si le sous-échantillonnage de chrominance est activé, les MCU peuvent effectivement être de 16 x 8, 8 x 16 ou 16 x 16, en termes d'image d'origine. Cependant, les MCU sont toujours tous des blocs 8x8.

3. Transformation cosinus discrète (DCT) sur chaque MCU. La perte d'informations est le résultat d'une erreur d'arrondi .

4. Quantification.  La valeur dans chaque cellule du MCU est divisée par un nombre spécifié dans une table de quantification (DQT). Les valeurs sont arrondies vers le bas, dont beaucoup deviendront nulles. Il s'agit de la principale partie avec perte de l'algorithme.

5. Scan Zig-Zag. Réorganisez les valeurs dans chaque MCU en une séquence de nombres suivant un motif en zig-zag. Les zéros qui se sont produits pendant la quantification seront regroupés. (Sans perte)

6. DPCM = modulation différentielle de code d'impulsion. Convertissez les séquences de nombres en une forme plus facile à compresser. (Sans perte)

7. RLE = Run Length Encoding. Les zéros consécutifs sont compressés. (Sans perte)

8. Entropie / codage de Huffman. (Sans perte)

Recompression de JPEG

Notez que le sous- échantillonnage des canaux de couleur et la quantification sont les seules étapes intentionnellement avec perte . Mis à part l'erreur d'arrondi pour l'instant, toutes les autres étapes sont sans perte. Une fois la quantification effectuée, inverser et répéter l'étape donne des résultats identiques. En d'autres termes, la re-quantification (avec le même DQT) est sans perte .

En principe, il est possible de créer un algorithme de rééchantillonnage sans perte après le premier passage. Cependant, avec l'implémentation dans ImageMagick, les couleurs peuvent changer radicalement avant d'atteindre l'état d'équilibre, comme le montre l'image de ths.

Dans des conditions optimales, la recompression d'un JPEG avec les mêmes paramètres de qualité entraînerait exactement le même JPEG. En d'autres termes, la recompression des fichiers JPEG est potentiellement sans perte . Dans la pratique, la recompression des fichiers JPEG n'est pas sans perte, mais sujette à, et limitée par, une erreur d'arrondi. Bien que les erreurs d'arrondi finissent souvent par converger vers zéro , de sorte que la même image exacte soit recréée, le sous-échantillonnage de la chrominance peut entraîner des changements de couleur importants.

Démonstration (même réglage de qualité)

J'ai écrit le bashscript suivant , qui utilise ImageMagick pour recompresser à plusieurs reprises un fichier JPEG avec un paramètre de qualité donné:

#!/usr/bin/env bash
n=10001; q1=90
convert original.png -sampling-factor 4:4:4 -quality ${q1} ${n}.jpg

while true ; do
   q2=${q1}            # for variants, such as adding randomness
   convert ${n}.jpg -quality ${q2} $((n+1)).jpg
   #\rm $((n-5)).jpg   # uncomment to avoid running out of space
   n=$((n+1))

   echo -n "$q2  "
   md5sum ${n}.jpg
done

Après l'avoir laissé fonctionner pendant quelques centaines d'itérations, j'ai couru md5sumsur les résultats:

d9c0d55ee5c8b5408f7e50f8ebc1010e  original.jpg

880db8f146db87d293def674c6845007  10316.jpg
880db8f146db87d293def674c6845007  10317.jpg
880db8f146db87d293def674c6845007  10318.jpg
880db8f146db87d293def674c6845007  10319.jpg
880db8f146db87d293def674c6845007  10320.jpg

Nous pouvons voir que, en effet, l'erreur d'arrondi a convergé vers zéro, et la même image exacte est reproduite, encore et encore .

J'ai répété cela plusieurs fois avec différentes images et paramètres de qualité. Habituellement, l'état d'équilibre est atteint et la même image exacte est reproduite encore et encore.

Qu'en est-il des résultats de @ mattdm ?

J'ai essayé de répliquer les résultats de mattdm en utilisant Imagemagick sur Ubuntu 18.04. L'original était une conversion brute en TIFF dans Rawtherapee, mais il semble qu'il ne soit plus disponible. À sa place, j'ai pris la version agrandie et je l'ai réduite à sa taille d'origine (256x256). Ensuite, j'ai recomprimé à plusieurs reprises à 75 jusqu'à ce que j'obtienne la convergence. Voici le résultat (original, 1, n, différence):

Mes résultats sont différents. Sans le véritable original, la raison de la différence est impossible à déterminer.

Et le montage de @ ths ?

J'ai recompressé l'image depuis le coin supérieur gauche du montage jusqu'à convergence à 90. Voici le résultat (original, 1, n, différence):

Après avoir activé le sous-échantillonnage de chrominance, les couleurs changent au moment où l'état stationnaire est atteint.

Changement parmi un petit nombre de paramètres

En modifiant la variable q2, le paramètre de qualité peut être limité à un ensemble de valeurs uniformément réparties.

q2=$(( (RANDOM % 3)*5  + 70 ))

Pour un petit nombre de choix de réglage, l' équilibre peut finalement être atteint , ce qui se voit lorsque les valeurs md5 commencent à se reproduire. Il semble que plus l'ensemble est grand, plus il prend de temps et pire l'image devient, avant que l'équilibre ne puisse être atteint.

Ce qui semble se produire à l'équilibre est que le coefficient DCT avant la quantification doit être divisible par toutes (ou la plupart) des valeurs quantiques. Par exemple, si vous basculez entre deux DQT où le coefficient DCT est divisé alternativement par 3 et 5, l'équilibre sera atteint lorsque le coefficient DCT est divisible par 15. Cela explique pourquoi la baisse de qualité est beaucoup plus importante que la différence entre les paramètres d'origine.

Changement parmi un plus grand nombre de paramètres

Bourriquet n'est pas content quand q2on le change ainsi:

q2=$(( (RANDOM % 9)  + 90 ))

Pour faire une vidéo, utilisez ffmpeg:

rename 's@1@@' 1*.jpg
ffmpeg -r 30 -i %04d.jpg -c:v libx264 -crf 1 -vf fps=25 -pix_fmt yuv420p output.mp4

Regarder les 9999 premières itérations, c'est presque comme regarder l'eau bouillir. Pourrait vouloir doubler la vitesse de lecture. Voici Bourriquet après 11999 itérations:

Et si les limites du MCU changent?

Si des changements se produisent un nombre limité de fois, une recompression répétée est susceptible d'atteindre l'état d'équilibre. Si des changements se produisent à chaque itération, l'image se dégradera probablement de la même manière que lorsque DQT change.

• C'est ce qui se passe dans les vidéos qui font pivoter une image avec des dimensions qui ne sont pas divisibles par 8.

Et l'édition?

L'effet de la recompression après l'édition dépend de l'édition particulière effectuée. Par exemple, l'enregistrement avec le même paramètre de qualité après réduction des artefacts JPEG réintroduirait les mêmes artefacts. Cependant, l'application d'un changement localisé, tel qu'un pinceau de cicatrisation, n'affecterait pas les zones non touchées.

La plus grande baisse de qualité d'image se produit la première fois que le fichier est compressé avec un paramètre de qualité donné. Par la suite, la recompression avec le même paramètre ne devrait pas introduire de changement supérieur à l'erreur d'arrondi. Je m'attends donc à ce que les cycles d'édition-réenregistrement à un paramètre de qualité donné ressemblent à toute autre image enregistrée avec le même paramètre de qualité (tant que les limites du MCU restent intactes et que le sous-échantillonnage de chrominance est désactivé ).

Et ces vidéos?

• Implémentation JPEG défectueuse? ( Ré-enregistrer 500 fois avec Photoshop au 10/12. )

• Modification des paramètres de qualité. (La plupart des vidéos.)

• Perturber les limites du MCU. (Recadrage ou rotation )

• D'autres manœuvres qui réduisent la qualité de l'image ou interfèrent avec l'algorithme JPEG?

Puis-je écraser mes originaux avec des fichiers JPEG recompressés?

Il est prudent de conserver des sauvegardes de tous les fichiers d'origine, mais si vous en écrasez accidentellement un, les dommages sont probablement limités. Il serait également judicieux de travailler en JPEG avec le sous-échantillonnage de chrominance désactivé.

JPEG ne peut pas être utilisé pour des images qui utilisent plus de 8 bits par couleur.

La perte de recompression est réelle, surtout lorsque vous travaillez avec des niveaux plus élevés de compression JPEG.

En théorie, si vous réenregistrez un fichier JPEG avec les mêmes paramètres exacts et que vous avez aligné votre recadrage sur des blocs 8 × 8, la dégradation devrait être minime. Cependant, si vous utilisez un niveau de compression élevé, vous verrez une perte supplémentaire, car les artefacts introduits par la compression initiale sont des modifications permanentes de l'image et seront également recompressés, provoquant plus d'artefacts.

Si vous ré-enregistrez avec un faible niveau de compression (haute qualité, comme "100" dans Gimp ou 11 ou 12 dans Photoshop), tout artefact nouvellement ajouté sera difficile à remarquer. Il ne fera pas l'image une meilleure , mais pas significativement pire. Cependant, il va introduire des changements à travers l'image.

Comme test rapide, j'ai utilisé ImageMagick pour recompresser une image JPEG encore et encore à 75%. Les exemples ci-dessous sont téléchargés en tant que fichiers PNG pour éviter une recompression supplémentaire, et ont été doublés en taille lorsque j'ai converti en PNG pour rendre l'effet plus évident. (Les originaux utilisés dans le test n'ont pas été doublés.) Il s'avère qu'après huit rééchantillonnages, l'effet a convergé vers un résultat parfaitement stable, où la recompression entraîne à nouveau un fichier identique bit par bit.

Voici l'original non compressé:

Voici le résultat de passer à 75% JPEG:

Et voici ce qui a été sauvegardé:

Cette sauvegarde d'une seconde entraîne une grande dégradation supplémentaire!

Et voici l'image finale convergée (8ème passe):

Encore une fois, les couleurs sont nettement plus contrastées, y compris certains motifs de fausses couleurs, et les artefacts en blocs sautent davantage. L'algorithme converge, mais vers une version significativement dégradée. Alors ne fais pas ça.

Mais voici la même chose avec un niveau de qualité de 99%, après 9 passes (le point où il converge donc les autres passes sont identiques):

Ici, la différence s'enregistre à peine. (Je veux dire littéralement; comparez-les pixel par pixel à la version non compressée et la déviation n'est qu'un très léger bruit aléatoire.) Alors, que se passe-t-il si je reviens à cette première image à 75% et que je réenregistre à 99%? Eh bien, ceci (après une seule fois):

Enregistrement à haute qualité est certainement visiblement mieux que resaving avec les mêmes paramètres, un peu à ma grande surprise. Mais, il y a une nouvelle dégradation évidente autour de la garniture rose et des yeux. Avec la version recyclée des mêmes paramètres, les artefacts JPEG sont exagérés à chaque recompression. Avec la faible résolution et la faible qualité que j'ai choisies, cela s'avère pire que de tout recompresser différemment.

Sur ces vidéos: j'ai trouvé celle-ci comme l'un des meilleurs succès de Google. Notez qu'il est dit dans la description:

C'est ce qui se produit si vous réencodez plusieurs fois une image JPEG, avec des paramètres aléatoires de haute qualité (85 ou plus).

L'accent a été ajouté - cela explique pourquoi il n'y a pas de convergence, car au lieu d'enregistrer avec les mêmes paramètres ou d'enregistrer en super haute qualité, des paramètres aléatoires sont utilisés à chaque fois .

La deuxième vidéo que j'ai trouvée dit:

Une image JPEG a été copiée et tournée d'une révolution complète pour chaque image. [...] (596 actions "tourner dans le sens horaire")

Donc, encore une fois, quelque chose a été fait pour que les erreurs s'accumulent.

Dans tous les cas, pour la retouche photo pratique , il convient de mentionner qu'économiser 75% une fois est bien pire que de la sauvegarder à 99% un million de fois . Dans mon cas d'exemple, les artefacts à 75% sont si évidents que la dégradation supplémentaire est comme le déversement d'eau dans l'océan. Si vous enregistrez à un niveau suffisamment élevé pour que ces artefacts ne soient pas vraiment visibles, enregistrer à nouveau avec les paramètres d'origine est une bonne stratégie. Bien sûr, si vous pouvez vous en tenir à toujours travailler à partir d'originaux non compressés, vous êtes mieux.

Si, pour une raison quelconque, vous devez (ou préférez fortement) simplement travailler avec JPEG, réglez votre appareil photo pour enregistrer dans la meilleure qualité possible , même si vous ne remarquez pas la différence dans les fichiers initiaux. Voir Cela vaut-il la peine d'utiliser le paramètre de qualité Premium JPEG de Pentax? pour en savoir plus - pas nécessairement vraiment spécifique au Pentax.

La recompression a un effet mesurable sur la qualité de l'image et cet effet est beaucoup plus prononcé lors de la modification des taux de compression.

Comme une vérification rapide ici, comme certaines valeurs SSIM pour les opérations effectuées sur une image de test contenant une combinaison d'entités linéaires et d'entités continues. J'ai choisi JPG95 parce que c'est ce qu'on m'a appris à utiliser à l'école Ad-photo et JPG83 parce que c'est courant chez les fournisseurs de contenu numérique.

• Enregistrer l'image Tiff au format JPG95 - .9989
• Enregistrer l'image Tiff sous JPG83 - .9929
• Réenregistrer l'image JPG95 au format JPG95 10 fois - .9998
• Réenregistrer l'image JPG83 au format JPG83 10 fois - .9993
• Réenregistrer JPG95 en tant que JPG83 puis réenregistrer en tant que JPG95 - .9929
• Réenregistrer JPG95 en JPG83 puis JP83 en JP92 puis JPG92 en JPG86 - .9914

Ainsi, la quantité de similitude structurelle perdue lors de la réenregistrement à la même compression 10 fois est 1 / 10e de celle perdue en l'enregistrant à la qualité du tiff. Cependant, la perte de qualité résultant du changement de la compression JPG, même une fois, est la même que la qualité perdue lors de l'enregistrement de cette image de Tiff en JPG.

Je vais exécuter ce test de plusieurs façons et mettre à jour.

Méthodologie : Dans ImageJ:

1. Convertir Tiff RGB en niveaux de gris 8 bits
2. Enregistrer JPG95 et JPG83 de Tiff Original
3. Effectuer d'autres opérations de réenregistrement comme spécifié
4. Charger des images de comparaison et utiliser le plug-in d'index SSIM

REMARQUE: de nombreuses personnes qui consultent les valeurs SSIM pour la première fois les lisent sous forme de pourcentages et supposent que la différence est faible. Ce n'est pas forcément vrai. Les valeurs SSIM doivent être comparées les unes par rapport aux autres plutôt que considérées comme un écart par rapport à 1.

Rien de tel qu'une expérimentation. Le script bash suivant (écrit sous Linux, pourrait fonctionner sur OSX si vous avez ImageMagick ):

• en commençant par une première image (nommée step000.jpg )
• prend un fichier JPEG, ajoute un point blanc (pour prouver qu'il s'agit d'une nouvelle image) et l'enregistre en tant que (PNG sans perte)
• prend le PNG et le recompresse en JPEG (donc nous ne compressons jamais JPEG en JPEG, et ne pouvons pas émettre l'hypothèse que le logiciel copie simplement les blocs encodés)
• crée une image qui montre les différents pixels entre les deux JPEG
• rincer et répéter, en utilisant le JPG de sortie de l'étape précédente

Le résultat est que:

1. il n'y a pas beaucoup de perte avec des qualités JPG élevées
2. les erreurs d'arrondi finissent par se régler, après un petit nombre de générations, les choses ne se dégradent plus.

Bien sûr, tout cela suppose que le JPEG est enregistré par le même logiciel avec les mêmes paramètres à chaque fois.

#! /bin/bash
# Runs successive JPEG saves on an image to evaluate JPEG losses

# convert & compare command from imagemagick
# if you use a recent version of IM, set these variables to:
# compare="magick compare"
# convert="magick convert"
convert=convert
compare=compare

dotradius=2
defaultsteps=10
defaultquality=90 # default quality for "convert"

function usage {
        echo "Usage: $0 [quality [steps]]"
        echo ""
        echo "Where:"
        echo "       - 'quality' is the quality factor of the JPEG compression "
        echo "          (1-100, 100 is best, default is $defaultquality)"
        echo "       - 'steps' is the number of successive steps to perform"
        echo "         (default is $defaultsteps)"
        echo ""
        echo "Produces:"
        echo "   - successive saves of a JPEG image to test JPEG-induced losses."
        echo "   - compare images with the original file and the 1st JPEG save."
        echo ""
        echo "Starts from a 'step000.jpg' file in the current directory."
        exit 1
}

[[ -n "$3" ]] && { usage ; exit 1 ; }
steps=${1:-$defaultsteps}
quality=${2:-$defaultquality}    
dotcolor="white" # change this if the top of the image is too clear

echo "Running with $steps steps with quality $quality"

for step in $(seq $steps)
do 
    echo "Step $step of $steps"
    src=$(printf step%03d $(( $step - 1 )) ) 
    dst=$(printf step%03d $(( $step )) )
    dif=$(printf diff%03d $(( $step )) )
    # dot coordinates
    let cxc="2 * $dotradius * $step"
    let cxr="$cxc + $dotradius"
    let cyc="$dotradius * 2"
    let cyr="$dotsradius * 2"

    $convert $src.jpg -fill white -draw "circle $cxc,$cyc,$cxr,$cyr" $dst.png
    $convert $dst.png -quality $quality $dst.jpg
    rm $dst.png
    $compare $src.jpg $dst.jpg $dif.jpg
done

Pour le moment je ne montrerai pas les résultats, je préfère vous laisser expérimenter avec vos propres photos. Avec suffisamment de commentaires, je vais ajouter un échantillon.