Discussion :

[nasboy3d]

Salut amis developpeurs....
Je voudrais avoir votre point de vue sur quelque chose....

J'utilise la fonction QT suivante qui retourne un pointeur sur une liste de pixels
d'image : uchar * QImage::bits ().
Comme vous pouvez le contaster la classe QImage est associé à une seule image......Ce que je voudrais c'est par exemple si j'appelle la fonction sur 2 images: uchar * pointeur1 = MonImage1.bits();
uchar * pointeur2 = MonImage2.bits();
pouvoir rapidement recupérer un seul pointeur fusion qui regroupe pointeur1 et pointeur 2 séquentiellement en mémoire(sans copie d'une partie de la mémoire vers une autre).
Je sais que moralement c'est impossible mais qui sait..... Etonnez-moi!!!!!!

Pour ceux qui doutent ce que je désire n'a rien à voir avec QT car ce dernier sert juste à illustrer........
Merci

[Aladore]

Non tu ne peux pas, mais ce que tu peux faire, c'est un tableau de pointeur sur uchar qui auraient pour élément le pointeur1 et le pointeur2.
Est-ce que ça correspondrait à ce que tu souhaites faire ?

[koala01]

Salut

Non tu ne peux pas, mais ce que tu peux faire, c'est un tableau de pointeur sur uchar qui auraient pour élément le pointeur1 et le pointeur2.
Est-ce que ça correspondrait à ce que tu souhaites faire ?

Et encore, tu aurais alors deux pointeurs de pointeurs contigu pointant sur deux adresses mémoire qui ne sont pas forcément elle-même contigües.

Tu ne pourrais donc pas avoir la certitude de, à partir du dernier pixel de la première image que l'incrémentation du pointeur sur ce pixel t'amène réellement au premier pixel de la seconde

Donc la réponse est: non, tu ne peux pas.

Soit tu dois forcer la copie des deux tableaux de pixels dans un troisième tableau dont la taille est suffisante, soit tu dois faire en sorte de créer un seul tableau de taille suffisante pour représenter l'ensemble des pixels des deux images et forcer le chargement de la première image à utiliser l'adresse du premier élément de ce tableau et le chargement de la deuxième image à utiliser l'adresse du pixel qui suit le dernier pixel de la première image.

Mais, a priori, la classe QImage s'occupera elle-même de la gestion du tableau de pixels nécessaire à sa représentation en mémoire, et tu ne peux donc pas appliquer cette deuxième solution

[Aladore]

Oui nous sommes bien d'accord, mais il pourrait faire une double boucle pour traiter l'ensemble des éléments des deux pointeurs non ?

[koala01]

Le fait est qu'il te faut généralement, déjà, une double boucle pour gérer l'ensemble des pixels d'une seule image, sous la forme de

Code :

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

1
2
3
4
for( l=0;l<img.heigth();++l
    for(c=0;c<img.with();++c)
       // utilisation de 
        ptr[l*img.with()+c]

Tu te retrouverais donc avec non pas une double mais une triple boucle et avec, en plus, une indirection supplémentaire

Avoue que cela commence tout doucement à faire beaucoup

[Jean-Marc.Bourguet]

Tu peux te faire une classe qui se comportera globalement comme tu le désires. Le plus gros problème sera que ce ne sera pas un pointeur et donc tu ne pourras pas la passer à des fonctions qui en attendent un.

Je doute que ce soit l'approche à utiliser dans la plupart des cas, mais je peux facilement imaginer des contextes où c'est une solution à envisager sérieusement.

Avec beaucoup de trous:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
template <typename T>
class MergedRegion
{
public:
   MergedRegion(T* p1, size_t s1, T* p2, size_t s2);
 
   T& operator*() { return operator[](current); }
   T& operator[](size_t idx) { return (idx < s1) ? p1[idx] : p2[idx-s1]; }
   MergedRegion& operator++() {++current; return *this}
};

[Invité]

Bonjour,
En fait, on ne sait pas ce que Nasboy3D veut faire avec ses images, il me semble que c'est tout de même ça qui est important.
On peut par exemple imaginer qu'il y deux images, et que le but est de créer une image qui résulte de la combinaison logique au niveau des pixels de ces deux images.
La notion de séquentiel n'a en général pas de sens pour deux objets. Lorsqu'il s'agit d'image, il y non plus pas beaucoup de chances que le premier pixel de la ligne L+1 suive le dernier pixel de la ligne L. C'est la raison pour laquelle les classes d'image ont une fonction ScanLine() qui renvoie un pointeur sur le premier pixel de la ligne. (ceci est vrai pour toutes les classes d'image que je connais - et pour certains formats la décomposition est encore plus compliquée : pavés, bandes etc.)
Cependant, d'après l'écriture "uchar *QImage::bits()", on pourrait penser que le tableau de bits est effectivement caractérisé par un pointeur sur un unsigned char. C'est pas beaucoup dans un contexte d'image moderne où on trouve plus souvent des pixels sur 16 ou 32 bits. Donc, de quoi s'agit-il?

[gbdivers]

Bonjour

J'ai un peu de mal a comprendre aussi le but de la chose...

En tout cas, si tu ne gère pas toi même la mémoire, aucune chance que la mémoire de tes 2 images soient contiguës. Il faudra forcement passer par une copie à un moment donné.

Une solution est de créer toi même un bloc mémoire de taille suffisante et de créer tes images en donnant le pointeur vers cette mémoire (si tu as la possibilité de créer les images) :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
// dimension de tes images
const int width_image_1 = 100;
const int height_image_1 = 200;
const int width_image_2 = 300;
const int height_image_2 = 400; 
 
// nombre octets par image (au format Format_ARGB32 = 4 octets par pixel)
const int size_image_1 = width_image_1 * height_image_1 * 4;
const int size_image_2 = width_image_2 * height_image_2 * 4;
 
// taille du bloc mémoire nécessaire
const int size_bloc = size_image_1 + size_image_2;
 
// création bloc mémoire
QVector< uchar > mem_bloc(size_bloc);
 
// pointeurs vers les blocs mémoire
uchar* ptr_image_1 = mem_bloc.data();
uchar* ptr_image_2 = ptr_image_1 + size_image_1;
 
// création des images
QImage image_1 (ptr_image_1, width_image_1, height_image_1, QImage::Format_ARGB32);
QImage image_2 (ptr_image_2, width_image_2, height_image_2, QImage::Format_ARGB32);

J'ai volontairement très détaillé pour que la démarche soit claire.

En cas de redimensionnement de tes images, il faut tout refaire (sauf si tu prends volontairement un bloc mémoire beaucoup plus grand que nécessaire)

En espérant que ça puisse t'aider

[nasboy3d]

Merci pour tous vos réponses et désolé pour le retard......
En passant j'adore l'entraide qu'il y a sur ce forum.....Merci encore
En fait par rapport à:

En fait, on ne sait pas ce que Nasboy3D veut faire avec ses images, il me semble que c'est tout de même ça qui est important.
On peut par exemple imaginer qu'il y deux images, et que le but est de créer une image qui résulte de la combinaison logique au niveau des pixels de ces deux images.
La notion de séquentiel n'a en général pas de sens pour deux objets.

Non ce n'est pas une combinaison logique que je veux faire.
Je m'explique : Je veux regrouper plusieurs images séquentiellement en mémoire puis passer un seul pointeur et une (taille*sizeof(uchar)) à mon GPU pour du texturage sur plusieurs objets. Après bien sur, je lui spécifierai les OFFSET_TEXURE pour chaque objet. Voilà J'espère que c'est assez clair.

En tout cas, si tu ne gère pas toi même la mémoire, aucune chance que la mémoire de tes 2 images soient contiguës. Il faudra forcement passer par une copie à un moment donné.

Une solution est de créer toi même un bloc mémoire de taille suffisante et de créer tes images en donnant le pointeur vers cette mémoire (si tu as la possibilité de créer les images) :

Je pense que c'est la seule solution.....mais je n'ai pas du tout envie de gérer
la création d'images moi-meme.....
Pour info je suis entré de créer un logiciel de modélisation(animation) 3D basé sur les NURBS et qui utilise beaucoup l'accélération matérielle : C'est un projet que j'ai commencé il y a à peu près un an et là je devrais avoir les premiers résultats. C'est un logiciel qui n'a rien à voir avec Rhino (que je trouve très bien, complet mais trop technique...)
Je reviendrai sur ce meme forum(section 3D) dès que j'ai les premiers résultats.