影像的平均色彩是一個六位數的十六進位（HEX）值，產生方式是將每個取樣的非透明像素的紅、綠、藍三個通道以 alpha 值加權後加總，再將各通道的總和除以取樣的 alpha 總和。這個結果是可見色彩的算術平均數，而非主色分群的模型，因此兩個等權重的紅色與藍色像素會產生一個紫色的 HEX 值，即使來源影像中根本沒有紫色存在。整個計算都在當前的瀏覽器分頁中本地執行——檔案、畫布取樣以及複製的 HEX 值全都保留在本機。取樣數量有上限以維持運算量在合理範圍，但同樣地，一個小而鮮豔的點綴色也可能被大面積的中性背景稀釋。你會收到四個數值：一個 HEX 字串、一組十進位 RGB 三元組、一個 alpha 覆蓋率百分比，以及原始來源尺寸與畫布取樣尺寸。最後這一對數字很重要，因為對於解碼後像素數超過 1,048,576 的檔案，影像平均色彩查詢工具會在取平均之前依照該像素預算等比例縮小影像，因此這個數字描述的是高解析度的取樣結果，而非每個來源像素逐位元組的平均。
平均色彩是如何從你的像素計算出來的
這個加權規則相當簡單，可以手寫出來。對於每個 alpha 值大於零的取樣像素，工具會將該像素的紅色值乘以其 alpha，再將綠色值乘以其 alpha，然後將藍色值乘以其 alpha。它會在整個取樣範圍內加總這些加權後的通道值，再將各通道的總和除以取樣的 alpha 總和。三個商數會在最後一次性四捨五入為 0 到 255 之間的整數，組合成一個六位數的小寫 HEX 字串，並與原始的十進位 RGB 三元組一同顯示。CanvasRenderingContext2D.getImageData 的 MDN 參考文件說明了提供這些畫布數值的 RGBA 像素介面，而 HTML canvas 的像素處理規範則是這個實作所遵循的底層合約。
這個規則直接衍生出兩個實作上的選擇。首先，完全透明的像素不會有任何貢獻，因為它們儲存的 RGB 通道在技術上是不可見的，且可能包含任意的編碼器資料——將它們納入平均會引入雜訊。其次，部分透明的像素會依照其不透明度比例貢獻，這表示在白色背景上的半透明紅色疊加層會將 HEX 拉向粉紅色，而不是回報底層的紅色。所回報的 alpha 覆蓋率是取樣的 alpha 總和除以取樣範圍中最大可能的 alpha 總和，以百分比表示，因此完全不透明的影像會顯示為 100%，而具有大片透明區域的影像則會明顯低於此數值。
用三個步驟使用影像平均色彩
這個工作流程很短，因為每個階段都在瀏覽器中執行。沒有上傳、沒有帳號，也沒有往返伺服器的檢查。
- 選擇一個大小不超過 20 MB 的支援影像格式。支援 PNG、JPEG、WebP、GIF、BMP 以及 AVIF。非影像檔案、空檔案或超過 20 MB 上限的檔案會在任何取樣發生之前被拒絕。
- 等待本地解碼並檢視 HEX、RGB、覆蓋率以及取樣尺寸。工具會解碼檔案、視需要將其縮小至畫布預算、逐一走訪像素網格，然後一次顯示所有四個數值。如果來源與取樣尺寸不同，代表縮小處理在此發生。
- 點擊 HEX 值以複製它，然後在預期的設計情境中驗證色塊。剪貼簿收到的內容正好是一個井字號後接六個小寫的十六進位數字。將該值貼到 CSS、設計 token 或腳本中，並在實際呈現的周圍版面、佈景主題或背景中檢查色塊。
解讀 HEX、RGB、覆蓋率以及尺寸
結果面板始終顯示四項資訊，將它們視為一個整體來解讀是最安全的方式。
| 輸出 | 它是什麼 | 需要注意的事項 |
|---|---|---|
| HEX | 以 # 開頭的六個小寫十六進位數字 | CSS 和設計 token 的複製貼上目標；格式嚴格為 #rrggbb |
| RGB | 範圍在 0–255 的十進位紅、綠、藍整數 | 以數值形式表示的同一個顏色，供程式碼與腳本使用 |
| Alpha 覆蓋率 | 取樣 alpha 總和除以最大可能 alpha，以百分比表示 | 當透明像素被略過時會下降；代表實際對平均有所貢獻的影像比例 |
| 來源與取樣尺寸 | 原始檔案的解碼大小以及實際進行平均的畫布大小 | 如果兩對數字不同，該數值反映的是縮小後的取樣，而非完整解析度的影像 |
一張平坦且不透明的照片牆壁會產生一組 HEX、RGB、近乎 100% 的覆蓋率，以及與取樣尺寸相同的來源尺寸。在柔和漸層疊加下的透明背景 logo 則可能會產生一個令你意外的 HEX，以及明顯低於 100% 的覆蓋率數字——這個落差正是加權規則確實在發揮作用、而非對每個像素等權平均的訊號。
Alpha 覆蓋率如何影響你所得到的 HEX
Alpha 覆蓋率是 HEX 的沉默夥伴。兩張不同的影像可能產生相同的六位數 HEX，但覆蓋率數值卻相差甚遠。一個角落透明、其餘完全不透明的平坦 PNG 會回報接近 100% 的覆蓋率，以及幾乎完全由不透明區域主導的 RGB。同樣的構圖，如果整個畫布套上 30% alpha 的漸層，則會回報較低的覆蓋率，以及一個被拉向半透明像素背後內容的 HEX——因為工具讀取的是畫布上可見的 RGBA，而非底下的圖層。
如果你想驗證某個特定像素是否被納入平均，透明像素如何影響影像平均色彩計算這篇說明文章會用具體範例逐步說明加權規則，並展示當你以不同 alpha 設定重新編碼同一個圖像時會產生什麼變化。覆蓋率百分比也是最快察覺解碼異常的方式：動畫 GIF 與 WebP 影格是以瀏覽器完成初始影像解碼時所顯示的影格來評估，因此以透明為主動畫影格上的覆蓋率看起來可能低於檔案 metadata 所暗示的數值。
瀏覽器在開始取樣前強制執行的限制
在讀取任何像素之前會執行多項輸入防護措施。設立這些限制是為了避免一個小小的壓縮檔案悄悄膨脹成數十億像素的畫布而讓分頁當機。
| 限制項目 | 上限 | 存在的理由 |
|---|---|---|
| 檔案大小 | 最大 20 MB | 在一般瀏覽器記憶體下維持初始載入在合理範圍 |
| 解碼後的邊緣尺寸 | 任一邊不得超過 20,000 px | 防止小型檔案標頭宣稱極大的尺寸 |
| 來源像素數 | 最多 40,000,000 像素 | 捕捉中等尺寸但極端解析度的影像 |
| 畫布取樣預算 | 1,048,576 像素 | 超過此數量的影像會在取平均前等比例縮小 |
| 檔案格式 | PNG、JPEG、WebP、GIF、BMP、AVIF | 僅限瀏覽器可解碼的標準 MIME 類型 |
不支援的資料、解碼失敗、畫布存取被封鎖、無效的尺寸，以及完全沒有可見像素的影像，都會以明確的錯誤訊息呈現，且絕不會顯示先前上傳的過時結果。EXIF、ICC 設定檔、相機 metadata、除了顯示以外的檔名，以及隱藏的文字區塊都不會被檢查或保留——只有解碼後的 RGBA 像素會進入平均計算，且來源檔案絕不會被修改或匯出。
單一 HEX 是正解的時機
這個工具刻意只產生一個數值。這使它適用於某些任務，卻也是其他情境下的錯誤選擇。
| 情境 | 為何有效 | 改用其他工具 |
|---|---|---|
| 粗略的背景配對 | 一個 HEX 就足以作為佔位顏色的種子 | 配色產生器以取得完整配色 |
| 影像載入時的佔位樣式 | 單一數字即可驅動快速的 LQIP 式色塊 | — |
| 設計素材庫的縮圖摘要 | 每個素材獲得一個代表性顏色以利分類 | — |
| 檔案之間的快速視覺比較 | 兩個 HEX 值一眼就能比較 | 需要明確指標時改用 色差計算機 |
| 最常出現的顏色、分離的色塊、主體感知擷取 | 算術平均無法提供這些 | 配色產生器 |
| 文字與背景的對比 | 平均背景不等同於均勻背景 | 色彩對比檢查工具 |
算術平均有兩個值得指出的可預期失敗模式。一個小而鮮豔的點綴色在大面積中性背景上會被稀釋——5% 的飽和黃色細條對上 95% 的灰色所產生的 HEX 看起來會比較接近米色而非黃色。兩個等權重的紅色與藍色像素會產生紫色的平均值，即使來源中根本沒有紫色像素存在。如果上述任一種情況符合你正在取樣的素材，配色工作流程會改為回傳最常出現的顏色，並提供一組你真正可以挑選使用的色塊。
為了可重現的設計工作，請記錄輸入檔案、使用的瀏覽器、所顯示的來源與取樣尺寸，以及回傳的數值。不同的程式可能會回傳略有不同的平均值，因為它們可能使用完整解析度的像素、不同的降取樣核心、是否感知 gamma 的運算、不同的動畫影格，或不同的色彩管理。這裡記載的加權規則與限制是刻意的產品設計選擇，而非意外行為，因此將它們與結果一起記錄下來，就是隨時重現該答案的最快方式。