每毫米像素 = 400/61.2 = 6.536

对。

一张图像中的像素数 = 65.36 x 65.36 = 4272 像素

好吧，您的意思是每个图标的像素。但即便如此，您也无法生成分数像素，因此您的数字应该是 65 x 65 或 66 x 66。这会导致进一步的简化。为什么不将您的图标设置为 64 x 64？这将简化内存的地址计算，并且只会产生大约 2% 的“收缩”。相信我，在这个尺寸上没有人会注意到。然后您的图标大小将是 4096 像素。

每个像素需要 18 位 X 3（对于 R、G 和 B）= 54 位

没有。正如 jms 刚刚回答的那样，每像素总共 18 位，或每种颜色 6 位。不过，您应该再次考虑不要太担心位级别。将颜色值存储为部分字节（每字节 6 位），每种颜色有单独的字节。这将多占用 33% 的内存，但在从内存传输到屏幕时会大大减少您的处理负载。

所需的总位数 = 4272 x 54 = 230688 位 = 28.16 KB

总位数为 4096 x 24，或 98304 位，或 12288 字节。

对于 50 张图片，我需要 1.375 兆字节的存储空间。

12288 乘以 50 得到 614400 字节。

通过将图标设置为 64×64 像素，让生活变得简单。如果您希望它们看起来更大，请在它们周围画一个边框。

使用 16 位颜色格式，每个图标只需要 8 kB，或 50 个图标集需要 400 kB。

一种简单的压缩形式是使用颜色表，而不是直接存储每个像素的颜色。对于一个图标来说，16 种颜色通常绰绰有余，特别是如果你应用一点创意抖动。这将每个图标的存储空间减少到 2 kB，再加上颜色表的 32 个字节。如果每个图标都有自己的颜色表，则总存储空间略高于 101 kB。

只是为了满足我自己的好奇心，我抓取了以下“最坏情况”图像（来自这里）：

这个 ImageMagick 命令行

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

把它变成了这样：

不错，当然颜色范围更有限的源图像会更好。例如，这里是 Olin，处理方式相同：

更多关于颜色深度

扩展 Dave Tweed 的答案，你可以做得比他展示的更好。

这是他使用的相同的大尺寸原件：

裁剪为方形并缩小为 64 x 64 像素，但使用全色（每红色、绿色、蓝色 8 位）产生：

将颜色信息从每通道 8 位四舍五入到 6 位会导致：

这就是您的显示器可以做的，因为您说它支持 18 位色深。

将颜色信息进一步四舍五入为红色 5 位、绿色 6 位和蓝色 5 位，总共 16 位/像素产生：

对于图标来说，这真的应该足够好了。

即使没有任何压缩，这种格式的图标也只占用 64 x 64 x 2 = 8192 字节。50 个这样的图像需要 409,600 字节。

每个像素需要 18 位 X 3（对于 R、G 和 B）= 54 位

你的估计不正确。“18 位”值是每个像素，而不是每个颜色。红色、绿色和蓝色通道的最大位深度为 6 位（64 个不同的值），总共 18 位。
该显示控制器还支持 16 位模式（其中像素数据只有 5 位红色，6 位绿色和 5 位蓝色），这使得将每个像素打包成两个字节变得很容易。这使得更容易有效地存储位图并增加每秒可以写入显示器的像素数量。

一张图像中的像素数 = 65.36 x 65.36 = 4272 像素

您实际上无法存储小数像素，因此您的实际位图（图像/精灵/字符/其他）可能是 65 ² = 4225 像素。

走简单的路线（16 位 R5G6B5 像素格式），4225 * 16 位相当于每个位图 67600 位，或每个位图 8450 字节。50 张图像需要 423 kB（无压缩）。

如果您真的想要完整的颜色深度，则每个像素需要超过 2 个字节。在那个阶段，您最好为每种颜色分配一个字节（正如 WhatRoughBeast 建议的那样），这将使存储需求进一步增加 3/2（50 个 65x65 位图为 634 kB）。

您还可以在内存中将 18 位像素彼此相邻打包（子像素位与字节边界不对齐），而不会浪费任何位。对于 50 个 65x65 18 位位图，您只需要 476 kB，但是编程会很痛苦并且处理速度会更慢。