Comprender los requisitos de memoria para un archivo de imagen

9

Quiero comprender los requisitos de memoria para que los archivos de recursos de imagen se muestren en una pantalla de resolución 240x400.

La pantalla tiene las siguientes especificaciones:

Admite una profundidad de color de hasta 18 bits y utiliza el controlador de pantalla ILI9327.

Suponiendo que necesito mostrar 50 iconos diferentes, cada uno de tamaño 10 mm X 10 mm, ¿cuál es el espacio de almacenamiento requerido?

Aquí están mis cálculos:

Píxeles por mm = 400 / 61.2 = 6.536

Número de píxeles en una imagen = 65.36 x 65.36 = 4272 píxeles

Cada píxel requerirá 18 bits X 3 (para R, G y B) = 54 bits

Total de bits requeridos = 4272 x 54 = 230688 bits = 28.16 kilobytes

Para 50 imágenes, requeriré 1.375 megabytes de almacenamiento.

¿Es correcto mi cálculo?

display

— Whiskyjack
fuente

2

Estás calculando los requisitos de almacenamiento de nivel superior. Por lo general, las imágenes se comprimen y, a menudo, es más rápido leer y descomprimir sobre la marcha (por ejemplo, una tarjeta SD) que leer los bytes adicionales de un archivo no comprimido. Esto a menudo se debe a que la E / S del dispositivo es un cuello de botella.

— Kingsley

17

Píxeles por mm = 400 / 61.2 = 6.536

Sip.

Número de píxeles en una imagen = 65.36 x 65.36 = 4272 píxeles

Bueno, te refieres a píxeles por icono. Pero aun así, no puede producir píxeles fraccionarios, por lo que su número debe ser 65 x 65 o 66 x 66. Y esto lleva a una mayor simplificación. ¿Por qué no hacer sus íconos de 64 x 64? Esto simplificará los cálculos de direcciones para su memoria y solo producirá una "contracción" de aproximadamente el 2%. Y confía en mí, a este tamaño nadie se dará cuenta. Entonces sus iconos tendrán un tamaño de 4096 píxeles.

Cada píxel requerirá 18 bits X 3 (para R, G y B) = 54 bits

No Como acaba de responder jms, son 18 bits por píxel en total, o 6 bits por color. Sin embargo, una vez más, debe considerar no preocuparse tanto por el nivel de bits. Almacene sus valores de color como bytes parciales (6 bits por byte) con bytes separados por color. Esto tomará un 33% más de memoria, pero reducirá drásticamente su carga de procesamiento al transferir de la memoria a la pantalla.

Total de bits requeridos = 4272 x 54 = 230688 bits = 28.16 kilobytes

Los bits totales son 4096 x 24, o 98304 bits, o 12288 bytes.

Para 50 imágenes, requeriré 1.375 megabytes de almacenamiento.

12288 veces 50 da 614400 bytes.

— WhatBoughBeast
fuente

1

Pero, seguramente, si hablamos de almacenamiento persistente, ¿almacenaría sus iconos comprimidos como PNG o JPEG? ¿O si estamos hablando de framebuffer, entonces son simplemente (display_width * display_height * bpp) / 8bytes?

— Aroth

@aroth: esto te lleva directamente al ámbito de las compensaciones. ¿Qué es más importante, el tamaño de la memoria o las demandas de procesamiento? La búsqueda de imágenes sin comprimir permite una transferencia esencialmente indolora a la pantalla a costa de archivos grandes. Es aún más fácil sin necesidad de descomprimir datos de color de una palabra más grande. Desempacar una imagen comprimida y / o aplicar tablas de colores permite archivos de datos mucho más pequeños, pero el esfuerzo de procesamiento puede ser intimidante para un novato. Todo es cuestión de prioridades y gustos.

— WhatRoughBeast

11

Haz la vida más simple para ti haciendo los íconos de 64 × 64 píxeles. Dibuja un borde alrededor de ellos si quieres que se vean más grandes.

Con el formato de color de 16 bits, esto solo requiere 8 kB por icono, o 400 kB para el conjunto de 50.

Una forma simple de compresión es usar una tabla de colores en lugar de almacenar el color de cada píxel directamente. Con frecuencia, 16 colores son más que suficientes para un icono, especialmente si aplica un poco de tramado creativo. Esto reduce el almacenamiento a 2 kB por icono, más 32 bytes para la tabla de colores. El almacenamiento total es un poco más de 101 kB si cada icono tiene su propia tabla de colores.

Solo para satisfacer mi propia curiosidad, tomé la siguiente imagen del "peor de los casos" (desde aquí ):

Esta línea de comando de ImageMagick

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

lo convirtió en esto:

No está mal, y, por supuesto, las imágenes de origen con una gama de colores más limitada saldrán aún mejor. Por ejemplo, aquí está Olin, procesado de la misma manera:

— Dave Tweed
fuente

2

Palabra clave: color indexado . Si, por ejemplo, 16 colores por mapa de bits no son suficientes, puede dividir el icono en varios mapas de bits más pequeños, cada uno con una paleta diferente. Aplicar difuminado también puede ayudar.

— jms

9

Más sobre profundidad de color

Ampliando la respuesta de Dave Tweed, puedes hacerlo incluso mejor de lo que mostró.

Aquí está el mismo original de gran tamaño que utilizó:

Recortado para ser cuadrado y encogido a 64 x 64 píxeles, pero con rendimientos de color completos (8 bits por rojo, gris, azul):

Redondeando la información de color de 8 bits por canal a 6 bits resulta en:

Eso es lo que puede hacer su pantalla, ya que dice que admite una profundidad de color de 18 bits.

Redondeando la información de color a 5 bits para el rojo, 6 para el verde y 5 para el azul, para un total de 16 bits / píxeles de rendimiento:

Esto realmente debería ser lo suficientemente bueno para los íconos.

Incluso sin ninguna compresión, los íconos de este formato solo toman 64 x 64 x 2 = 8192 bytes. 50 de estas imágenes requerirían 409,600 bytes.

— Olin Lathrop
fuente

2

Mi imagen está comprimida a 4 bits por píxel (16 colores): 2k bytes por icono, más una tabla de búsqueda de 32 bytes. Quería mostrar cómo se ve el dithering con un conjunto limitado de colores.

— Dave Tweed

Como estamos comparando diferentes profundidades de color, ¿le gustaría agregar una con un mapa de colores de 8 bits? Eso estaría a medio camino (logarítmicamente) entre las variantes de 4 bits y 16 bits que ya tenemos aquí.

— ilkkachu

@Dave: Eso no estaba claro en su respuesta, pero eso explica los artefactos de vacilación.

— Olin Lathrop

8

Cada píxel requerirá 18 bits X 3 (para R, G y B) = 54 bits

Tu estimación es incorrecta. El valor de "18 bits" es por píxel , no por color. Los canales rojo, verde y azul tienen una profundidad máxima de 6 bits (64 valores diferentes), 18 bits en total.
Este controlador de pantalla también admite un modo de 16 bits (donde los datos de píxeles solo tienen 5 bits para el rojo, 6 para el verde y 5 para el azul), lo que hace que sea fácil empaquetar cada píxel en solo dos bytes. Esto facilita el almacenamiento eficiente de mapas de bits y aumenta la cantidad de píxeles que puede escribir en la pantalla por segundo.

Número de píxeles en una imagen = 65.36 x 65.36 = 4272 píxeles

Prácticamente no puede almacenar píxeles fraccionarios , por lo que sus mapas de bits reales (imágenes / sprites / caracteres / lo que sea) probablemente serían 65 ² = 4225 píxeles.

En la ruta fácil (formato de píxel R5G6B5 de 16 bits), 4225 * 16 bits equivaldría a 67600 bits por mapa de bits, o 8450 bytes por mapa de bits. 50 imágenes requerirían 423 kB (sin compresión).

Si realmente desea la profundidad de color completa, necesita más de 2 bytes por píxel. En esa etapa, también podría dedicar un byte para cada color (como sugiere WhatRoughBeast), lo que aumentará aún más el requisito de almacenamiento en 3/2 (634 kB para 50 mapas de bits de 65x65).

También puede empaquetar los píxeles de 18 bits uno al lado del otro en la memoria (bits de subpíxeles sin alinear con los límites de bytes), sin perder ningún bit. Solo necesitaría 476 kB para los 50 mapas de bits de 65x65 de 18 bits, pero sería difícil programar y procesar más lentamente.

— jms
fuente