Discussion :

[Luke spywoker]

Salut les pythons,
Je bosse sur un programme: j'analyse des bytes et j'aimerai avoir votre opinion sur la facon de nommer un byte d'un groupe de 2 bytes complémentaires.
Si je vous dit ceci est le Low Byte et ceci est le High Byte que comprenez vous ?
Merci pour vos réponses et si vous avez de meilleurs idées de dénomination d'un Byte de début et de fin sur deux Bytes merci de postez.
PS: désolez pour la question non technique mais si il n'y a que moi qui comprend mon programme c'est pas l'idéal.

[VinsS]

Salut les pythons,

Si je vous dit ceci est le Low Byte et ceci est le High Byte que comprenez vous ?

Je comprends Low Byte = byte de poids faible, High Byte = byte de poids fort.


...
Qu'est-ce qu'on gagne ?

[tyrtamos]

Bonjour,

Pareil que VinsS, en ajoutant que la traduction de "byte" est "octet", ceci pour éviter les confusions avec "bit". Pour certains ordinateurs dont la mémoire est plutôt 16 bits ou plus, il faudrait plutôt utiliser "mot" qui est plus général. On aurait ainsi: "mot de poids faible" et "mot de poids fort". Mais pour les ordinateurs courants, "octet" est très bien.

Cette distinction, est particulièrement importante quand on parle du stockage des nombres dans les ordinateurs: http://fr.wikipedia.org/wiki/Endianness. Nos PC courants sont en "little-endian", c'est à dire que les octets de poids faible sont stockés dans la mémoire avant les octets de poids fort.

[wiztricks]

Je bosse sur un programme: j'analyse des bytes et j'aimerai avoir votre opinion sur la facon de nommer un byte d'un groupe de 2 bytes complémentaires.

Techniquement, c'est un "short" i.e. un "int" dans [0..65535] si non signé ou dans [-32767, +32767] si signé.

Si je vous dit ceci est le Low Byte et ceci est le High Byte que comprenez vous ?

Le short "s" peut être représenté par une séquence de 2 bytes "x", "y" pouvant avoir une valeur dans [0..255] i.e. (x, y) tel que s = x^255 + y
x sera le "high byte" et y sera le "low byte".

La dimension "endianess" intervient pour rendre compte de "l'ordre" du stockage des bytes x, y en mémoire.
Plutôt que de lire un "short" et de calculer x, y à partir du quotient et du reste de la division par 255, on récupère x et y en fonction de leur position mémoire (u, v) telle que : x = short[u], y = short[v].
L'"endianness" définit les valeurs (u, v) comme étant (0, 1) ou (1, 0).

PS: désolez pour la question non technique mais si il n'y a que moi qui comprend mon programme c'est pas l'idéal.

Cela fait partie des les définitions de base connues et généralement maîtrisées les programmeurs. Il suffit de les respecter pour ne rien avoir à documenter.

- W

[dividee]

"low byte" et "high byte" sont compréhensibles, bien que je préfère "low-order byte" et "high-order byte". Ou en français "octet de poids faible" et "octet de poids fort".

... la traduction de "byte" est "octet", ceci pour éviter les confusions avec "bit".

Au sens strict, "octet" n'est pas la traduction de "byte". La sémantique est différente: l'octet est toujours composé de 8 bits (d'où son nom). Le byte est la plus petite unité adressable. Il se trouve que pour toutes les architectures modernes, les deux coïncident, mais des architectures avec des bytes de 7 ou 9 bits ont existé. "octet" est aussi utilisé en anglais, quand on veut insister sur le fait qu'on parle bien d'une quantité de 8 bits (par exemple, pour décrire le format d'un en-tête pour un protocole réseau). Pourquoi utilise-t-on plutôt "byte" en anglais et "octet" en français ? Je ne sais pas exactement, sans doute pour des raisons de prononciations...

[wiztricks]

Salut,

Si vous cherchez à trouver ce à quoi peuvent correspondre ces mots dans différents contexte, on n'est pas rendu.

Dans un forum Python, nous sommes dans le contexte d'un langage de programmation qui définit les "bytes" comme une séquence d'entiers dans range(256).

- W

[tyrtamos]

Bonjour dividee,

Au sens strict, "octet" n'est pas la traduction de "byte"

Au sens strict, oui. Mais ça conviendra dans 99% des cas, et c'est la traduction de google. En hardware, quand on doit considérer une mémoire de 12 bits, on parle plutôt d'un "mot de 12 bits" (http://fr.wikipedia.org/wiki/Mot_%28informatique%29). Et je préfère parler français quand je le peux (ce qui est loin d'être facile en informatique ).

[Luke spywoker]

Merci pour vos réponses,
apparement tous le monde a la bonne définition de ce que je voulais dire:

Qu'est-ce qu'on gagne ?

Dans le block obligatoire appelé Image Descriptor Block, du format d'image GIF, le premier byte sert de marqueur de ce block et a la valeur hexadécimale 2c le 2 ième et le 3 ième donne le coté gauche et le 4 ième et 5 ième donne la hauteur, en résumer le coin supérieur gauche que nous connaissont tous et sont toujours égaux a zéro puis suivent sur deux bytes la largeur et la hauteur de l'image avec le Low byte en premier.
C'est le cadeau offert a tous les gagnant de notre grand concours: Low Byte et High Byte que comprenez vous ?
Le gagnant de notre tirage au sort gagnera le droit d'effectuer une analyse byte a byte d'une image au format GIF...

[wiztricks]

Le gagnant de notre tirage au sort gagnera le droit d'effectuer une analyse byte a byte d'une image au format GIF...

L'en-tête des fichiers .GIF est par une structure similaire à un struct C en little-endian. Récupérer ces informations en les reconstruisant à partir d'un stream de bytes est plutôt pénible alors qu'on peut "mapper" directement cela via ctypes.

Enfin, c'est vous qui voyez.
- W

[Luke spywoker]

Je me sert partiellement des infos fournis par PIL pour effectuer des testes conditionnels pour confirmez les bytes que je décrypte tant que l'interprétation des bytes récupéré est égal aux infos fournis par PIL ca roule, sinon les fichiers GIF sont composé de blocks qui ont pour certains, un voire deux marqueurs de début et je me sert également d'un ouvrage relatant de la structure de données des différents formats de fichiers.

[Luke spywoker]

Un problème n'étant pas technique en devient un si je vous dit que j'arrive a détecté 4 blocks obligatoire:
-Le block d'en tête, avec la signature GIF8[7|9]a.
-Le Block Logical screen Descriptor qui contient la largeur et la hauteur de l'image, un byte drapeau, suivit du byte contenant la valeur du pixel de background (enfin son index plutôt) et le pixels ration.
-Le block contenant les triplet rgb et c'est celui-ci qui pose le pose le problème enoncé a la suite.
-Le Image Descriptor block qui contient son drapeaux de marquage de début suivit des coordonées afin d'obtenir les info de largeur et hauteur puis un byte de flag.

Bon le problème est que une fois ces bytes marqué par des PmwBalloon(), pas byte a byte pour le block contenant les triplet, mais dont le calcule des indexes de début et de fin s'avérant, ardu du a la forme de ce block qui peut être:
-partiellement sur une ligne.
-Sur une ligne jusqu'a sa fin.
-Sur plusieurs lignes.
-Et peut avoir des trous (si des gens ont écrit dans le fichiers GIF je suppose).
Le chargement dans le widget Text prend un temps conséquent et ce ne sont que quelques lignes sur des centaines compris dans le fichier GIF...

Et moi qui voulais marquer le rendu du fichier entier je ne sais le temps de chargement que ca prendrai...

Bon je sais que sans le code vous ne pouvez pas m'aider directement sur le code mais vous avez peut-être des idées théorique et je peut vous faire un pseudo-code représentant mon algorithme de marquage.

Merci pour vos réponses.

[wiztricks]

Salut,

Je ne vois pas trop le rapport de vos derniers messages avec le sujet de la discussion initiale. Je comprends que vous essayez de décoder des fichiers binaires .GIF, mais pas du tout où vous voulez en venir en parlant de PmwBalloon et de widget Text.

Désolé
- W

[PauseKawa]

Bonsoir,

Le chargement dans le widget Text prend un temps conséquent et ce ne sont que quelques lignes sur des centaines compris dans le fichier GIF...

Je dirais que notre jeune padawan s'exerce à la stéganographie. Le choix du format GIF compliquant la chose (Technique LSB. Le format JPEG est plus conciliant).
Mais bon... Il est possible que je me trompe...

@+

[PauseKawa]

Re,

Bon je sais que sans le code vous ne pouvez pas m'aider directement sur le code mais vous avez peut-être des idées théorique et je peut vous faire un pseudo-code représentant mon algorithme de marquage.

C'est en effet une bonne idée: L'optimisation de celui ci (et celui de décodage) est sans doute la solution à vos soucis de 'chargement'.
De plus si c'est de la stéganographie certains de nos membres s'y sont déjà exercés.

@+