Discussion :

[progfou]

J'ai un petit problème à vous soumettre...
J'ai un tableau à 3 dimensions. Ca correspond à une image, et pour chaque pixel (8 bits pour les 2 permieres dimensions) on associe un tableau de 150 éléments de 16 bits.

Evidemment, il est possible de faire un tableau à trois dimensions. Mais c'est probablement sous optimal !
Si l'image est grande, la consommation mémoire va vite devenir prohibitive...

Il doit donc certainement exister des solutions, sachant que le problème principal est de conserver un code rapide. Calculer la troisième dimension pour chaque pixel est couteuse, et donc on ne peut pas se permettre de ne conserver qu'un petit bout de l'image à chaque fois, car il y a des centaines de milliers de passages sur la même image.

Peut-on optimiser le stockage ?
Merci d'avance de vos réponses !

[Fabllot]

Bonjour !

C'est assez dur à voir comme ça (avec si peu d'info)...
Peut-être peux-tu "compresser des données", en remarquant que certains pixels possédent le même tableau ?
Détaille ce que tu dois faire, on pourra peut-être plus t'aider...

[Neitsa]

Bonjour,

on associe un tableau de 150 éléments de 16 bits.

Ouch... Cela fait effectivement beaucoup...

Calculer la troisième dimension pour chaque pixel est couteuse, et donc on ne peut pas se permettre de ne conserver qu'un petit bout de l'image à chaque fois

Je crains qu'a partir du moment où il n'est pas possible de générer rapidement le tableau de 150 mots par pixel de l'image, il faille conserver ces informations quelques part... Soit en mémoire (accès rapide mais problème de capacité), soit en stockage statique (e.g disque dur, ce qui entraîne immédiatement une dégradation des performances mais a l'avantage d'une capacité de stockage supérieure et par extension de décharger la mémoire).

Dans un premier temps tout dépend de la taille effective des images mais un simple calcul montrer qu'on sera vite limité au niveau mémoire...

Prenons une image 1024 * 768 :

Image : 1024 * 768 * 8 = 786432 octets
Tableau 3D = 1024 * 768 * 300 = 235929600 octets

soit environ 236 MiB... (on est aux environs du GiB pour une image deux fois plus grande...)

1) Calculer la taille nécessaire au tableau 3D et s'il n'occupe pas plus de la moitié voir les trois quarts de la mémoire système (il faut penser à laisser de la place au système et peut être aux autre processus), laisser le tableau en mémoire.

1-A) Dans le cas contraire (le tableau ne tient pas en mémoire), le décharger complètement sur disque et accepter une pénalité coûteuse en temps de traitement.

1-B) Décharger uniquement une partie du tableau sur disque, en laissant la 1/2 ou le 1/4 de mémoire système libre.

2) La partie du tableau qui ne pourra tenir en mémoire sera calculée "à la volée" (à l'exécution), si cela n'est pas plus pénalisant qu'un stockage disque (i.e écriture / lecture).
Il faudra tester ce qui est le plus rapide entre la génération à l'exécution et les I/O vers et depuis le disque.

Y'a-t-il une possibilité d'optimisation de la génération de ce tableau ?

Comme le suggère Fabllot, il y a peu être une possibilité de compression des données. La temps nécessaire à la décompression pour accéder aux données sera sûrement moindre que le temps nécessaires aux I/O. Le problème reste la compression (en mémoire) d'une telle quantité de donnée...

[droggo]

Qau,

J'ai un tableau à 3 dimensions. Ca correspond à une image, et pour chaque pixel (8 bits pour les 2 permieres dimensions) on associe un tableau de 150 éléments de 16 bits

En voilà des pixels détaillés !

Une optimisation probabablement faisable est de se poser la question

"A quoi servent réellement 150 * 16 bits pour un pixel ?"

car il y a des centaines de milliers de passages sur la même image

Ces pixels riches sont donc également très occupés par les visites. Sont-elles toutes justifiées ?

[souviron34]

moi j'avais fait un truc, je ne sais pas si cela peut t'être utile (c'était pour du 3D réel, donc des XYZ réels, avec de 1 à 30 valeurs réelles par point, donc là le gain était immense) :

pas de buffer 3d, mais

une ligne
une colonne
une "verticale"

pour chaque point un pointeur sur une structure contenant un pointeur sur la valeur X et la valeur Y et la valeur Z, et un tableau d'adresses pour les données.

Donc au lieu d'une matrice de N*M*L réels pour juste la position, 3 buffers N, M, L de réels et une matrice de N*M*L de triplets de pointeurs (un gain gigantesque de 1 To à 640 Mo).

[progfou]

Je ne comprends pas pourquoi, dans ta dernière solution, on occupe moins de place ?
Sinon, pour l'utilisation du disque dur, j'y pense également, en faisant des copies de blocs pour les traitements dans une taille mémoire donnée (1/4 par 1/4 d'image par exemple) dans les cas où la taille est trop grande.

Pour le moment, week-end, nous en reparlons lundi ?

[souviron34]

Je ne comprends pas pourquoi, dans ta dernière solution, on occupe moins de place ?

Donc au lieu d'une matrice de N*M*L réels pour juste la position, 3 buffers N, M, L de réels et une matrice de N*M*L de triplets de pointeurs

• Soit une matrice réelle A[100][100][100]
  
  soit 1.e06 réels.
  
  On a ainsi un cube X,Y,Z
  
  
• Si maintenant je fait :
  
  une matrice réele X[100], une Y[100], une Z[100]
  
  Puis une matrice entière B[100][100][100] (qui contiendra l'adresse des (X,Y,Z) correspondants à un point)
  
  j'ai donc 300 réels et 1.e06 entiers.
  

Exemple : en C, si les réels sont des doubles (sur une machine 32 bits ils font 64 bits), je gagne 1.e06 * 32 bits - (300 * 64 bits) = 3 997 600 octets = 4 Mo

Juste sur une matrice de 100*100*100.

Si c'est une matrice 10000*10000*100, tu vois le rapport (40 000 Mo)

....

[Graffito]

Bonjour,

Peut-on optimiser le stockage?

2 possibilités :

1) compression :
Est-ce que les données sont quelquonques ou y a-t-il par exemple des à-plats de couleur ou des séries de pixels (150 octets) idendiques.

2) stockage disque avec accès rapides suivant des "index" :
Pour définir les index, il faudrait connaitre les traitements afin de "buffériser" des parties d'images pour minimiser le nombre d'accès disques.

[ol9245]

si c'est des passages sucessifs sur la même image, il doit y avoir une grosse redondance = presque toutes les 150 valeurs sont les mêmes. Si c'est le cas, tu peux faire un dictionaire et compresser tes données. Tout dépend de tes besoins : reconstituer une à une chaque image ? ou avoir une info précise ?
OL

[souviron34]

absolument...

Pour pouvoir t'aider il faudrait vraiment avoir une idée plus précise sur ce que représentent ces 150 élément/pixel de la 3ième dimension...