只有在瀏覽器停止傳送已足夠顯示在使用者螢幕上的資料後，這個函式才會真正發揮作用，因為繼續傳送更多像素完全沒有必要。這就是 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 資源。 |
| 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 中時，有些顏色會丟失（我嘗試了兩個開源程式庫，盡量減少錯誤以找出問題所在）。
我現在使用的縮圖函式（已修正）如下：
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);
}有人建議可以使用這個函式來擷取儲存在檔案中的影像的交錯位元。但事實並非如此。
雖然在傳入有效的影像資源時，imageinterlace() 會回傳 0 或 1，但如果傳入的是檔案名稱字串，則會產生 PHP 警告，且回傳值既不是 0 也不是 1。dr_snapid 的評論「伺服器會傳送每第 N 行」並不完全正確。網路伺服器不需要知道它正在傳送的檔案內容；它的工作只是傳送資料。確切地說，影像是以「每第 N 行」的資料出現在檔案開頭的方式建立的，隨著瀏覽器接收到的檔案內容越多，細節也越完整。在 PHP 中，資料可能是動態生成的，而不是從檔案中提取的，但這並不會改變資料本身不同的這個事實，而不是傳送方式不同。*
事實上，JPEG 並不是「每第 N 行」，而是更像是「每第 N 個像素」，其中 N 會逐漸減小，導致網格隨著接收到的資料越多而變得越精細（因此會出現低解析度影像逐漸變得更清晰）。瀏覽器基本上會估計像素之間的間隙，可能是透過簡單地混合顏色，同時「真實」資料持續到達。這與非漸進式 JPEG 編碼資料的方式截然不同，加上該格式的其他壓縮技術，確實可能會導致檔案大小不同。
*你能想像如果伺服器需要使用不同的演算法傳送不同的檔案類型，而瀏覽器需要能夠接收所有這些檔案類型，網路會變得有多麼容易出錯嗎？如果您需要在 Flash 中載入生成的影像，請將 imageinterlace() 設定為 0。Flash 不支援漸進式 JPEG。這個函式在使用 Ming 時很有用，因為 SWFBitmap 建構函式會使用非交錯的 JPEG 檔案，所以您必須使用 imageinterlace(0);稍微補充一下關於 JPEG 漸進式顯示的原理：JPEG 檔案中並沒有儲存多個低解析度的圖片，唯一改變的是「像素」的排列順序。在 JPEG 中，圖像是以 8x8 像素的區塊來劃分的，因此，它不像逐行掃描像素那樣線性排列，而是先將每個 8x8 區塊中的一個像素放在圖像數據流的開頭。如此一來，當瀏覽器收到所有 8x8 區塊的像素後，就能夠顯示「像素化」的圖像，而隨著收到更多數據，瀏覽器就能夠添加更多像素並使圖像「更清晰」。關於 MichaelSoft 提到的「Imageinterlace($im, 1) 會建立一個在完全載入之前都不顯示任何內容的 JPG 檔案」
事實上，這並非完全正確。
這種情況只會發生在 Internet Explorer（目前所有版本）上，因為它似乎不支援漸進式顯示，而是在圖像 100% 載入完成後才顯示。其他瀏覽器（Mozilla、Mozilla Firefox、Opera、Konqueror 等）則會按照預期的方式運作：先顯示一個非常低解析度的圖像，然後在載入過程中覆蓋一個中低解析度的圖像，接著顯示越來越多的細節。Microsoft Internet Explorer 中存在一個錯誤（至少目前仍然存在），這意味著通常情況下，漸進式/交錯式 JPEG 在載入過程中根本不會顯示，而是在整個圖片載入完成後才會突然出現。一般的非交錯式/非漸進式 JPEG 會在載入時逐行顯示，這反而會讓人覺得它載入得更快。微軟的 IE 瀏覽器在這方面確實搞反了！
這種情況在其他瀏覽器（例如 Mozilla/FireFox）中並不會出現，在這些瀏覽器中，圖像是按照預期漸進式載入的。交錯式顯示並不會儲存另一張圖像，它只是改變了圖像行發送和渲染的順序。伺服器會先發送每隔 N 行的數據，到達檔案結尾後，再回到開頭，讀取中間的行。
每次傳輸後，瀏覽器都會顯示已下載的行，並以相同的顏色填充尚未接收的行，但隨著每次傳輸，需要填充的間隙會越來越小，圖像也會越來越清晰。經過多次傳輸後，每一行都已被讀取，瀏覽器也已完整渲染了圖像。
希望這樣解釋清楚了，這也說明了為什麼檔案大小不應該有任何差異，所以我無法解釋為什麼有些人觀察到檔案大小有所不同。
據我了解，檔案中只有一位元用來表示圖像是否為交錯式，如果設定為 1，伺服器和客戶端（瀏覽器）的處理方式就會不同。