高效处理超宽但不太高的位图?

发布于 2024-08-29 03:04:39 字数 192 浏览 2 评论 0原文

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

我是否可以更有效地执行此操作,例如直接将其创建为 gif,而不是稍后保存?

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

Is there any way to create a more space/resource efficient bitmap?
Currently I try to render a file, approx 800px high but around 720000px wide.
It crashes my application, presumably because of the share memory-size of the bitmap.

Can I do this more efficiently, like creating it as an gif directly and not later when I save it?

I try to save a series of lines/rectangles from a real world reading, and I want it to be 1px per 1/100th of a second.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

一抹淡然 2024-09-05 03:04:39

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

这意味着您要创建的图像将是:

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

尝试创建这么大的图像基本上会破坏您的记忆。

无论您想要实现什么目标,答案就是平铺和缓存您的图像

You have to remember that any image you load into memory regardless if it's a GIF or JPEG or whatever on disk will be turned into a 32 bit bitmap which means four bytes per pixel.

This means that the image you're creating will be:

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

You're basically blowing your memory by trying to create an image that large.

For whatever you're trying to accomplish the answer is tiling and caching your image.

蓦然回首 2024-09-05 03:04:39

您的映像约为 2.3 GB,无论机器是 32 位还是 64 位,您可以拥有的最大 .Net 对象都是 2 GB。

您必须将位图分成块才能处理该大小的图像。

Your image is about 2.3 gig, and the biggest .Net object you can have is 2 gig regardless if the machine is 32 or 64 bit.

You're going to have to break the bitmap up in chunks to handle an image that size.

如何视而不见 2024-09-05 03:04:39

您必须执行以下任一操作:

  • 强制 x64 环境并获取 RAM 的堆栈负载。

  • 更改您的架构

您的映像将略高于 2 GB。

You're going to have to either:

  • Force x64 environment and get a stack load of RAM.

  • Change your architecture

Your image is going to be a little over 2 GB.

心是晴朗的。 2024-09-05 03:04:39

我可以做得更有效吗,比如直接将其创建为 gif,而不是稍后保存时?

您可以在写入时压缩图像。它不再是(未压缩/未编码)“位图”格式。压缩算法的示例包括“行程编码”和“霍夫曼”。

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

也可能将其保存在几个较小的、不连续的内存块中:而不是单个巨大的内存块(太大以至于一开始就无法分配)。

Can i do it more efficient, like creating it as an gif directly and not later when i save it?

You can compress the image as you write it. It won't be in (uncompressed/unencoded) "bitmap" format anymore. Examples of compression algorithm include "run-length encoding" and "huffman".

Also, use the least possible color-depth: preferaby black-and-white, i.e. 1-bit-per-pixel.

Also perhaps save it in several, smaller, discontinuous memory chunks: instead of a single huge memory chunk (so huge that it can't even be allocated in the first place).

隐诗 2024-09-05 03:04:39

如果将其创建为高 720000 像素、宽 800 像素的 bmp,并在实际显示时旋转它(*),
您可以将数据以位图形式直接流式传输到文件。也许使用 RLE 而不是原始位图;在这种情况下,以这种方式进行流传输应该仍然是可能的。

(*)将其显示出来作为练习留给读者。你需要瓷砖什么的。

If you create it as 720000px high and 800px wide as a bmp and rotate it when actually displaying it(*),
you can stream the data directly to file in bitmap form. Maybe use RLE instead of raw bitmap; streaming in this manner should still be possible in that case.

(*)Displaying it is left as an exercise to the reader. You'll need tiling or something.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文