只有在浏览器停止发送已发送足够数据以在用户屏幕上显示它们之后，此函数才会变得很棒，因为它的可能性以及发送更多像素绝对没有用处。这是 jpeg 渐进性的当前目的，但尚未实现。之后，您无需为不同密度的屏幕创建许多版本的图片，这将节省很多东西。
(PHP 4, PHP 5, PHP 7, PHP 8)
imageinterlace — 启用或禁用隔行扫描
imageinterlace() 打开或关闭隔行扫描位。
如果设置了隔行扫描位并且图像用作 JPEG 图像，则图像将创建为渐进式 JPEG。
| 版本 | 描述 |
|---|---|
| 8.0.5 | imageinterlace() 现在返回 bool；以前它返回 int（隔行扫描图像为非零，否则为零）。 |
| 8.0.0 |
image 现在期望一个 GdImage 实例；以前，期望一个有效的 gd resource。 |
| 8.0.0 |
enable 现在期望一个 bool；以前它期望一个 int。 |
示例 #1 使用 imageinterlace() 打开隔行扫描
<?php
// 创建一个图像实例
$im = imagecreatefromgif('php.gif');
// 启用隔行扫描
imageinterlace($im, true);
// 保存隔行扫描图像
imagegif($im, './php_interlaced.gif');
imagedestroy($im);
?>只有在浏览器停止发送已发送足够数据以在用户屏幕上显示它们之后，此函数才会变得很棒，因为它的可能性以及发送更多像素绝对没有用处。这是 jpeg 渐进性的当前目的，但尚未实现。之后，您无需为不同密度的屏幕创建许多版本的图片，这将节省很多东西。这个函数真的救了我！
好吧，为了测试，我应该上传几个 jpg，有些具有 jfif 编码，
因此，当我在 fpdf、tcpdf 中包含它们时，某些颜色会丢失（我尝试了 2 个开源库以最大程度地减少错误以了解问题所在）。
我现在使用的缩略图函数（已修复）是
public static function jpgtofilethumb($file,$thumb,$lun,$quality){
//来自 php.net
list ($x, $y) = @getimagesize ($file);
$img = @imagecreatefromjpeg ($file);
if ($x > $y) {
$tx = $lun;
$ty = round($lun / $x * $y);
} else {
$tx = round($lun / $y * $x);
$ty = $lun;
}
$thb = imagecreatetruecolor ($tx, $ty);
// 启用隔行扫描
if(imageistruecolor($thb)) imageinterlace($thb, true);
imagecopyresampled ($thb,$img, 0,0, 0,0, $tx,$ty, $x,$y);
imagejpeg ($thb, $thumb, $quality);
imagedestroy ($thb);
imagedestroy ($img);
}有人建议此函数可用于检索存储在文件中的图像的隔行扫描位。情况并非如此。
虽然如果传递有效的 Image 资源，imageinterlace() 会返回 0 或 1，但将文件名作为字符串传递会导致 PHP 警告，并且返回值既不是 0 也不是 1。dr_snapid 的评论“服务器发送每 N 行”并不完全正确。Web 服务器无需了解其发送的文件内容；它的工作只是发送数据。相反，图像的创建方式使得对应于“每 N 行”的数据出现在文件的开头，随着浏览器接收更多文件，细节可以逐渐填充。在 PHP 的情况下，数据可能是动态生成的而不是从文件提取的，但这并不改变数据本身不同的事实，而不是发送方式。*
事实上，对于 JPEG 来说，它更像是“每 N 个像素”，而不是“每 N 行”，其中 N 逐渐减小，从而产生一个网格，随着数据的接收，网格变得越来越精细（因此出现低分辨率图像变得更详细）。浏览器基本上估计像素之间有什么，可能只是混合颜色，而“真实”数据继续到达。这与非渐进式 JPEG 相比，是一种根本不同的数据编码方法，再加上该格式的其他压缩技术，确实可能导致不同的文件大小。
*你能想象如果服务器期望使用不同的算法发送不同的文件类型，而浏览器期望能够接收所有这些文件类型，那么 Web 会变得多么容易出错吗？如果您需要在 Flash 中加载生成的图像，请将 imageinterlace() 设置为 0。Flash 不支持渐进式 JPEG在使用 Ming 时，此函数很有用，因为 SWFBitmap 构造函数将使用非隔行扫描的 Jpeg 文件，因此您必须使用 imageinterlace(0);补充一下关于 jpeg 渐进原理的 5 分钱：jpeg 中没有存储多个低分辨率图像以及原始图片，唯一更改的是“像素”的顺序。在 jpeg 中，图像被划分为 8x8 像素的区域，因此，而不是像素的线性顺序（逐行），首先是每个 8x8 区域的一个像素包含在图像数据流的开头，因此当浏览器接收到所有 8x8 区域的像素时，它可以显示“像素化”图像，并且一旦它接收到更多数据，浏览器就可以添加更多像素并“锐化”图像。关于 MichaelSoft 的注释“Imageinterlace($im, 1) 创建一个 JPG，它在显示任何内容之前先完全加载”
实际上，这并不完全正确。
这只发生在 Internet Explorer（任何版本，目前为止）中，因为它似乎不支持渐进显示，而是在加载完成后显示图像。其他浏览器（Mozilla、Mozilla Firefox、Opera、Konqueror 等）则按预期执行其工作：显示非常低分辨率的图像，然后叠加中低分辨率的图像（在加载过程中），然后显示越来越多的细节。微软 Internet Explorer 中存在一个错误（至少目前是这样），这意味着渐进式/隔行 JPEG 在加载过程中通常根本不会显示，只有当整个图片加载完成后才会突然出现。普通的非隔行/非渐进式 JPEG 会在加载时逐行显示，这反而会让人产生加载速度更快的错觉。MSIE 对此的处理方式绝对是反的！！
其他浏览器（如 Mozilla/FireFox）中没有出现这种行为——在这些浏览器中，图像按预期渐进加载。隔行扫描不会存储另一张图像，它只是简单地改变了图像线条发送和渲染的顺序。服务器发送每第 N 行，到达末尾后，再返回开头，读取中间的线条。
在每次传递后，浏览器都会显示已下载的线条，并用相同的方式填充尚未接收到的线条，但每次传递填充的间隙都会变小，图像会变得更清晰。经过多次传递后，每行都已读取，浏览器已以完整细节渲染图像。
希望这说得通，这确实解释了为什么文件大小不应该有太大差异，所以我无法解释为什么有些人观察到文件大小差异。
据我了解，文件中只有一个比特表示它是隔行扫描还是非隔行扫描，如果设置为 1，服务器和客户端（浏览器）只是以不同的方式处理它。