色彩反轉是將影像中每個紅、綠、藍通道值替換為其互補位元組的運算：輸出的紅色等於 255 減去輸入的紅色、輸出的綠色等於 255 減去輸入的綠色、輸出的藍色等於 255 減去輸入的藍色，而 alpha 通道則保持不變。套用至整張圖片時，這個規則對每個像素都是機械化且相同的，因此黑色像素會變成白色、白色像素會變成黑色、純紅色像素會變成純青色、純綠色像素會變成純洋紅色、純藍色像素會變成純黃色。此轉換不需要任何色彩管理轉換、伽馬線性化，或感知性的互補色彩模型 —— 它是對瀏覽器透過 Canvas 元素所公開的解碼 RGBA 矩陣進行的直接位元組運算。這個簡單的定義正是 反轉影像顏色 工具所執行的內容：選擇一張 PNG、JPEG、GIF 或 WebP，等待檔案透過其實際位元組與真實的瀏覽器解碼進行驗證，然後匯出一張靜態 PNG，其中每個 RGB 欄位都已替換為 255 減去其原始值，而 alpha 則保持不變。整個流程 —— 檔案讀取、位元組偵測、解碼、像素存取、轉換、預覽，以及 PNG 匯出 —— 都在當前的瀏覽器分頁中執行，因此原始影像永遠不會被傳送到外部伺服器。
反轉顏色實際上對像素做了什麼
瀏覽器解碼到 ImageData 緩衝區中的每個像素都帶有四個位元組通道：紅、綠、藍，以及 alpha。這個反轉規則忽略這些數字作為顏色的意義，並將其視為 0–255 的整數。對於每個像素，工具會獨立地計算三個新的顏色通道：
- 輸出紅色 = 255 − 輸入紅色
- 輸出綠色 = 255 − 輸入綠色
- 輸出藍色 = 255 − 輸入藍色
- 輸出 alpha = 輸入 alpha (保持不變)
因為每個通道都是獨立反轉的，所以結果就是您從數學定義中所預期的攝影負片效果。RGB(120, 50, 200) 的像素會變成 RGB(135, 205, 55)。RGB(0, 128, 255) 的像素會變成 RGB(255, 127, 0)。對同一個規則套用兩次會還原為原始的位元組，因為對於任何 0–255 的值，255 − (255 − x) 等於 x。
值得將這個位元組通道規則與它所「不是」的兩件事區分開來。它不是色彩管理的轉換，因此不會線性化伽馬，也不會模擬 sRGB 轉換曲線。它也不是底片負片的修復，因此不會移除橘色遮罩、不會校正掃描負片、不會調整曝光，也不會執行色調分級。如果你需要上述功能，那麼原始照片編輯器或具備色彩管理的工具才是正確的選擇。
| 輸入 RGB | 輸出 RGB | 視覺上的變化 |
|---|---|---|
| 0, 0, 0 (黑) | 255, 255, 255 (白) | 最暗的像素變成最亮 |
| 255, 255, 255 (白) | 0, 0, 0 (黑) | 最亮的像素變成最暗 |
| 255, 0, 0 (紅) | 0, 255, 255 (青) | 純紅色與其互補色交換 |
| 0, 255, 0 (綠) | 255, 0, 255 (洋紅) | 純綠色與其互補色交換 |
| 0, 0, 255 (藍) | 255, 255, 0 (黃) | 純藍色與其互補色交換 |
| 120, 50, 200 | 135, 205, 55 | 每個通道獨立翻轉 |
接受的檔案格式與驗證器檢查的內容
此工具接受四種容器格式：PNG、JPEG、GIF，以及 WebP。它不會信任副檔名、檔案選擇器的篩選條件，或作業系統的 MIME 標籤，因為這三者都可能造假。相反地，工具會檢查實際的 ArrayBuffer，並套用與成對的 Base64 影像工作流程所使用的相同純結構偵測器。如果位元組模式不符合完整的支援容器，則會在任何 Canvas 處理開始之前拒絕該檔案。
結構規則是明確的。PNG 必須包含完整的 8 位元組簽章、第一個 IHDR 結構，以及結尾的 IEND。JPEG 必須包含 SOI 標記、接續的標記，以及結尾的 EOI。GIF 必須以 GIF87a 或 GIF89a 開頭、帶有足夠的邏輯螢幕結構，並以結尾位元組作結。WebP 必須帶有精確的 RIFF 位元組計數、WEBP 標記，以及一個有界的 VP8、VP8L 或 VP8X 第一個區塊。截斷的魔術位元組以及被重新命名的任意檔案會在 Canvas 處理開始之前就失敗。
在結構偵測之後，偵測到的 MIME 會用於建構 Blob。該 Blob 接著必須透過 createImageBitmap 進行解碼，並回報實際的正向尺寸 —— 結構偵測無法取代瀏覽器的解碼。即使副檔名已被更改為受支援的副檔名，這四種格式之外的檔案 —— SVG、AVIF、HEIC、BMP、TIFF、PDF 等 —— 皆不在處理範圍內。
如何反轉影像的顏色
完整的工作流程包含三個已確認的階段。每一個階段都必須在下一個階段開始之前完成，重新選擇檔案會重置之前所有的結果。
- 選擇一張 PNG、JPEG、GIF 或 WebP 檔案，並等待位元組容器偵測、透過 createImageBitmap 進行的瀏覽器解碼，以及尺寸驗證。如果其中任何一項檢查失敗，檔案會在工具顯示預覽之前被拒絕。
- 反轉已解碼的第一幀。工具會從以原始尺寸繪製的 Canvas 讀取完整的 ImageData，將每個像素變更為 255 − R、255 − G、255 − B (alpha 保持不變)，然後將完整的矩陣放回。接著會以原始尺寸並排顯示來源預覽與反轉後的預覽，以便直接進行比較。
- 確認尺寸與輸出的位元組大小，然後下載靜態 PNG。匯出的內容是從完整原始尺寸的影像進行編碼，絕不會裁剪或重新取樣，且無論輸入格式為何，匯出的檔案始終為完整的 PNG。
選擇另一個檔案會立即遞增一個工作世代，關閉先前的 ImageBitmap，撤銷來源與輸出兩者的 ObjectURL，清除所有舊有的錯誤與結果，並重置忙碌狀態。來自先前作業的延遲檔案讀取、位元圖解碼，以及 toBlob 回呼，皆無法發布至較新的選擇中。即使在 React Strict Mode 的 effect 設定與清除循環中，清理作業也能保持安全。
Canvas 匯出步驟會使用瀏覽器透過 toBlob 方法所提供的原生 PNG 編碼器，如 MDN HTMLCanvasElement.toBlob 參考文件 中所述。null Blob、無效的大小，或超出精確 32 MiB 輸出預算的 Blob，皆會在結果 URL 發布之前失敗。
檔案大小與尺寸限制
此工具在開始處理之前會強制執行三項獨立的限制，且這三者必須同時滿足。壓縮的輸入可能會展開成大型的像素緩衝區，而細長的長形影像雖然可能低於面積限制，但仍可能超出實際可用的 Canvas 尺寸，因此這些限制會分開檢查，而不是從彼此衍生而來。
| 限制 | 數值 | 存在的原因 |
|---|---|---|
| 輸入檔案大小 | 15 MiB | 報告的檔案大小會在讀取之前進行檢查，然後實際的 ArrayBuffer 長度會在讀取之後再次進行檢查。 |
| 最大邊長 | 每邊 8,192 像素 | 即使記憶體允許更大的緩衝區，瀏覽器的 Canvas 仍有實際的大小限制。 |
| 最大面積 | 24,000,000 像素 | 細長的長形影像雖然可能低於邊長限制，但仍可能超出可用的 Canvas 尺寸。 |
| 輸出 PNG 大小 | 32 MiB | 輸出預算與輸入分開，因為 PNG 是未壓縮的，嘈雜的來源可能會產生更大的結果。 |
接受精確的邊界值。超過限制的一個位元組、一個邊長像素，或一個面積像素都會被拒絕。低於這些限制但從不支援的容器重新命名的檔案仍會在結構檢查中失敗，因此這些限制並不能取代位元組偵測器。不會靜默地進行任何縮放、裁剪、取樣或部分處理。
輸出的 PNG 保留了什麼、捨棄了什麼
輸出永遠會是完整的、全解析度的 PNG，而不會是其他東西。動畫、元資料，以及來源檔案的附加資料皆會被捨棄，因此輸出並不是輸入的逐位元組精確複本。
- 已解碼的 RGB 值會被替換為位元組層級的互補值。
- 每個像素的 Alpha 都會保持不變。
- 原始的像素尺寸會被保留 —— 絕不會套用任何縮放、裁剪或重新取樣。
- 檔案格式永遠是 PNG，與輸入格式無關。
- EXIF、GPS、ICC 設定檔、註解，以及其他元資料不會透過 Canvas 匯出加以保留。
- 動畫 GIF 與動畫 WebP 輸入會變成一張靜態 PNG。後續的幀、計時、迴圈、調色盤，以及銷毀行為皆不會被保留。
- 不會保證保留零 alpha 下的隱藏 RGB。工具會反轉 Canvas 實際提供的內容，但瀏覽器的解碼器或 Canvas 可能會在 getImageData 回傳之前對視覺上隱藏的 RGB 進行正規化，因此工具無法還原從未到達 ImageData 的來源位元組。
如果你將來源檔案與輸出檔案一同保留，則除了反轉後的靜態 PNG 之外，你還擁有開始時所擁有的一切。即使已解碼的 RGBA 轉換本身是精確的，PNG 轉換仍可能會改變元資料、動畫，以及色彩管理的行為，因此當上述任何一項特性很重要時，原始檔案才是可以作為備援的檔案。
什麼時候顏色反轉不是合適的工具
位元組通道反轉是一種特定的視覺效果，有許多任務是它無法執行的。它不會線性化伽馬，因此具有相同 RGB 位元組的 sRGB 照片與線性影像在反轉後看起來不會相同。它不會模擬感知性的互補顏色，因此想要更柔和或更溫暖的反轉效果的設計師將需要使用具備色彩管理的編輯器。它不會移除橘色的底片遮罩、不會校正掃描負片、不會調整曝光，也不會執行色調分級 —— 這些操作需要原始照片或具備色彩管理的工具。
如果你需要在輸出中保留動畫、嵌入的 ICC 設定檔、EXIF 元資料、GPS 資料，或其他來源檔案的附加資料，那麼它同樣不是正確的選擇。對於這些情況，請保留原始檔案，並在能夠以原始格式及完整原始元資料寫入複本的工具中執行反轉。
對於其他在本機進行的像素層級效果，Lizely 也提供了 影像翻轉工具 用於鏡像翻轉、影像馬賽克工具 用於對影像的部分區域進行遮罩，以及 影像模糊工具 用於選擇性的柔化處理，所有這些工具皆在同一個瀏覽器流程中執行，因此檔案永遠不會被上傳。成功的解碼並不是惡意程式分析、內容審核、作者身分驗證，或證明影像安全或真實的依據 —— 請選擇與實際工作相符的工具。
如果你正在權衡各種選項，如何在不上傳影像的情況下將影像放入 PDF 對此進行了詳細的說明。
如果你正在權衡各種選項，在 Figma 中反轉影像顏色：本機瀏覽器方法 對此進行了詳細的說明。