Bonjour Cette partie est normalement invisible : Tube CRT 4/3 avec sur balayage En secam le bruit coloré correspond au bruit FM quand il n'y a pas de sous porteuse. Dans ce cas la moindre "diaphonie",due par exemple a un câblage folklorique,va le réduire artificiellement. PS Il est facile de lever le doute en shuntant entrée et sortie des lignes a retard avec une résistance de ,disons, 10 Kohms
le discret 11 utilise donc 2 types de décalage de lignes vers la droite : 902 et 1804 nanosecondes,
ces décalages en nanosecondes correspondent à combien de pixels sur l'image ?
supposons que j'ai une image de 720x576 pixels ( type DVD ) et que je veuille appliquer un décalage de 902 nanosecondes sur la ligne 152 de cette image, combien de pixels vont se retrouver "vierges" sur cette ligne 152 ? ( en sachant que mon image fera toujours 720x576 après cryptage, les pixels qui débordent au delà de la position 720 ne seront pas affichés )
un raisonnement par pourcentage m’intéresserait aussi,
je cherche en fait à créer une petite application qui modifie une image png pour recréer une sorte de cryptage discret11, je raisonne donc en pixels plutôt qu'en nanosecondes, mais il me faut la correspondance en pixels ou en pourcentage, j'imagine qu'au moins 5% des pixels d'une ligne à cause du décalage sont "grignotés" ( transformés en blanc ou en noir )
Une ligne de balayage d'un système 625/25 dure 64 us sur lesquels environ 12 us sont réservés à l'impulsion de synchro et à ses paliers avant et arrière. Il reste donc approximativement 50 us dédiés à l'affichage. En admettant une résolution équivalente à 720 pixels, le décalage de 902 ns correspond approximativement à 0.9*720/50 = 13 pixels.
mon algorithme consiste à décaler vers la droite les pixels de chaque ligne de l'image, à chaque ligne je fais un tirage pseudo aléatoire ( sur 3 nombres ),
si je trouve 1 : je ne fais aucun décalage si je trouve 2 : je fais un décalage de 1.8% ( par rapport à la largeur totale de l'image ) si je trouve 3 : je fais un décalage de 3.6% ( toujours par rapport à la largeur de l'image )
raisonner en pourcentage ( plutôt qu'en nanosecondes ) me permets de travailler sur n'importe quelle résolution d'image,
et si je sauvegarde les décalages appliqués à chaque ligne dans un fichier texte je pourrai alors en théorie décrypter une image qui avait été cryptée avec les mêmes décalages ( en réutilisant ce fichier texte pour faire le chemin inverse, décalage à gauche avec les valeurs du fichier texte comme référence ),
un mode automatique de décryptage peut être aussi envisagé en analysant le pourcentage de pixels noirs en début de ligne pour en déduire le pourcentage de décalage qui a été appliqué, mais ça sera moins fiable si du noir se trouve aussi juste après le début du décalage,
pour l'instant mon utilitaire fonctionne qu'en ligne de commande ( on passe en option le chemin du fichier image à crypter ) et ne fait que crypter une image, c'est un utilitaire en java, la création d'une interface graphique sera la prochaine étape,
et l'étape ultime sera de créer une option permettant de crypter cette fois un fichier vidéo, car si je peux crypter une image alors je peux aussi appliquer la même chose à une vidéo vu qu'une vidéo n'est qu'une suite de frames, mais ça va demander un peu plus de boulot,
bien sûr si mon utilitaire intéresse quelqu'un je posterai le lien