时间戳

首页 > 解决方案 > 索引颜色内存大小与原始图像

colors - 索引颜色内存大小与原始图像

问题描述

在这篇文章中https://en.m.wikipedia.org/wiki/Indexed_color

它是这样说的：

调色板大小超过 256 个条目的索引彩色图像很少见。实际限制是每个像素大约 12 位，4,096 个不同的索引。由于以字节为单位的调色板大小大于原始图像数据本身，因此使用索引的 16 bpp 或更高并不能提供索引彩色图像的特性。此外，有用的直接 RGB 高彩模式可用于 15 bpp 及以上。

我不明白为什么索引的 16 bpp 或更高在内存方面效率低下

因为在这篇文章中还有这个：

索引颜色节省了大量的内存、存储空间和传输时间：使用真彩色，每个像素需要 24 位，即 3 个字节。典型的 640×480 VGA 分辨率真彩色未压缩图像需要 640×480×3 = 921,600 字节 (900 KiB)。将图像颜色限制为 256，每个像素只需要 8 位，即每个 1 字节，因此示例图像现在只需要 640×480×1 = 307,200 字节（300 KiB），加上 256×3 = 768 个额外字节来存储调色板贴图本身（假设为 RGB），大约是原始大小的三分之一。较小的调色板（4 位 16 色、2 位 4 色）可以将像素打包得更多（达到六分之一或十二分之一），显然是以色彩准确性为代价的。

如果我有 640x480 分辨率并且如果我想使用 16 位调色板：640x480x2(16 位 == 2 字节) + 65536(2^16)*3(rgb) 614400 + 196608 = 811008 字节

原始图像内存大小：640x480x3(rgb) 921600 字节

所以 811008 < 921600

如果我有 1920x1080 分辨率：

原始图像：1920x1080x3 = 6 220 800

索引颜色：

1920x1080x2 + 调色板尺寸(2**16 * 3)

4147200 + 196608

4343808 字节

所以再次索引颜色在内存方面是有效的。我不明白，为什么在这篇文章中说它效率低下。

标签： colorssizergbpaletteindexed

解决方案

这实际上取决于图像的大小。正如你所说，如果b是每个像素的字节数，p是像素数，那么图像数据大小i是：

我 = p * b

色表大小t为：

t = 2^(b * 8) * 3

因此，原始图像与索引图像占用相同空间的点是：

p * 3 = p * b + 2^(b * 8) * 3

我现在将解决 p：

p * 3 - p * b = 2^(b * 8) * 3

p * (3 - b) = 2^(b * 8) * 3

p = (2^(b * 8) * 3) / (3 - b)

因此，对于各种 bytepp，使用索引图像的最小图像大小会达到平衡：

1 bytepp (8 bit) - 384 pixels (like an image of 24 x 16)
1.5 bytepp (12 bit) - 8192 pixels (like an image of 128 x 64)
2 bytepp (16 bit) - 196,604 pixels (like an image of 512 x 384)
2.5 bytepp (20 bit) - 6,291,456 pixels (like an image of 3072 x 2048)
2.875 bytepp (23 bit) - 201,326,592 (like an image of 16,384 x 12,288)

如果您使用小于 512 x 384 的图像，则每像素 16 位索引颜色将占用比原始 24 位图像数据更多的空间。

推荐阅读