VK a un groupe avec la description suivante:

La même photo est enregistrée manuellement tous les jours sur un ordinateur et est à nouveau téléchargée, perdant progressivement de la qualité.

À gauche, l'image originale téléchargée le 7 juin 2012, à droite, c'est ce qu'elle est maintenant.

Cette différence est très suspecte. Essayons de comprendre ce qui s'est passé pendant ces 7 années. Pour faire connaissance il y a un article sur Medusa à propos de ce groupe, mais seul le côté technique nous intéressera.

Pourquoi et à quel stade JPEG compresse-t-il avec les pertes

Prenons un schéma d'encodage et de décodage JPEG très simplifié. Seules les opérations illustrant les principes de base de l'algorithme JPEG sont affichées.

Donc, 4 opérations:

• DCT est une transformée en cosinus discrète.
• Quantification - arrondir chaque valeur au multiple le plus proche du pas de quantification: y = [x / h] * h, où h est le pas.
• IDCT est la transformée en cosinus discrète inverse.
• L'arrondi est un arrondi normal. Cette étape n'a pas pu être représentée dans le diagramme, car elle est évidente. Mais alors son importance sera démontrée.

La couleur verte indique les opérations qui enregistrent toutes les informations (sans tenir compte des pertes lors de l'utilisation de nombres à virgule flottante), les roses - perdre. Autrement dit, les pertes et les artefacts n'apparaissent pas à cause de la transformée en cosinus, mais à cause d'une simple quantification. L'article ne considérera pas une étape importante - le codage Huffman, car il est effectué sans perte.

Considérez ces étapes plus en détail.

DCT

Puisqu'il existe plusieurs variantes de DCT, juste au cas où, je précise que JPEG utilise un deuxième type de DCT avec normalisation. Lors de l'encodage, chaque image est divisée en carrés 8x8 (pour chaque canal). Chacun de ces carrés peut être représenté comme un vecteur à 64 dimensions. La transformation cosinus consiste à trouver les coordonnées de ce vecteur dans une autre base orthonormée. Il est difficile de visualiser l'espace à 64 dimensions, donc des analogies à 2 dimensions seront données ci-dessous. Vous pouvez imaginer que l'image est divisée en blocs de 2x1. Dans les graphiques qui seront présentés ci-dessous, l'axe x correspond aux valeurs du premier pixel du bloc, l'axe y au second.

En poursuivant l'analogie avec un exemple spécifique, supposons que les valeurs de deux pixels de l'image d'origine soient 3 et 4. Dessinez le vecteur (3, 4) dans la base d'origine, comme illustré dans la figure ci-dessous. La base d'origine est marquée en bleu. Les coordonnées du vecteur dans une nouvelle base sont (4.8, 1.4).

Dans l'exemple considéré, une nouvelle base a été choisie au hasard. DCT offre une base fixe à 64 dimensions très spécifique. La justification de la raison pour laquelle il est utilisé en JPEG est très intéressante et a été décrite par moi dans un autre article . Nous n'aborderons que l'essence. En général, les valeurs de tous les pixels sont équivalentes. Mais si nous les convertissons en utilisant DCT, puis à partir des 64 coordonnées résultantes dans une nouvelle base (appelée les coefficients de transformation DCT), nous pouvons en toute sécurité mettre à zéro ou arrondir approximativement certains d'entre eux, avec des pertes minimales. Ceci est possible grâce aux fonctionnalités des images compressibles.

Quantification

Les valeurs fractionnaires ne peuvent pas être enregistrées dans un fichier. Par conséquent, selon l'étape de quantification, les valeurs 4.8, 1.4 seront enregistrées comme suit:

• à l'étape 1 (l'option la plus douce): 5 et 1,
• à l'étape 2: 4 et 2,
• à l'étape 3: 6 et 0.

Habituellement, l'étape est choisie différente pour chaque valeur. Un fichier JPEG possède au moins un tableau, appelé table de quantification, qui stocke 64 étapes de quantification. Ce tableau dépend de la qualité de compression définie dans n'importe quel éditeur graphique.

IDCT

Identique à DCT, mais avec une base transposée. Mathématiquement, x = IDCT (DCT (x)), donc s'il n'y avait pas de quantification, il serait possible de récupérer sans perte. Mais il n'y aurait pas de compression. En raison de l'utilisation de la quantification, le vecteur d'origine ne peut pas toujours être calculé avec précision. La figure suivante montre 2 exemples avec une récupération précise et inexacte. La grille inclinée correspond à une nouvelle base, la ligne droite à celle d'origine.

La question évidente se pose: une séquence de transcodage peut-elle conduire à un vecteur très différent de l'original? Peut-être.

Il serait intéressant de trier tous les vecteurs entiers et de voir à quoi leur transcodage va conduire. Pour réduire le bruit de l'information, nous supprimons la grille de la base initiale et nous connectons directement les vecteurs originaux et reconstruits (sans étape intermédiaire) par segments. Considérons d'abord un pas de quantification égal à 1 pour toutes les coordonnées. La nouvelle base dans la figure suivante est tournée de 45 degrés et pour cela, nous avons 17,1% de récupérations inexactes. Les couleurs des segments ne veulent rien dire, mais elles seront utiles pour éviter leur fusion visuelle.

Cette base est de 10,3 degrés avec 7,4% de récupérations inexactes:

Près de:

Et celui-ci est à 10,4 de 6,4%:

19 degrés à partir de 12,5%:

Mais si vous définissez un pas de quantification supérieur à 1, les vecteurs reconstruits commencent à se concentrer clairement à proximité des nœuds de la grille. C'est l'étape 5:

C'est 2:

Si vous recodez l'image plusieurs fois, mais avec la même hauteur, il ne se passera presque rien par rapport à un seul recodage. Les valeurs semblent "bloquées" dans les nœuds de la grille et ne peuvent plus "sauter" de là vers d'autres nœuds. Si l'étape est différente, le vecteur «sautera» d'un nœud de grille à un autre. Cela peut l'emmener partout. La figure suivante montre le résultat de 4 transcodes aux étapes 1, 2, 3, 4. Vous pouvez voir une grande grille à l'étape 12. Cette valeur est le plus petit multiple commun de 1, 2, 3, 4.

Et à ce sujet - avec les étapes de 1 à 7. La visualisation n'est montrée que pour une partie des vecteurs originaux afin d'améliorer la visualisation.

Arrondi

Pourquoi arrondir les valeurs après IDCT? Après tout, si vous vous débarrassez de cette étape, l'image restaurée sera représentée par des valeurs fractionnaires et nous ne perdrons rien lors du recodage. D'un point de vue mathématique, nous passerons simplement d'une base à l'autre sans perte. Il faut mentionner ici la conversion des espaces colorimétriques. Bien que JPEG ne régule pas l'espace colorimétrique et vous permette d'enregistrer directement dans la source RVB, mais dans la grande majorité des cas, une conversion préliminaire en YCbCr est utilisée. Caractéristiques oculaires et tout ça. Et une telle conversion entraîne également des pertes.

Supposons que nous obtenions un fichier JPEG compressé avec une qualité maximale, c'est-à-dire avec un pas de quantification de 1 pour tous les coefficients. Nous ne savons pas quel codec a été utilisé, mais généralement les codecs effectuent l'arrondi après la conversion RGB -> YCbCr. Puisque la qualité est maximale, après IDCT, nous obtenons des valeurs fractionnaires, mais plutôt proches de celles d'origine dans l'espace YCbCr. Si nous arrondissons, la plupart d'entre eux seront restaurés exactement.

Mais si ce n'est pas rond, en raison de ces petites différences, la conversion YCbCr -> RGB peut encore les éloigner des valeurs d'origine. Avec le transcodage ultérieur, l'écart augmentera de plus en plus. Pour visualiser en quelque sorte ce processus, nous utilisons la méthode du composant principal pour projeter des vecteurs à 64 dimensions sur un plan. Ensuite, pour 1000 transcodes, nous obtenons approximativement la séquence de modifications suivante:

Les valeurs absolues des axes ici n'ont pas beaucoup de sens, mais la signification relative des distorsions peut être utilisée.

Exemples de transcodage multiples

Chat source:

Après une reconservation de qualité 50:

Après un nombre ultérieur de transcodes de même qualité, l'image ne change pas. Maintenant, nous allons progressivement réduire la qualité de 90 à 50 en 1:

La même chose s'est produite dans le tableau ci-dessous:

Après une reconservation de qualité 20:

De 90 à 20 en toute transparence:

Maintenant 1000 fois avec une qualité aléatoire de 80 à 90:

10000 fois:

Analyse des images du groupe VK

Commençons l'analyse de plus de 2000 images du groupe VK. Tout d'abord, vérifiez l'écart absolu moyen par rapport au tout premier. L'axe des x est le numéro de l'image (ou le jour), l'axe des y est l'écart.

Passons au graphique différentiel montrant l'écart absolu moyen des images voisines.

De petites fluctuations au début sont normales. Jusqu'au 232e, tout se passe bien, les photos sont totalement identiques. Et le 233e diffère soudainement en moyenne de 1,23 pour chaque pixel (sur une échelle de 0 à 255). C’est beaucoup. Peut-être que les tables de quantification viennent de changer. Vérifiez-le. Et en même temps, c'est comparable à la taille des fichiers reçus.

Oui, les tableaux ont changé. Mais pas avant les 700. Puis, peut-être, un transcodage caché intermédiaire de faible qualité s'est produit. Essayons de ré-encoder le 232e deux fois. Pour la première fois, nous allons passer par différents niveaux de qualité, et pour la seconde nous utilisons la même table de quantification que pour tous du 1er au 700s. Notre objectif est d'obtenir une image aussi similaire que possible à la 233e. Dans la figure suivante, le long de l'axe x est la qualité du transcodage intermédiaire, le long de y est l'écart absolu moyen par rapport au 233e.

Bien qu'il y ait un échec sur le graphique avec une qualité de 75%, approximativement égale à 1, mais toujours loin du zéro souhaité. L'ajout de la 2e étape intermédiaire et la modification des paramètres de sous-échantillonnage n'ont pas amélioré la situation.

Avec le reste des images, tout est à peu près le même, plus le changement dans les tableaux de quantification est également superposé. Autrement dit, à un moment donné, l'image change radicalement, puis elle se stabilise en quelques jours, mais seulement jusqu'à ce qu'une nouvelle vague se produise. Il y a peut-être un changement dans l'image elle-même sur les serveurs. Je ne peux pas exclure complètement l'implication de l'administrateur du groupe.

Malheureusement, je n'ai pas découvert ce qui s'est réellement passé avec l'image. Au moins maintenant, je suis sûr que ce n'était pas seulement une reconservation. Mais, plus important encore, il est devenu préférable de représenter les processus en cours pendant le codage et le décodage. J'espère que vous aussi.

Archive avec photos , pour une recherche indépendante.