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?
Respuestas:
Sip.
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.
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.
Los bits totales son 4096 x 24, o 98304 bits, o 12288 bytes.
12288 veces 50 da 614400 bytes.
fuente
(display_width * display_height * bpp) / 8bytes?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
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:
fuente
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.
fuente
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.
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 2 = 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.
fuente