1

我不确定内存是否是这里的罪魁祸首。我正在尝试从内存中的数据（它以前来自数据库）中实例化一个 GD 图像。我尝试这样的电话：

my $image = GD::Image->new($image_data);

$image回来了undef。GD 的 POD 说构造函数将undef在内存不足的情况下返回，所以这就是我怀疑内存的原因。

图像数据为 PNG 格式。如果我调用 newFromPngData，也会发生同样的事情。

这适用于非常小的图像，例如 30K 以下。但是，稍微大一点的图像，比如 ~70K 会导致问题。我不认为 70K 的图像会导致这些问题，即使在它被瘪了之后。

这个脚本通过 Apache 2.0 在 CGI 下运行，在 OS 10.4 上，如果这很重要的话。

默认情况下，Apache 是否有任何内存限制？它们可以增加吗？

感谢您的任何见解！

编辑：为澄清起见， GD::Image 对象永远不会被创建，因此从内存中清除$image_data它并不是一个真正的选择。

4

2 回答 2

1

GD 库每字节图像大小占用许多字节。这是一个远远超过10：1的比例！

当用户将图像上传到我们的系统时，我们首先检查文件大小，然后再将其加载到 GD 图像中。如果它超过阈值（1 兆字节），我们不会使用它，而是向用户报告错误。

如果我们真的很在意，我们可以将它转储到磁盘，使用命令行“convert”工具将其重新缩放到合理的大小，然后将输出加载到 GD 库中并删除临时文件。

convert -define jpeg:size=800x800 tmpfile.jpg -thumbnail '800x800' -

将缩放图像，使其适合 800 x 800 正方形。它的最长边现在是 800 像素，应该可以安全加载。上面的命令会将缩小的 .jpg 发送到 STDOUT。size= 选项应该告诉 convert 不要费心在内存中保存巨大的图像，但足以缩放到 800x800。

于 2009-11-28T19:19:25.047 回答
0

我遇到过同样的问题几次。

我的解决方案之一就是增加脚本可用的内存量。另一个是清除缓冲区：

原始脚本：

$src_img = imagecreatefromstring($userfile2);
imagecopyresampled($dst_img,$src_img,0,0,0,0,$thumb_width,$thumb_height,$origw,$origh);

编辑脚本：

$src_img = imagecreatefromstring($userfile2);
imagecopyresampled($dst_img,$src_img,0,0,0,0,$thumb_width,$thumb_height,$origw,$origh);
imagedestroy($src_img);

通过清除第一个 src_image 的内存，它释放了足够的空间来处理更多的处理。

于 2008-12-23T05:33:09.273 回答