這個工具會回傳一個具代表性的 HEX 色碼,它是透過對每個取樣像素進行「以 alpha 為權重的算術平均」所產生,而不是計算哪個像素出現次數最多。其平均公式很直接:對於每個 alpha 不為零的取樣像素,紅、綠、藍三個通道會各自乘上該像素的 alpha 值,接著把各通道的加權總和除以 alpha 的總和,最後每個通道各自四捨五入到最接近的整數,範圍落在 0 到 255 之間。完全透明的像素會從加總中被剔除,因為其儲存的 RGB 通道不可見,可能帶有任意的編碼器資料;部分透明的像素則會依其不透明度按比例貢獻。最終結果是一個六位數小寫 HEX 與對應的十進位 RGB,整個計算過程完全在當前的瀏覽器分頁中執行。因為這是算術運算而非基於頻率的方法,所以兩個權重相同的紅色與藍色像素會平均出紫色,即使原始影像中根本沒有紫色像素;同樣地,一個微小的明亮重點色也會被大片中性背景稀釋掉。
影像中最常出現的顏色是如何定義的
大多數搜尋「most common color in image」的使用者,實際上想要的是下列三種相關需求之一:真正出現次數最多的像素值、一個可以直接貼到 CSS 的單一代表 HEX,或是一個可以和其他素材比較的色調摘要。這三種需求各自對應三種不同的答案。計算像素數量會得到一個直方圖峰值,這才是真正的主導色結果;平均所有可見像素會得到一個經過加權的 RGB 值,能平滑掉個別像素的雜訊;主體感知的擷取則會先分離出前景物體再進行取樣,完全是第三條不同的路線。
第一個答案是大多數人字面上所指的「最常出現」;第二個答案 — 平均 — 是瀏覽器和許多影像工具能夠在不進行分群或分割的情況下,一次就產生出來的結果,這也是平均類型的工具在設計工作流程中常見的原因;第三個答案則需要物件偵測,這超出「單一數值工具」的範圍。一個快速的經驗法則:當影像以相當均勻的色調為主、僅有少數明亮重點時,算術平均會很接近直方圖峰值;當影像是忙碌的拼貼、有好幾塊面積不一樣大的強烈區域時,平均值會偏向最大的中性區域,而主導色則取決於你計算的是哪一個區域。
Image Average Color Finder 如何產生單一 HEX
Image Average Color Finder 在設計上就是專門處理「平均」這個情境。它接受 PNG、JPEG、WebP、GIF、BMP 或 AVIF 檔案,在你的瀏覽器中本機解碼影像,對解碼後的點陣圖進行取樣,並回傳單一以 alpha 為權重的算術平均值,輸出一個六位數 HEX 與對應的十進位 RGB 數值。整個流程 — 解碼、取樣、平均、複製到剪貼簿 — 都在當前分頁中執行。該檔案及其取樣像素不會上傳到 Lizely 或任何影像分析服務,原始檔案也絕不會被修改或匯出。
權重的規則是有文件紀錄且刻意設計的。對於每個 alpha 不為零的取樣像素,紅、綠、藍三個通道會各自乘上 alpha 值,加權後的總和會除以整個取樣的 alpha 總和,每個通道再四捨五入到最接近的整數,範圍 0 到 255。完全透明的像素不會貢獻任何數值,因為其儲存的通道不可見,可能含有任意的編碼器資料;部分透明的像素則會依其不透明度按比例貢獻。介面會回報 alpha 覆蓋率 — 也就是取樣的 alpha 總和除以該取樣的最大可能 alpha — 讓你一眼就能判斷某個偏低的數值是否因為透明圖層而被拉低。
實作方式是使用 MDN CanvasRenderingContext2D.getImageData 參考文件中所描述的標準瀏覽器 canvas 像素介面,以及相關的 WHATWG HTML canvas 像素處理規格。Canvas 像素存取以標準的 8 位元 RGBA 資料形式取得,該工具既不會保留也不會檢查 EXIF、ICC 設定檔、相機中繼資料、超出顯示用途的檔名,或隱藏的文字區塊。預覽色塊會直接使用計算出來的 HEX,這對快速檢查很有用,但結果仍會受到你的顯示器、瀏覽器、周圍主題,以及人眼在相鄰色彩下的視覺適應所影響。
從任何影像取得平均 HEX
只要你準備好來源檔案,完成整個任務只需要幾次點擊。步驟順序很重要,因為每一步都依賴前一步 — 本機解碼必須先完成,任何 HEX 數值才可信;而複製到剪貼簿的步驟,則預設已經有結果顯示出來。
- 開啟 Image Average Color Finder,選擇一個支援的 PNG、JPEG、WebP、GIF、BMP 或 AVIF 檔案,大小上限為 20 MB。
- 等待檔案在本機完成解碼,然後在結果面板中讀取 HEX、十進位 RGB、alpha 覆蓋率,以及來源與取樣的尺寸。
- 點擊顯示的 HEX 數值來複製它。如果你的瀏覽器阻擋剪貼簿存取,該數值仍會保持可見且可選取 — 請改為手動選取並複製。
- 將 HEX 貼到你的設計環境(CSS 變數、主題 token、元件 prop、行銷簡報),並對照其真實的使用情境來檢視色塊,而不要單獨相信這個數字。
如果結果看起來不對,最常見的原因是影像中有一大片低飽和度的區域主導了平均值。將來源影像縮限到你關心的主體 — 例如裁切到物件本身、移除厚重浮水印,或只取樣較小的範圍 — 通常會讓 HEX 更接近你肉眼所認為的主導色。這個工具只能看到你餵給它的像素,所以餵給它更精準的裁切結果,就是改變答案最乾淨的做法。
平均 vs. 調色盤:哪一種符合你的需求
當你想要一個數值來概括整個檔案時,平均是很好的選擇;當你需要看出檔案的色彩範圍時,調色盤才是對的工具。下表整理了取捨,讓你在上傳前就能選定方向。
| 使用情境 | 單一平均 HEX | 多重色塊的調色盤 |
|---|---|---|
| 為英雄區塊佔位元素做粗略的背景配對 | 一行 CSS、一個顏色 | 對單一背景色來說殺雞用牛刀 |
| 為設計素材清單做縮圖摘要 | 一個 HEX 足以作為網格標籤 | 當摘要卡片有多個區塊時很有用 |
| 從參考照片建立適合品牌的調色盤 | 除了平均值以外,其他顏色全部錯失 | 呈現來源中實際的色彩分布 |
| 依頻率排序的「最常出現像素」 | 回傳的是算術平均值,不是峰值 | 依頻率回傳排序後的色塊 |
| 主體感知擷取(僅前景) | 無法自行分離出主體 | 仍須依賴分群或遮罩 |
當問題真的是「哪一個像素出現次數最多」時,平均值會偏離峰值,你應該改用分群工具。Color Palette Generator 是 Lizely 中相關的選項,它能從基準色產生出依頻率排序的色塊;當你手上已經有至少一個來自平均值的錨定 HEX 時,這個工具搭配起來特別好用。
限制、降取樣與邊界情況
這個工具內建嚴格的輸入防護機制,而這些機制有其存在的理由。選擇的檔案必須非空、使用瀏覽器支援的影像 MIME 類型,且大小不超過 20 MB。解碼後,任一邊的長度不得超過 20,000 像素,總像素數不得超過 4,000 萬像素。這些限制是為了避免小型壓縮檔在解碼時膨脹成數 GB 大小的 canvas。如果你的來源觸發了這些檢查中的任何一項,結果面板會顯示明確的錯誤,並不會回報任何過時的數值。
解碼後的大型影像在分析前會進行降取樣。總像素數在 1,048,576 以下的影像會以其解碼後的尺寸讀取;超過這個數量的影像則會按比例縮放,使分析 canvas 維持在該像素預算內。因此,結果描述的是一個高解析度的取樣,而非對每個來源像素做逐位元組的平均,瀏覽器的內插運算可能會讓數值與離線的全解析度計算略有差異。介面會同時回報來源與取樣的尺寸,讓近似之處透明可見,而不是被隱藏起來。
動畫格式適用相同的規則,但有一個額外注意事項。該工具會評估瀏覽器完成初始影像解碼時所暴露的那一幀;它不會對所有幀取平均,也不會計入幀的持續時間。瀏覽器的色彩管理、方向處理、寬色域轉換,以及動畫行為,也可能因格式與瀏覽器不同而有所差異。透明圖層會以可預期的方式改變結果:在不透明主體外圍的大片透明邊框,由於完全透明的像素會從計算中被剔除,因此不會對平均值產生任何貢獻。在上傳前裁切到可見主體,或先將透明區域壓平,單純只是縮窄哪些不透明像素會進入取樣範圍。
超越單一 HEX:拿到數值後的下一步
在真正的設計工作上,單一 HEX 很少是最終答案。把平均出來的 HEX 當作起點,然後用兩個相關問題來檢驗它。如果這個色塊會放在文字背後,請把這組配色丟到 Color Contrast Checker 跑一次,確認它在你的內文或標題字級下通過 WCAG AA,而不是靠 RGB 數字感覺差不多就通過。如果這個色塊需要對應既有的 UI 元件、品牌色票,或印刷打樣,請改用 Color Difference Calculator 取得 CIEDE2000 指標,而不是用肉眼判斷十六進位的接近程度。
把任何單一數值視為快速參考,而非保證。瀏覽器的色彩描述檔、螢幕校準,以及人眼的視覺適應,都會讓同一個 HEX 在不同顏色旁邊看起來不一樣;所以從照片平均出來的 HEX,幾乎不可能與油漆色卡、布料色樣,或印刷打樣一對一完全對應,除非經過進一步校準。這正是單一數值摘要工具預設的邊界:它提供給你的是一個站得住腳的代表值,而非感知上的同一性。
想深入了解,可參閱 如何在不使用 Photoshop 的情況下取得影像的平均顏色。
想深入了解,可參閱 如何在本地端找出影像的顏色數值。