Version imprimable
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
Comment dois-je déclarer pixels pour qu'il pointe sur la plage mémoire ?Code:Rgb pixels [w] [h];
Merci ! :)
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).
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
Je connais évidemment la petite formule simple, c'est d'ailleurs comme cela qu'un accès à tab [x][y] est compilé.Citation:
If you are accessing 32-bpp image data, cast the returned pointer to QRgb*
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 :)
Bonjour,
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).Citation:
Envoyé par PapaJaac
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.Citation:
Envoyé par PapaJaac
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.Citation:
Envoyé par PapaJaac
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.Citation:
Envoyé par PapaJaac
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.
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 ?
----------
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 ?Citation:
Tes données sont contigues, si tu veux les transformer en tab2D il faut faire au mieux un traitement.
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 ?
Tu as deux solutions pour y arriver:Citation:
Envoyé par PapaJaac
Celle que je préconise dans le cas présent d'allouer directement l'espace pour 200 éléments avec un new type tab[200] qui va t'assurer que l'ensemble des éléments seront contigus en mémoire.
L'autre est de travailler en deux temps :
effectuer l'allocation dynamique d'un pointeur de pointeur pouvant contenir 10 pointeurs puis, pour chaque pointeur, allouer dynamiquement la mémoire pour 20 éléments, sous une forme proche de
Outre tous les problèmes susceptibles de survenir, le fait est que tu n'as alors aucune garantie de contiguïté entre les différentes lignes, ce qui pose rapidement des problème de cache miss lorsqu'il s'agit d'accéder aux différents éléments ;)Code:
2
3
4
5
Merci.
Bon ces tableaux nD (n > 1) c'est vraiment la misère, je laisse tomber ;)
Bonjour,
En fait, on évite bien des déconvenues avec les matrices et tableaux quand on renonce à tab[i][j] pour tab(i,j)...
Sans ça, on a une piètre liberté sur le mode de stockage et on présume que l'entité ligne ou colonne existe...
J'ai trouvé un passage dans LE bouquin de Stroustrup où il déconseille l'usage des tableaux à plus d'une dimension pour autre chose que des applis de très bas niveau.
M. Stroustrup est une référence ; j'écouterai donc désormais M. Stroustrup. :)