Bonjour Jipété,
Envoyé par
Jipété
...
source, la page a été mise à jour en février 2022 et on n'a pas entendu parler d'une inversion de cette règle, qui concerne le BMP, d'accord, mais c'est ce "
cela n'a pas duré longtemps" qui m'a interpelé.
Je parlais des adresses lignes de Windows, c'est à dire de la représentation en mémoire et non des formats de stockage qui, à l'exception du bmp (et encore non compressé et sans table de couleurs), ne respectent en rien un quelconque ordre de balayage. Par exemple le jpeg avec ses transformées de Fourier (cos) par bloc, ses plans couleurs de résolutions différentes (4:2:2 par exemple), sa quantification de coefficients et son codage d'Huffman se trouve très loin de la forme à plat que la décompression reconstruit.
Ils avaient trouvé astucieux d'avoir en mémoire une représentation où les premières adresses lignes correspondaient au bas de l'image (meilleurs respect des quadrants mathématiques ?). Il fallait donc vérifier le sens (parce que ce n'était pas systématique certainement pour des questions de compatibilité) en comparant les adresses de deux lignes qui se suivaient.
En général, on s'en moque car les fonctions graphiques masquent le stockage. Mais si on veut travailler directement sur les données (en assembleur par exemple) cela devient important. Aujourd'hui les deux sens existent encore mais seul le top down semble réellement utilisé.
Sur Stack Overflow à la question de quelqu'un qui désespérait il y a eu la réponse suivante :
"The TBitmap::ScanLine property accounts for top-down and bottom-up. For a bottom-up bitmap, ScanLine[0] returns the last row, and ScanLine[Height-1] returns the first row, of the raw pixel data. For a top-down bitmap, ScanLine[0] returns the first row, and ScanLine[Height-1] returns the last row, of the raw pixel data."
Si je m'en rappelle bien c'est grâce au nombre de cheveux que j'y ai laissé .
Salut
Partager