Discussion :

[PapaJaac]

Bonjour !

J'ai une classe perso Rgb dont la taille une fois instanciée est de 4 octets.

Une fonction de mon IDE (c'est QImage::bits () de Qt mais peu importe) me renvoie un uchar*.

Je souhaite gérer cette plage mémoire comme un tableau à deux dimensions (w, h sont connues) de structures Rgb.

Si je devais simplement créer ce tableau de pixels ce serait simplement

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Rgb pixels [w] [h];

Comment dois-je déclarer pixels pour qu'il pointe sur la plage mémoire ?

Merci !

[koala01]

Salut,

Ce qu'il y a de bien, avec les images, c'est que tu as la garantie qu'il s'agit d'une matrice pleine (comprend : que tu auras d'office toujours le même nombre de cellules dans toutes les lignes).

Plutôt que de travailler avec un tableau deux dimensions (déjà travailler avec des pointeurs, ca reste "moyen moyen" ) représenté par un pointeur de pointeur (hé oui, pour avoir les deux dimensions ca devient une pointeur de pointeurs ), tu peux (et c'est ce que Qt a décidé de faire, de toutes évidence) te baser sur un tableau "normal" de (Longueur * Largeur) éléments.

Tu remarqueras que cela revient strictement au même en terme de nombre d'éléments

La seule différence, c'est que pour accéder à un des éléments, il faut alors utiliser une petite formule simple qui est ( (numéro de la ligne * nombre d'éléments par ligne) + numéro de la colone).

[PapaJaac]

Qt renvoie un uchar* mais pourrait aussi bien retourner un void*, étant donné que la disposition des données d'une image dépend de son format.
En l'occurrence je travaille sur des images au format ARGB32, chaque pixel est codé sur 4 octets non signés. Transparence, puis composantes rouge vert et bleu.
Le uchar* n'étant pas adapté, le cast est obligatoire, et d'ailleurs recommandé par la doc

If you are accessing 32-bpp image data, cast the returned pointer to QRgb*

Je connais évidemment la petite formule simple, c'est d'ailleurs comme cela qu'un accès à tab [x][y] est compilé.
Je sais lire et modifier un pixel en utilisant cette formule. Mais j'aimerais bien utiliser un tableau 2D. Pour une question de lisibilité du code : par principe je veux que ce soit moi qui décide, et que le compilo se débrouille derrière : je ne suis pas à son service, c'est lui qui est au mien

[Bousk]

Bonjour,

Qt renvoie un uchar* mais pourrait aussi bien retourner un void*, étant donné que la disposition des données d'une image dépend de son format.

A priori non, une image, une fois chargée en mémoire, est toujours représentée par une série de RGBA (ou ARGB).

En l'occurrence je travaille sur des images au format ARGB32, chaque pixel est codé sur 4 octets non signés. Transparence, puis composantes rouge vert et bleu.
Le uchar* n'étant pas adapté, le cast est obligatoire, et d'ailleurs recommandé par la doc

En quoi le uchar* n'est pas adapté ? C'est typiquement le type qui peut être utilisé par OpenGL par exemple. La suite des ARGB est contigue, le 5° élément correspondant au canal Alpha du 2° pixel.

Je connais évidemment la petite formule simple, c'est d'ailleurs comme cela qu'un accès à tab [x][y] est compilé.

Je suis sceptique quant à la façon d'accéder une fois compilée. Un tableau 2D n'a aucune garantie sur la contiguité des données (peut-être dans le cas d'un tableau statique, mais en allocation dynamique je ne pense pas), une simple formule arithmétique est alors impossible.

Je sais lire et modifier un pixel en utilisant cette formule. Mais j'aimerais bien utiliser un tableau 2D. Pour une question de lisibilité du code : par principe je veux que ce soit moi qui décide, et que le compilo se débrouille derrière : je ne suis pas à son service, c'est lui qui est au mien

Tes données sont contigues, si tu veux les transformer en tab2D il faut faire au mieux un traitement. Au pire c'est impossible directement (sans réallocation etc). Et dépend de la représentation lignes-colonnes ou colonnes-lignes.
Il serait au final bien plus simple d'utiliser un tab1D et fournir une méthode d'extraction d'un pixel (x,y) pour la lisibilité du code.

Tu peux essayer un naïf reinterpret_cast<QRGB**> mais sans conviction de ma part.

[PapaJaac]

D'accord, n'importe quelle zone mémoire peut être considérée comme un uchar*, et les données y figurant être traitées comme des assemblages d'octets, mais admets que ce n'est pas convivial !
Les entités qui ont un sens dans mon cas sont des groupes consécutifs de 4 octets, l'ensemble étant garanti contigu. Chacun des octets a lui aussi une signification bien précise. Une entité est représentée par la classe Rgb (appelez-la Pixel32 si vous voulez) qui comporte un certain nombre de membres permettant des calculs sur ce pixel. C'est le pixel qui m'intéresse, pas les uchar qui le composent. Pourquoi irais-je m'embêter avec ?
----------

Tes données sont contigues, si tu veux les transformer en tab2D il faut faire au mieux un traitement.

Mais pourquoi donc ?? Le rangement en mémoire d'un tableau à 2 (et plus) dimensions est parfaitement défini en C++. En 2D c'est d'abord la première ligne, puis la seconde, etc... Le 1er octet de la 2è ligne suit le dernier de la première. Quel traitement voudrais-tu faire ?

[PapaJaac]

En relisant vos réponses j'ai l'impression que quelque chose m'échappe dans l'affaire.

Pour en avoir le cœur net, je vais poser la question autrement :

Je veux créer dynamiquement (avec new) un tableau d'entier appelé tabInt, de 10 lignes et 20 colonnes. Juste le créer, je le remplirai après, plus tard.

Comment rédiger la ligne ?