Discussion :

[Auteur]

bonjour,


pour le travail j'utilise une application qui implémente des fonctions directX pour afficher des images 2D et 3D.
Je me suis aperçu que les temps de chargement de ces images variaient considérablement d'un format à l'autre !


Les images testées font toutes 800x600 pixels.

• Avec une bitmap 24 bits, le temps de chargement est très court bien que le fichier soit volumineux (1,4Mo) ;
• Avec une images 8 bits indexée, le temps de chargement s'allonge ;
• Avec les formats jpg et png c'est catastrophique

Je n'ai plus en tête ces temps de chargement au moment où je poste le message mais ils varient pratiquement du simple au double.
Je précise que dans mon cas ces durées sont critiques : un temps de chargement supérieur à 30ms est considéré comme "long".


1- Pourquoi les temps de chargement des images varient considérablement d'un format à l'autre ?
Est-ce inhérent à directX, à l'application qui implémente ces fonctions ou à la carte graphique ?


2- J'ai vu que pour le format jpg, je pouvais créer des images entrelacées ou désentrelacées. Est-ce que directX ou la carte vidéo gère différemment des ces deux types d'images ? Si oui comment ?


Pour info :
je travaille avec Windows XP, carte graphique Quadro FX 550, deux écrans LCD en 1280x1024 à 60Hz.

[stardeath]

bonjour,

alors déjà il faut voir qu'à la base les bmp, png et jpg ne sont pas du tout stockés pareil :

- le bmp est un simple header suivi d'un tableau de valeurs qui représente directement la valeur pour chaque pixel de ton image -> le cout de décodage de l'information est nul

- le jpg est nettement plus compliqué : http://fr.wikipedia.org/wiki/JPEG#La_compression_JPEG
sur le schéma, en bas de droite à gauche, on voit tout de suite la teneur en calcul de la lecture d'un jpg

- j'ai pas de schéma pour le png, mais de toute façon c'est plus couteux en temps de calcul que le bmp.

donc même si on doit lire un "gros" bmp, le cout de lecture peut être considéré comme gratuit, à l'inverse des 2 autres qui doivent subir une décompression et une ré-interprétation des données.

et finalement que ça soit directx, la cg ou une bibliothèque tierce, à résolution équivalente, un bmp sera plus rapide à chargé qu'un png ou jpg.
(bien sur dans le cas ou la vitesse de lecture d'un fichier sur le disque ne devienne pas handicapant)

pour l'entrelacement je sais pas.

[Auteur]

et finalement que ça soit directx, la cg ou une bibliothèque tierce, à résolution équivalente, un bmp sera plus rapide à chargé qu'un png ou jpg.
(bien sur dans le cas ou la vitesse de lecture d'un fichier sur le disque ne devienne pas handicapant)

ok il semblait bien que c'était la décompression des images qui posait problème...

[LeGreg]

ok il semblait bien que c'était la décompression des images qui posait problème...

Il y a deux paramètres à prendre en compte : la vitesse de décompression et la place mémoire occupée par le stockage de masse.

Stocker toutes les images sous forme BMP pour les textures n'est pas réaliste le plus souvent (sauf pour le plus simple des jeux.. et encore là c'est une mauvaise utilisation des ressources) à cause de la place prise sur le disque dur ou le DVD. Mais en même temps stocker sous forme de JPEG peut rendre le chargement long.. et c'est encore un plus gros problème si les textures doivent être chargées en continu pendant le jeu (monde ouvert ou, simplement, pas assez de RAM disponible pour faire tenir un niveau de détail correct)ou sur un système avec des capacités de décompression réduites (console ?).

Ceci dit il y a des intermédiaires. Par exemple les jeux actuels utilisent des textures au format DXTC (un dérivé du S3TC). Le format DXTC s'il est compressé à l'avance peut prendre moins de place qu'un BMP simple et être quasi immédiat à décompresser (la décompression se fait en temps réel par la carte graphique).

Mais même le DXTC peut encore être trop volumineux pour certains supports/types de jeux. Par exemple Quake Wars utilisait une seule grosse texture pour tout le terrain de jeu et ne pouvait pas stocker sous forme DXTC parce que c'était encore trop gros (le nombre de DVD était un problème mais aussi la vitesse de transfert depuis le DVD). Ils ont donc réimplémenté une variante de JPEG (block compression, discrete cosine transform, runlength encoding et huffman) mais optimisé pour la vitesse de décompression et dans un espace de couleur adapté à leur "monde".

Bref il y a sans doute beaucoup à faire, et beaucoup dépend du type de jeu envisagé et des contraintes (limité par les temps d'accès DVD ? par la puissance du processeur central ? Décodage possible et/ou natif sur le GPU ?)/

LeGreg

[Auteur]

Le logiciel en question n'est pas pour réaliser des jeux

Il ne gère que des images bmp, jpg, tif et png. Pour les objets 3D on peut définir une image parmi les formats supportés comme texture.

Ce qui me surprend quand est que le temps de chargement d'une image est lié uniquement à directX, la carte graphique n'a visiblement aucun rôle là dedans ?

[LeGreg]

Le logiciel en question n'est pas pour réaliser des jeux

Les règles d'optimisation sont les mêmes pour les logiciels de jeu et les autres. Si c'est lent dans un cas ce sera lent dans l'autre.

Il ne gère que des images bmp, jpg, tif et png. Pour les objets 3D on peut définir une image parmi les formats supportés comme texture.

Ce qui me surprend quand est que le temps de chargement d'une image est lié uniquement à directX, la carte graphique n'a visiblement aucun rôle là dedans ?

Tout dépend ce qui domine le temps de chargement. En général ce sont soit les accès au disque (ou autre mémoire de masse), soit les calculs (de décompression). Mais si l'image était déjà décompressée en mémoire (pour être chargée en mémoire graphique de manière opportune) alors parfois le transfert par le bus PCI-E peut avoir une importance non négligeable (voire être le point d'étranglement et causer des micro-saccades).

Il est aussi envisageable de faire la phase de décompression sur la carte graphique (DirectCompute va dans ce sens). Et là la puissance de calcul de la carte graphique aura une importance plus ou moins grande.

M'enfin dans ton cas, ton problème parait assez théorique sauf si tu as accès au code source de ton programme et que tu peux le modifier pour l'améliorer (ou si tu as accès direct au développeur et lui faire des suggestions pour la prochaine version)..

[Mat.M]

Il ne gère que des images bmp, jpg, tif et png. Pour les objets 3D on peut définir une image parmi les formats supportés comme texture.

Ce qui me surprend quand est que le temps de chargement d'une image est lié uniquement à directX, la carte graphique n'a visiblement aucun rôle là dedans ?

C'est normal !
Pour charger une jpg il faut la décompresser la décoder il faut faire un arbre de Huffman je crois.

http://www.ijg.org/

Tandis que pour lire une bmp c'est tout bête : il faut lire l'entête avec un simple fread ( de 128octets) lire au besoin la palette de couleurs et lire le reste qui n'est qu'un gros bloc de triplets r g b .

http://www.cplusplus.com/src/

Donc si tu fais un simple fread ou même une API de Windows pour lire un fichier cela va se faire très vite !
Cela se comprend parfaitement que le temps de lecture d'une jpg soit plus long qu'une bmp.
En plus quand tu lis une bitmap il faut au besoin aligner les octets composant la teinte R G B avec un format compatible pour la carte graphique.

2- J'ai vu que pour le format jpg, je pouvais créer des images entrelacées ou désentrelacées. Est-ce que directX ou la carte vidéo gère différemment des ces deux types d'images ? Si oui comment ?

A ma connaissance non le format de fichier fut-il Png ou Jpg c'est en amont ; Direct X doit toujours décompresser et décoder la bitmap ; si tu veux afficher une bitmap avec le GDI il faut d'abord la décoder pour en faire un bloc d'octets compatible avec le mode d'affichage et la carte graphique.
La carte graphique elle ne connait que des octets pour la couleur.
Avec les API win32 il n'ya rien en natif pour lire une jpeg c'est à toi de fournir le code pour pouvoir la décoder