Comprendre les besoins en mémoire d'un fichier image

Je veux comprendre les besoins en mémoire des fichiers de ressources d'image à afficher sur un écran de résolution 240x400.

L'écran a les spécifications suivantes:

Il prend en charge jusqu'à 18 bits de profondeur de couleur et utilise le pilote d'affichage ILI9327.

En supposant que je doive afficher 50 icônes différentes, chacune de taille 10 mm X 10 mm, quel est l'espace de stockage requis?

Voici mes calculs:

Pixels par mm = 400 / 61,2 = 6,536

Nombre de pixels dans une image = 65,36 x 65,36 = 4272 pixels

Chaque pixel nécessitera 18 bits X 3 (pour R, G et B) = 54 bits

Nombre total de bits requis = 4272 x 54 = 230688 bits = 28,16 kilo-octets

Pour 50 images, il me faudra 1,375 mégaoctets de stockage.

Mon calcul est-il correct?

Pixels par mm = 400 / 61,2 = 6,536

Ouaip.

Nombre de pixels dans une image = 65,36 x 65,36 = 4272 pixels

Eh bien, vous voulez dire des pixels par icône. Mais même ainsi, vous ne pouvez pas produire de pixels fractionnaires, donc votre nombre doit être 65 x 65 ou 66 x 66. Et cela conduit à une simplification supplémentaire. Pourquoi ne pas faire vos icônes 64 x 64? Cela simplifiera les calculs d'adresse pour votre mémoire et ne produira qu'un "rétrécissement" d'environ 2%. Et croyez-moi, à cette taille, personne ne le remarquera. Vos icônes auront alors une taille de 4096 pixels.

Chaque pixel nécessitera 18 bits X 3 (pour R, G et B) = 54 bits

Nan. Comme jms vient de répondre, c'est 18 bits par pixel au total, soit 6 bits par couleur. Encore une fois, cependant, vous ne devriez pas trop vous soucier du niveau de bits. Stockez vos valeurs de couleur sous forme d'octets partiels (6 bits par octet) avec des octets séparés par couleur. Cela prendra 33% de mémoire en plus, mais réduira considérablement votre charge de traitement lors du transfert de la mémoire à l'écran.

Nombre total de bits requis = 4272 x 54 = 230688 bits = 28,16 kilo-octets

Le nombre total de bits est de 4096 x 24, ou 98304 bits, ou 12288 octets.

Pour 50 images, il me faudra 1,375 mégaoctets de stockage.

12288 fois 50 donne 614400 octets.

Simplifiez-vous la vie en créant des icônes de 64 × 64 pixels. Tracez une bordure autour d'eux si vous voulez qu'ils paraissent plus grands.

Avec le format couleur 16 bits, cela ne nécessite que 8 Ko par icône, ou 400 Ko pour l'ensemble de 50.

Une forme simple de compression consiste à utiliser une table de couleurs au lieu de stocker directement la couleur de chaque pixel. 16 couleurs est souvent plus que suffisant pour une icône, surtout si vous appliquez un peu de tramage créatif. Cela réduit le stockage à 2 Ko par icône, plus 32 octets pour la table des couleurs. Le stockage total est un peu plus de 101 Ko si chaque icône a sa propre table de couleurs.

Juste pour satisfaire ma propre curiosité, j'ai saisi l'image "pire des cas" suivante (d' ici ):

Cette ligne de commande ImageMagick

convert image.jpg -crop 267x267+66+0 -resize 64x64 -colors 16 final.png

l'a transformé en ceci:

Pas mal, et bien sûr, les images source avec une gamme de couleurs plus limitée sortiront encore mieux. Par exemple, voici Olin, traité de la même manière:

En savoir plus sur la profondeur de couleur

En développant la réponse de Dave Tweed, vous pouvez faire encore mieux que ce qu'il a montré.

Voici le même original de grande taille qu'il a utilisé:

Recadrée pour être carrée et réduite à 64 x 64 pixels mais en utilisant la couleur pleine (8 bits par rouge, grn, blu):

L'arrondi des informations de couleur de 8 bits par canal à 6 bits entraîne:

C'est ce que votre écran peut faire, car vous dites qu'il prend en charge une profondeur de couleur de 18 bits.

Arrondir les informations de couleur à 5 bits pour le rouge, 6 pour le vert et 5 pour le bleu, pour un total de 16 bits / pixel donne:

Cela devrait vraiment être assez bon pour les icônes.

Même sans compression, les icônes de ce format ne prennent que 64 x 64 x 2 = 8192 octets. 50 de ces images nécessiteraient 409 600 octets.

Chaque pixel nécessitera 18 bits X 3 (pour R, G et B) = 54 bits

Votre estimation est incorrecte. La valeur "18 bits" est par pixel , pas par couleur. Les canaux rouge, vert et bleu ont chacun une profondeur de bits maximale de 6 bits (64 valeurs différentes), 18 bits au total.
Ce contrôleur d'affichage prend également en charge un mode 16 bits (où les données de pixels n'ont que 5 bits pour le rouge, 6 pour le vert et 5 pour le bleu), ce qui facilite le regroupement de chaque pixel en seulement deux octets. Cela facilite le stockage efficace des bitmaps et augmente la quantité de pixels que vous pouvez écrire sur l'affichage par seconde.

Nombre de pixels dans une image = 65,36 x 65,36 = 4272 pixels

Vous ne pouvez pratiquement pas stocker de pixels fractionnaires , donc vos bitmaps réels (images / sprites / caractères / autres) seraient probablement 65 ² = 4225 pixels.

Dans la voie la plus simple (format 16 bits R5G6B5 pixels), 4225 * 16 bits équivaudraient à 67600 bits par bitmap, ou 8450 octets par bitmap. 50 images nécessiteraient 423 ko (sans compression).

Si vous voulez vraiment la profondeur de couleur complète, vous avez besoin de plus de 2 octets par pixel. À ce stade, vous pourriez tout aussi bien consacrer un octet à chaque couleur (comme le suggère WhatRoughBeast), ce qui augmentera encore les besoins de stockage de 3/2 (634 ko pour 50 bitmaps de 65 x 65).

Vous pouvez également compresser les pixels de 18 bits les uns à côté des autres dans la mémoire (bits de sous-pixels non alignés avec les limites d'octets), sans gaspiller aucun bit. Vous n'auriez besoin que de 476 ko pour les bitmaps 50 65x65 18 bits, mais ce serait difficile à programmer et plus lent à traiter.