每個現代 Paint 風格的色彩反轉功能，都是將每個紅、綠、藍色通道以 255 減去原始位元組的方式取代，保留 alpha 通道不動。Paint 的指令正是圍繞著這個運算而設計，所有認真的瀏覽器複製版本也是如此，包括 Invert Image Colors——這兩個工具都遵循「輸出紅色等於 255 減去輸入紅色、輸出綠色等於 255 減去輸入綠色、輸出藍色等於 255 減去輸入藍色」的規則，套用於每個解碼後存留下來的像素。這個簡單的相減運算會產生照片負片的效果：黑色變成白色、白色變成黑色、紅色變成青色、綠色變成洋紅色、藍色變成黃色。由於規則是確定性的，連續套用兩次必定會還原回原本的位元組。Paint 與一個仔細打造的瀏覽器工具之間，仍存在幾項細微差異——選取行為、輸出格式、動畫處理、中繼資料，以及你的影像是否曾離開過本機——在選擇工作流程之前，這些都值得先了解清楚。
像素層級的「反轉色彩」是什麼意思
「反轉」這個詞聽起來很戲劇化，但這個運算其實只是每個通道一行算術。對於解碼後影像中的每個像素，工具會計算新的紅色值為 255 減去舊的紅色值、新的綠色值為 255 減去舊的綠色值、新的藍色值為 255 減去舊的藍色值。控制透明度的 alpha 值則原封不動地複製過去。由於每個通道都是獨立的，這條規則可以從單一像素的色塊一路擴展到數百萬像素的照片，完全不需要參考相鄰像素。
透過一個具體的例子就能讓規則變得明確。假設有一個像素，其來源 RGB 三元組為 (128, 64, 200)，完全不透明。輸出紅色為 255 − 128 = 127。輸出綠色為 255 − 64 = 191。輸出藍色為 255 − 200 = 55。結果為 (127, 191, 55)，這是一種柔和的橄欖色調，正好是輸入的 RGB 互補色。對 (127, 191, 55) 再執行一次相同公式，就會還原為 (128, 64, 200)，這也是為何「雙重反轉」會成為任何反轉實作的標準健全性檢查。
當 alpha 通道不是 255 時，RGB 部分仍適用這條規則，但實際看到的顏色會取決於像素下方的內容。在白色頁面上的一個 50% 透明紅色，反轉後看起來不會像 50% 透明的青色；它看起來會像 50% 透明的青色與同樣的白色背景混在一起。這種混色是正常現象，也正是 Paint 實際產生的結果。
在 Microsoft Paint 中執行（經典方法）
Paint 內建一鍵反轉功能，運作原理也是上述的逐通道規則。整個工作流程很短，但關於選取行為與檔案格式的幾項細節，對於真正取得你想要的結果很重要。
- 在 Microsoft Paint 中開啟你的影像。使用檔案 > 開啟，或將檔案拖曳到 Paint 視窗中。
- 決定要反轉整個畫布還是僅反轉部分區域。在沒有選取任何項目的情況下，反轉色彩指令會影響畫布上的每個像素。如果你只想處理某個區域，請選擇選取工具、畫一個矩形，或在套用指令前按 Ctrl+A 選取全部。
- 套用反轉。點選影像 > 反轉色彩，或使用鍵盤快速鍵 Ctrl+Shift+I。選取虛線框會維持在原位；只有其下方的像素會改變。
- 儲存檔案。使用檔案 > 儲存來覆寫原始檔案，或使用檔案 > 另存新檔來選擇新格式。JPEG 輸出為有損壓縮，因此無論是否進行反轉，將 JPEG 重新存回 Paint 都會進一步降低品質。
有兩項 Paint 的行為很容易被忽略。第一，不規則與矩形選取只會反轉所包圍的像素，因此若需要不規則輪廓，必須使用不規則選取工具並畫出封閉路徑。第二，Paint 不會保留 EXIF 中繼資料、ICC 色彩描述檔或動畫：匯入 Paint 的多格 GIF 會被攤平為第一格，而 JPEG 一旦經過 Paint 重新編碼，就會失去大部分的拍攝中繼資料。如果上述任何細節對你很重要，就有理由考慮 Paint 以外的方案。
瀏覽器工具在這項工作上勝過 Paint 的時機
Paint 雖然方便，但同樣的逐像素規則可以在瀏覽器分頁中執行，無需安裝、無需上傳，並產生無損的 PNG 輸出。Resizing an Image in Paint? Try Your Browser Instead 這篇文章說明了將常見的 Paint 工作搬遷到本機瀏覽器工具的整體模式，而反轉色彩的情境也適用同樣的論點：瀏覽器工具可以讀取位元組、加以解碼、執行公式，然後交還一個 PNG，全程不需要將你的檔案送到伺服器。
隱私是改用瀏覽器工具的首要理由。How to Invert Colours on an Image Without Uploading It 用白話說明了其中的差異：本機工具會將讀取、解碼、轉換與編碼全部保留在當前分頁內，而一般常見的「免費反轉工具」則會將原始檔案上傳到遠端服務。對於個人照片、掃描文件，或任何含有嵌入中繼資料的檔案，本機處理路徑在建構上就更安全。
檔案處理是第二個理由。Paint 在處理極大的影像時會遇到困難，並會將任何動畫輸入攤平為第一格。一個具有明確位元組預算與每邊像素上限的瀏覽器工具，可以在你嘗試處理太大檔案時顯示清楚的「檔案過大」訊息，而不是讓畫布卡住；同時也能在反轉過程中保留 alpha，使透明 PNG 能正確地完整往返。無損的 PNG 輸出也避免了 Paint 在重新儲存照片時造成的第二代 JPEG 品質劣化。
在瀏覽器中逐步反轉影像
Invert Image Colors 工具使用與 Paint 相同的「255 減通道值」規則，但所有運算都在本機進行，並回傳一張靜態 PNG。整個互動流程由三個操作步驟構成。
- 選擇一個 PNG、JPEG、GIF 或 WebP 檔案，並等待位元組容器偵測、瀏覽器解碼與尺寸驗證。工具會檢查實際的檔案位元組——而不是檔名或所提供的 MIME 類型——並要求在開始任何像素處理之前完成真正的瀏覽器解碼。
- 反轉已解碼的初始影格，然後比較來源與完整的原尺寸 PNG 預覽。每個透過 Canvas 暴露的像素都會經過 255 − R、255 − G、255 − B 的轉換，alpha 則原封不動地複製；因此透明像素會保留其透明度，完全不透明的像素則保留其形狀。
- 確認尺寸與輸出位元組大小，然後下載靜態 PNG。匯出的永遠是完整的 PNG；不會產生截斷或有損的替代方案；任何超出獨立 PNG 位元組預算的輸出，會在下載連結顯示之前被拒絕。
在執行中途選擇不同的檔案會遞增工作世代，關閉前一個 ImageBitmap，並撤銷舊的預覽 URL，因此過期的下載內容絕不會洩漏到新的選取結果。整個迴圈已針對 React Strict Mode 的雙重 effect 週期以及 null 的 toBlob 回呼進行防護，這也是「確認尺寸並下載」步驟在第一次嘗試就能可靠執行的實務原因。
色彩對應參考表
下表列出常見的輸入色彩，及其經過一次反轉後精確的 RGB 互補色。這些都是公式的確定性輸出，而非取樣值，因此適用於任何遵循「255 減通道值」規則的工具。
| Input color | RGB in | RGB out |
|---|---|---|
| Black | (0, 0, 0) | (255, 255, 255) |
| White | (255, 255, 255) | (0, 0, 0) |
| Red | (255, 0, 0) | (0, 255, 255) |
| Green | (0, 255, 0) | (255, 0, 255) |
| Blue | (0, 0, 255) | (255, 255, 0) |
| Cyan | (0, 255, 255) | (255, 0, 0) |
| Magenta | (255, 0, 255) | (0, 255, 0) |
| Yellow | (255, 255, 0) | (0, 0, 255) |
| 50% gray | (128, 128, 128) | (127, 127, 127) |
請特別注意 50% 灰階那一列。由於 255 減 128 是 127 而非 128，灰階漸層的正中央在反轉後會偏移一個位元組。這種不對稱性對視覺工作無害，是公式本身的已知特性，並非錯誤。
檔案限制、驗證與被捨棄的內容
Invert Image Colors 在逐像素轉換的前、中、後各階段都會套用一連串明確的檢查。這些檢查沒有一個是隱藏的，也沒有一個會靜默地調整大小、裁切或縮放你的影像。具體的硬性限制條列如下。
| Boundary | Value |
|---|---|
| Reported file size (input) | ≤ 15 MiB |
| Actual ArrayBuffer length (input) | ≤ 15 MiB |
| Output PNG byte budget | ≤ 32 MiB (separate from input) |
| Decoded edge length | ≤ 8,192 pixels per side |
| Decoded pixel area | ≤ 24,000,000 pixels total |
輸入與輸出預算刻意分開，因為一張雜訊較多的照片或複雜插畫的 PNG 重新匯出，通常會比原本的 JPEG、GIF 或 WebP 還大。一個檔案若解碼後符合邊長與面積限制，但展開後超過 32 MiB 的 PNG 上限，會在發布下載連結之前被拒絕，並顯示明確的錯誤，而非產生截斷的影像。MDN 參考文件中關於 HTMLCanvasElement.toBlob 的說明，描述了該工具在這項檢查中所依賴的同步匯出行為。
格式偵測採用結構性方式而非依賴檔名。工具會讀取實際的 ArrayBuffer，檢查 PNG 簽章加上 IHDR 加上結尾的 IEND、JPEG 的 SOI 加上後續的標記加上 EOI、GIF87a 或 GIF89a 標頭加上邏輯螢幕結構加上結束符，或精確的 RIFF 位元組計數加上 WEBP 標記加上有界範圍的 VP8、VP8L 或 VP8X 第一個區塊。WebP RIFF container 的 Google 說明文件定義了該位元組配置。從 SVG、AVIF、HEIC、BMP、TIFF 或 PDF 重新命名的檔案，即使副檔名宣稱符合，也會在結構性檢查時失敗，並在任何 Canvas 處理開始之前就被擋下。
部分來源屬性是刻意不被保留的。EXIF、GPS、ICC 色彩描述檔、註解以及其他來源中繼資料，都不會被帶入 PNG 輸出。動畫 GIF 與動畫 WebP 輸入僅使用瀏覽器解碼的初始影格，因此無論來源有多少影格或循環次數，結果都是單一張靜態 PNG。半透明像素會保留其 alpha，但瀏覽器解碼器或 Canvas 可能在迴圈看到之前先行正規化視覺上隱藏的 RGB，因此輸出中完全透明的區域，未必是輸入中完全透明區域的字面互補色。如果上述任何細節對你的檔案很重要，請將原始檔案與反轉後的 PNG 一起保留。