Question

像我之前的那么多，我正在写一个PHP脚本来做一些图像缩略图。该脚本已获得WOMM（适用于我的机器）认证，但当我将其移至我的主机（1＆amp; 1 Basic）时，存在一个问题：无法处理某些文件大小以上的图像。我已将所有操作移至文件系统，以确定它不是潜在的POST问题。这是相关的代码：


function cropAndResizeImage( $imageLocation )
{
  //
  // Just to be certain
  //
  ini_set('display_errors','on');
  error_reporting(E_ALL);
  ini_set('memory_limit','128M'); 
  ini_set('max_execution_time','300');  

  $image_info   = getimagesize($imageLocation);
  $image_width  = $image_info[0];
  $image_height = $image_info[1];
  $image_type   = $image_info[2];

  switch ( $image_type )
  {
    // snip...
    case IMAGETYPE_JPEG:
      $image = imagecreatefromjpeg($imageLocation);
      break;

    default:
      break;
  }

  // snip...
}

利用我println调试的神秘力量，我已经确定imagecreatefromjpeg没有返回;实际上，脚本在到达时会完全停止。一些事实：

这与filesize相关。 1MB以下的图像看起来很好（经过现场检查），但图像大约为3MB barf。但不知道精确的截止是什么。
这不是因为服务器超时; wget在3MB图像上返回＆lt; 1s，在“适当小”图像上显示更长时间（表示没有处理大图像）。
使用@预设函数调用以抑制错误无效。这与脚本没有抛出错误的事实非常匹配，它只是默默地终止于此函数调用。

如果我不得不猜测，可能有一些GD参数我不知道（或有权访问）限制1＆amp; 1服务器上的输入文件大小 - 配置变量猜测是由于它的事实barf立即，并且（启发式）不会出现在图像上进行任何实际加载或计算。

有什么建议吗？谢谢你的帮助。

更新（礼貌@Darryl's评论）：对phpinfo的调用表明PHP正在正确更新max_execution_time和memory_limit个变量。这并不一定意味着这些资源正在被分配，只是它们似乎按预期运行。

更新2：根据谷歌的一些参考资料，我尝试优化JPEG（质量从3MB降低到200KB），没有运气，所以这不是图像文件大小的问题。然后我尝试减少原始3888x2592图像的像素数，第一个成功的尺寸是1400x2592（1401x和1402x都导致半分析和错误表示“格式错误的JPEG”，除非整个图像没有多大意义没有加载）。通过进一步减少到1300x2592，我可以实例化我正在寻找的400x300缩略图;在1400x2592，我用来处理该任务的imagecreatetruecolor调用以与imagecreatefromjpeg相同的方式无声地失败。

至于为什么会这样，我有点不确定。 1400 * 2592 == 3.5MB没有什么特别有意义，但我不得不想象这是GD + PHP将处理的像素数量的限制。

Answer 1

请参阅php网站上有关内存使用情况的this note。

*“使用imagecreatefromjpeg（）加载图像所需的内存是图像尺寸和图像位深度乘以开销的函数。

可以从这个公式计算：

Num bytes = Width * Height * Bytes per pixel * Overhead fudge factor“*

Answer 2

我猜1＆amp; 1不允许您更改脚本memory_limit或max_execution_time，因此可能内存不足。您是否尝试过运行phpinfo()来查看限制是什么？

imagecreatefromjpeg正在静默终止脚本

2 个答案: