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

9

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:

spécifications

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?

Whiskyjack
la source
2
Vous calculez les exigences de stockage de niveau supérieur. En général, les images sont compressées, et il est souvent plus rapide de lire et de décompresser à la volée (disons une carte SD) que de lire les octets supplémentaires d'un fichier non compressé. Cela est souvent dû au fait que les E / S du périphérique sont un goulot d'étranglement.
Kingsley

Réponses:

17

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.

WhatRoughBeast
la source
1
Mais sûrement, si nous parlons de stockage persistant, vous stockeriez vos icônes compressées au format PNG ou JPEG? Ou si nous parlons de framebuffer, alors ce sont simplement des (display_width * display_height * bpp) / 8octets?
2018
@aroth - Cela vous fait carrément entrer dans le domaine des compromis. Quoi de plus important, la taille de la mémoire ou les exigences de traitement? Opter pour des images non compressées permet un transfert essentiellement indolore à l'écran au prix de gros fichiers. C'est encore plus facile sans avoir à décompresser les données de couleur d'un mot plus gros. Déballer une image compressée et / ou appliquer des tables de couleurs permet des fichiers de données beaucoup plus petits, mais l'effort de traitement peut être intimidant pour un débutant. Tout est affaire de priorités et de goût.
WhatRoughBeast
11

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 ):

le pouvoir des couleurs

Cette ligne de commande ImageMagick

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

l'a transformé en ceci:

entrez la description de l'image ici

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:

entrez la description de l'image ici entrez la description de l'image ici

Dave Tweed
la source
2
Mot-clé: couleur indexée . Si par exemple 16 couleurs par bitmap ne suffisent pas, vous pouvez diviser l'icône en plusieurs bitmaps plus petits, chacun avec une palette différente. L'application de tramage peut également aider.
jms
9

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.

Olin Lathrop
la source
2
Mon image est compressée à 4 bits par pixel (16 couleurs) - 2 000 octets par icône, plus une table de recherche de 32 octets. Je voulais montrer à quoi ressemble le tramage avec un ensemble limité de couleurs.
Dave Tweed
Étant donné que nous comparons différentes profondeurs de couleurs, pensez à en ajouter une avec une palette de couleurs 8 bits? Cela se situerait à mi-chemin (logarithmique) entre les variantes 4 bits et 16 bits que nous avons déjà ici.
ilkkachu
@Dave: Ce n'était pas clair dans votre réponse, mais cela explique les artefacts de tramage.
Olin Lathrop du
8

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.

entrez la description de l'image ici

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 2 = 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.

jms
la source