有效处理超宽但不那么高的位图？答案

【问题标题】：Efficient handling of super wide, but not so tall, bitmap?有效处理超宽但不那么高的位图？
【发布时间】：2011-02-07 03:02:42
【问题描述】：

有什么方法可以创建更节省空间/资源的位图？目前我尝试渲染一个大约 800px 高但大约 720000px 宽的文件。它使我的应用程序崩溃，可能是因为位图的共享内存大小。

我能否更有效地执行此操作，例如直接将其创建为 gif，而不是稍后保存时？

我尝试从现实世界的读数中保存一系列线条/矩形，我希望它是每 1/100 秒 1 像素。

【问题讨论】：

有关 google open id 的帮助，请查看 meta.stackoverflow.com
您可能需要考虑以纯文本格式存储数据，并将用户请求的任何部分呈现为图像（提供导出/导入功能）。您可能会担心这会更令人沮丧，因为用户需要使用您的程序来处理数据，但是处理巨大的图像对用户来说也很困难，所以无论哪种方式，您都遇到了麻烦。
我很想知道您为什么需要这样的图片。

【解决方案1】：

你将不得不：

您的图片将超过 2 GB。

【讨论】：

【解决方案2】：

如果您将其创建为 720000px 高和 800px 宽的 bmp 并在实际显示时旋转它（*），您可以将数据直接以位图形式流式传输到文件。也许使用 RLE 而不是原始位图；在这种情况下，以这种方式流式传输仍然是可能的。

(*)显示它作为练习留给读者。你需要平铺什么的。

【讨论】：

【解决方案3】：

您必须记住，无论是 GIF 或 JPEG 还是磁盘上的任何图像，您加载到内存中的任何图像都将转换为 32 位位图，这意味着每个像素四个字节。

这意味着您正在创建的图像将是：

4 bytes * 800 pixels high * 720,000 pixels wide = 2,304,000,000 bytes

你试图创建这么大的图像基本上是在破坏你的记忆。

无论您想要完成什么，答案是平铺和缓存您的图像。

【讨论】：

【解决方案4】：

我可以做得更高效，比如直接将其创建为 gif，而不是稍后保存吗？

您可以在编写图像时对其进行压缩。它不再是（未压缩/未编码的）“位图”格式。压缩算法的例子包括“run-length encoding”和“huffman”。

另外，使用尽可能低的颜色深度：最好是黑白，即每像素 1 位。

也可以将它保存在几个更小、不连续的内存块中：而不是单个巨大的内存块（大到一开始甚至无法分配）。

【讨论】：

【解决方案5】：

您的图像大约是 2.3 gig，无论机器是 32 位还是 64 位，您可以拥有的最大 .Net 对象是 2 gig。

您将不得不将位图分成块来处理这样大小的图像。

【讨论】：