Soit une image de 256x256, donc de 65536 pixels. On peut donc s'en servir pour représenter des fichiers de minimum 196k (trois octets par pixels). pour les fichiers plus petits, on réduit l'image, pour les plus grands, on place plusieurs octets par pixels (on ne fait que les additionner bêtement, pas besoin de plus).
Les composantes R, G et B de chaque pixel sont les valeurs des octets qu'ils représentent. On sauve l'image. On a donc une image gribouillie par fichier, et on ne sait rien en faire.
Maintenant, pour chaque image, on prend les images des autres fichiers, et on fait leur moyenne, puis la différence avec l'image du fichier. On obtiens donc ... une image toute noire pour un fichier concordant !
Si le moindre octet, ou groupe d'octets ne correspond pas, de jolis et brillants pixels de couleurs vont apparaître sur l'image.
Avec les optimisations du compilateur, on peut avoir un léger bruit sur les images, bruit qu'on peut laisser passer. Si jamais une ligne de code, comme montrée dans le commentaire plus haut, est modifiée, ce ne sera pas quelques octets de changés, mais une quarantaine.
Au lieu d'avoir quelques (ou plus) pixels différents éparpillés sur l'image, on aura une "tache" plus claire. La quantité de pixels ne fera donc pas la différence (une image peut être bruitée), mais plutôt leur disposition. Si une zone de pixels contigus sont clairs, c'est qu'il y a un problème.
On applique donc un petit flou, puis quelques autres opérations, et enfin un ajustement du constraste, et on peut obtenir de belles images avec des taches quand ça ne va pas, ou toutes noires quand ça va.
Je m'en vais tester tout ça, pour vérifier mes dires. (et ça, ce sera un bon petit logiciel libre qui va pouvoir servir à tout le monde, j'aurai au moins créé un comparateur rapide de fichiers binaires :P ).
[^] # Re: Magie !
Posté par steckdenis . En réponse au journal Aider au développement d'un nouveau gestionnaire de paquets. Évalué à 2.
Soit une image de 256x256, donc de 65536 pixels. On peut donc s'en servir pour représenter des fichiers de minimum 196k (trois octets par pixels). pour les fichiers plus petits, on réduit l'image, pour les plus grands, on place plusieurs octets par pixels (on ne fait que les additionner bêtement, pas besoin de plus).
Les composantes R, G et B de chaque pixel sont les valeurs des octets qu'ils représentent. On sauve l'image. On a donc une image gribouillie par fichier, et on ne sait rien en faire.
Maintenant, pour chaque image, on prend les images des autres fichiers, et on fait leur moyenne, puis la différence avec l'image du fichier. On obtiens donc ... une image toute noire pour un fichier concordant !
Si le moindre octet, ou groupe d'octets ne correspond pas, de jolis et brillants pixels de couleurs vont apparaître sur l'image.
Avec les optimisations du compilateur, on peut avoir un léger bruit sur les images, bruit qu'on peut laisser passer. Si jamais une ligne de code, comme montrée dans le commentaire plus haut, est modifiée, ce ne sera pas quelques octets de changés, mais une quarantaine.
Au lieu d'avoir quelques (ou plus) pixels différents éparpillés sur l'image, on aura une "tache" plus claire. La quantité de pixels ne fera donc pas la différence (une image peut être bruitée), mais plutôt leur disposition. Si une zone de pixels contigus sont clairs, c'est qu'il y a un problème.
On applique donc un petit flou, puis quelques autres opérations, et enfin un ajustement du constraste, et on peut obtenir de belles images avec des taches quand ça ne va pas, ou toutes noires quand ça va.
Je m'en vais tester tout ça, pour vérifier mes dires. (et ça, ce sera un bon petit logiciel libre qui va pouvoir servir à tout le monde, j'aurai au moins créé un comparateur rapide de fichiers binaires :P ).