先讀範圍，再決定增強副本能替你做什麼。

做什麼、不做什麼

做什麼

• 在你的瀏覽器內讀取一張圖片（JPEG、PNG、WebP、GIF、BMP；AVIF 視瀏覽器而定）。檔案上限 25 MiB、約 40 百萬像素、每邊不超過 16384 px；超過時會說明原因，不會悄悄縮小。
• 提供 4 組預設與 17 種處理步驟（自動色階、亮度／對比、伽瑪、背景平整、陰影／亮部恢復、CLAHE、白平衡、去除色偏、三種去雜訊、反銳化、輕度去模糊、放大、傾斜微調、裁切、反相）。每個步驟都能開關、調整參數與順序。
• 預覽在長邊最多 1280 px 的縮圖上計算，可取消、有進度；滿意後再「套用到原尺寸」，在背景工作者內重新處理並產生副本。
• 「套用到原尺寸」有進度條，可隨時取消（按「取消處理」或 Esc），取消不會留下任何檔案；若背景工作者在 10 秒內沒有停下來（例如正在編碼輸出檔），頁面會強制中止它，並請你重新選取圖片。輸出超過 100 百萬像素、或預估記憶體超過保護上限時，會說明原因並拒絕執行，不會當機。
• 前後對照（滑桿或並排）、縮放與平移、1:1 像素檢視，以及處理前後的直方圖與統計。
• 輸出 PNG（無損）或 JPEG（有損，可選品質），檔名加上「_增強版」；同時產生 JSON 與 TXT 兩種處理紀錄。可選擇在影像左下角加註兩行文字（預設關閉，會改變像素）。

不做什麼

• 不上傳、不聯網、不使用任何瀏覽器儲存空間（含 cookie）；關閉或重新整理頁面，畫面上的資料就消失。
• 不修改原圖；結果一律另存為新檔。
• 不辨識內容（不做人臉、車牌或文字辨識），不判斷圖片真偽或是否被修改過。
• 不使用機器學習模型，不「生成」細節。所有步驟都是公開、可重算的傳統影像運算。
• 不內建 HEIC 解碼（多數瀏覽器無法解碼）；GIF 或動畫 WebP 只處理首張畫面；不處理 RAW。
• 輸出是重新編碼的新檔：不含原圖的 EXIF、位置資料與色彩描述檔；透明處壓平成白底。

每個步驟在做什麼（白話）

下面依工具內的選單順序排列。每個步驟都附上「代價」：不是只有好處。順序也會影響結果，常見的順序是：先調亮度與色彩，再去雜訊，最後才銳化；要放大時，放大放在去雜訊之後、輕度銳化之前。

四組預設與使用建議

暗部提亮

自動色階→陰影／亮部恢復（陰影 40、亮部 10、範圍 8 ％）→雙邊濾波（半徑 2、容忍度 25）→反銳化（半徑 1.2、強度 50、門檻 2）。適合整體偏暗的照片或截圖。若亮部已經爆白、或暗部只剩雜訊，沒有資訊可救，這組也變不出來。

夜間監視器畫面

中值（半徑 1）→雙邊濾波→去除色偏→自動色階→CLAHE（限制值 1.5、6 塊、套用 40 ％）。先去雜訊再拉開對比，區域對比只套用一部分。限制：暗部雜訊可能被染成紫綠色斑；在下方的合成夜間樣本中，一張兩項分數都提高，另一張 PSNR 提高但 SSIM 略降。

文字截圖放大

放大 ×2（Lanczos3）→反銳化（半徑 1.0、強度 60）。放大不會長出原本沒有的細節；它讓字比較好讀，不讓字比較真。

掃描文件

傾斜微調（預設停用，要自己啟用）→背景平整（範圍 4 ％、拉到白色）→自動色階（各通道）→雙邊濾波（容忍度 20）→反銳化（強度 70、門檻 2）。頁面歪斜時，用「估計傾斜角」取得建議值，看預覽後再決定。

怎麼調

• 預設只是起點，不是萬用解。請看前後對照與放大後的細節，再決定要不要換掉。
• 一次只改一個參數，並放大到 1:1 像素看邊緣、小字與暗部。出現光暈、塗蠟感、假紋理，就調回來。
• 步驟越少越好。每多一步，就多一份「這是處理出來的」的風險。
• 預覽在縮圖上計算，和原尺寸結果接近但不承諾逐像素相同；要檢查真正的像素，請套用到原尺寸後用 1:1 檢視。

處理紀錄怎麼讀

每次「套用到原尺寸」都會同時產生處理紀錄：JSON（給程式讀，也可以在工具內匯入，還原步驟與參數）與 TXT（給人讀）。

紀錄裡有什麼

• input：原圖檔名、位元組數、類型、SHA-256、尺寸、檔案宣告的最後修改時間（檔案系統的宣告值，可被更改）、EXIF 方向標記（若有）。
• output：副本檔名、位元組數、格式、SHA-256、尺寸、JPEG 品質、pixelsSha256（編碼前 RGBA 像素的雜湊）、是否加註；有加註時另有加註前的像素雜湊與加註內容。
• steps：每個啟用的步驟依序一筆：序號、代碼、名稱、全部參數、由影像算出的值（derived，例如自動色階實際用到的暗端與亮端）、該步驟用時，以及一句該步驟的限制說明（note，例如放大不會增加資訊）。
• sizeChange、processing、stats：尺寸變化、總用時、處理前後的亮度平均、對比與清晰度指標。清晰度指標（拉普拉斯變異數）只是參考，雜訊與壓縮痕跡也會讓它變大。
• tool、createdAt、environment、notes：工具與版本、產生時間（本機時鐘）、瀏覽器識別字串，以及一組固定的提醒。

它能證明什麼、不能證明什麼

• 能說明：這份副本由哪一份原圖（以 SHA-256 指認）、經過哪些步驟與參數得到。
• 不能證明：原圖內容真實、紀錄沒有被改寫、處理的時間與紀錄所寫一致。紀錄是普通文字檔。要讓它有分量，請在產生後立刻用證據鏈帳本計算原圖、副本與紀錄的雜湊，並把封存碼交給第三方保存。

如何自行驗證

先核對雜湊

• 用作業系統的 sha256sum（或 shasum -a 256、certutil -hashfile）對原圖與副本計算，和處理紀錄中的 input.sha256、output.sha256 比對。
• 或用下面的 Python 程式（只用標準函式庫，不依賴本站任何程式）：

import hashlib, json

def sha256_of(path):
    h = hashlib.sha256()
    with open(path, "rb") as f:
        for chunk in iter(lambda: f.read(1 << 20), b""):
            h.update(chunk)
    return h.hexdigest()

ORIGINAL = "範例.png"                  # 你保存的原圖
COPY = "範例_增強版.png"               # 下載的增強副本
LOG = "範例_增強版_處理紀錄.json"      # 下載的處理紀錄（JSON）

log = json.load(open(LOG, encoding="utf-8"))
print("原圖與紀錄相符：", sha256_of(ORIGINAL) == log["input"]["sha256"])
print("副本與紀錄相符：", sha256_of(COPY) == log["output"]["sha256"])

核對副本的像素

• pixelsSha256 是編碼前 RGBA 像素的雜湊。輸出為 PNG 時，解碼後的像素與編碼前相同，可以這樣核對（需要 NumPy 與 Pillow）：

import hashlib, json
import numpy as np
from PIL import Image

COPY = "範例_增強版.png"               # 輸出為 PNG 時才能這樣核對
LOG = "範例_增強版_處理紀錄.json"

log = json.load(open(LOG, encoding="utf-8"))
rgba = np.asarray(Image.open(COPY).convert("RGBA"))      # 高 × 寬 × 4
print("尺寸相符：", [rgba.shape[1], rgba.shape[0]] == [log["output"]["width"], log["output"]["height"]])
print("像素雜湊相符：", hashlib.sha256(rgba.tobytes()).hexdigest() == log["output"]["pixelsSha256"])

輸出為 JPEG 時，解碼結果與編碼前的像素不同，這個核對不適用；JPEG 只能核對檔案雜湊。

用 NumPy 重現一個步驟

• 步驟的公式都寫在上面。以「自動色階（只看亮度）」為例：整數亮度＝（299R＋587G＋114B＋500）÷1000 取整；依累積分布找出暗端與亮端；再用查表把所有通道拉伸。若紀錄中只有這一個步驟，下面的程式最後一行應印出「相差： 0」：

import json
import numpy as np
from PIL import Image

ORIGINAL = "範例.png"                  # 不含透明度的 PNG
COPY = "範例_增強版.png"
LOG = "範例_增強版_處理紀錄.json"      # 只啟用「自動色階」一個步驟、端點依據為「只看亮度」

log = json.load(open(LOG, encoding="utf-8"))
step = log["steps"][0]
assert step["id"] == "levels" and step["params"]["mode"] == "luma" and len(log["steps"]) == 1
p = step["params"]

src = np.asarray(Image.open(ORIGINAL).convert("RGB")).astype(np.int64)
out = np.asarray(Image.open(COPY).convert("RGB")).astype(np.int64)

luma = (299 * src[..., 0] + 587 * src[..., 1] + 114 * src[..., 2] + 500) // 1000   # 整數亮度
hist = np.bincount(luma.ravel(), minlength=256)

def percentile_index(h, n, q):                 # 最小的 v，使累積數 >= n*q/100
    c = np.cumsum(h)
    return int(np.argmax((c >= n * q / 100) & (c > 0)))

lo = percentile_index(hist, luma.size, p["low"])
hi = percentile_index(hist, luma.size, p["high"])
v = np.arange(256)
lut = np.floor(np.clip((v - lo) * 255 / (hi - lo), 0, 255) + 0.5).astype(np.int64) if hi > lo else v
print("暗端、亮端：", lo, hi, "｜ 紀錄中的值：", step.get("derived"))
print("與副本逐點比較，差最多的一點相差：", int(np.abs(lut[src] - out).max()))

• 原圖要用 PNG 且不含透明度。JPEG 在不同解碼器之間可能有差 1 的像素，會使重現結果略有出入；這是解碼器的差異，不是處理步驟的差異。
• 步驟不只一個時，依序重現即可；要核對的是每一步的輸入，不是原圖。

我們如何驗證這些演算法

• 核心函式寫成可在 Node 執行的純函式，並有 574 項單元斷言（本機沙箱的測試，涵蓋正常、邊界、錯誤輸入與極端大小）。
• 另以 NumPy、SciPy、OpenCV、Pillow、scikit-image 做了 356 個交叉比對案例（版本：numpy 2.5.3、scipy 1.18.1、opencv 5.0.0、pillow 12.3.0、scikit-image 0.26.0）。結果如下，誤差越小越一致；這是對合成圖的比對，不代表所有真實圖片都相同。

交叉比對：本機沙箱小樣本。誤差單位為 0 到 255 的灰階（傾斜估計為度）。

項目	對照對象	通過	「應一致」類的實測最差誤差	「解釋或近似」類的實測最差誤差
自動色階、亮度對比、伽瑪、反相、白平衡、去色偏	NumPy 依定義、scikit-image rescale_intensity、OpenCV YCrCb	94／94	1	0.1792
高斯模糊基礎（精確核與方塊近似）	SciPy gaussian_filter、OpenCV GaussianBlur	46／46	4.6e-05	4.402
反銳化遮罩	scikit-image unsharp_mask	12／12	1	—
中值、雙邊、非局部平均	OpenCV medianBlur、bilateralFilter、獨立實作	30／30	1	—
CLAHE 區域對比	OpenCV createCLAHE	19／19	0	—
Lanczos3、雙三次	Pillow resize、獨立實作	42／42	1	16
傾斜微調	Pillow rotate、OpenCV warpAffine、獨立實作	35／35	0	1
輕度去模糊	NumPy／SciPy 獨立實作的 Richardson–Lucy	6／6	1	—
陰影／亮部恢復	NumPy／SciPy 依定義	14／14	0	2
背景平整	NumPy／SciPy 依定義	8／8	1	—
預設流程「掃描文件」	各步驟的獨立參考依序串接	4／4	1	—
平均亮度、標準差、拉普拉斯變異數	NumPy	4／4	7.3e-12	—
投影輪廓法傾斜估計（單位：度）	合成頁面的已知角度	42／42	0.1	—

合計 356 個案例，通過 356，未通過 0。「應一致」是指預期與對照對象相同（容許 ±1 的四捨五入差）；「解釋或近似」是已知有差異、並以模型解釋或量化的案例（例如方塊模糊對真高斯、Pillow 的中介夾制）。

• 已知且已說明的差異：以獨立實作對照發現，Pillow 旋轉的雙三次係數相當於 −1，OpenCV 是 −0.75，本工具採用 −0.5（Catmull–Rom），所以和兩者的結果會略有不同；σ 大於 2 的模糊改用三次方塊模糊近似真高斯（形狀差異以「解釋或近似」類量化）；CLAHE 的內插順序模仿 OpenCV 5.0 的單精度運算；Pillow 縮放時把橫向結果先存成 8 位元並夾在 0 到 255，所以在飽和的銳利邊會和本工具（全程浮點）差到 16 個灰階。
• 環境差異：不同瀏覽器的數學函式與影像編碼器可能有末位差異，所以跨瀏覽器重跑同一組步驟，pixelsSha256 不一定相同，輸出檔的雜湊也不一定相同。

實測：什麼時候有幫助，什麼時候沒有

共 74 組「情境×處理方式」，判讀為：改善 53、有升有降 17、幾乎不變 3、變差 1。判讀規則：PSNR 提高至少 0.5 分貝且 SSIM 提高至少 0.005 為「改善」；兩者都下降到同樣門檻為「變差」；兩者變動都小於門檻為「幾乎不變」；其餘為「有升有降」。

• 有幫助的：偏暗與曝光不足的圖，提亮後兩項分數都明顯提高；掃描件的背景平整；中值濾波對椒鹽雜訊（PSNR 約提高 14 分貝）；輕度高斯模糊加上去模糊或反銳化（PSNR 約提高 0.8 到 2.8 分貝）；傾斜估計在乾淨的合成頁面上誤差在 0.1 度以內。
• 沒有幫助、甚至更差的：低對比圖加上 CLAHE，分數有升有降，一個組合還變差；動態模糊套用「假設高斯」的去模糊，幾乎不變；雙邊濾波與非局部平均對椒鹽雜訊幾乎無效；夜間畫面的預設組合在其中一張圖上 PSNR 提高但 SSIM 略降；單純放大（Lanczos3、雙三次）相對最近鄰放大，分數只改善一點點（×2 時 PSNR 約 0.2 到 0.4 分貝），可見放大主要是改變觀感而不是增加資訊；放大後再輕度銳化，改善較多。
• 估計值要看信心：沒有文字的場景（人像、靜物各一張）估計值沒有意義：本次 2 張中有 2 張被標為「不可靠」（信心值約 0.04；工具以信心值大於 0.06 且墨跡點數足夠才標為可靠）；較難的頁面（背景漸層、雜訊、重度壓縮）3 張，誤差都在 0.05 度以內，信心值約 0.53，全部標為可靠。這些都是程式合成的頁面；真實照片裡的文件常有陰影、摺痕、透視與背景花紋，估計可能偏離，請一律對照預覽目視確認。

去雜訊對照

同一張加了高斯雜訊（σ=15）的圖，處理前 PSNR 25.14、SSIM 0.619。下表列出本工具的幾種去雜訊，以及外部函式庫的結果作為參考。外部函式庫的演算法與參數不同，不能直接拿來比高低；本工具的非局部平均是為了在瀏覽器內快速完成的簡化近似。

效能與記憶體

以下數字全部來自本機沙箱的實測，只有一台機器、每個情境各測一次，不是你的裝置的預測。沙箱是 2 核心、回報裝置記憶體 8 GB 的無頭 Chromium 141.0.7390.37；真實手機沒有實測。

載入並計算 SHA-256（4000×3000、約 1.3 MiB 的 JPEG）：正常速度 0.5 秒、CDP 降速 4 倍（僅主執行緒） 0.7 秒、手機外觀 390×844＋CDP 降速 4 倍 0.7 秒、整個瀏覽器限制在 25 ％單核 2.8 秒。「主執行緒最長任務」只記錄超過 50 毫秒的任務，「無」表示沒有任何任務超過 50 毫秒。「最長畫面間隔」是在處理期間以 requestAnimationFrame 量到的相鄰畫面最長間隔，用來看畫面有沒有卡住。處理時畫面保持可操作，是因為計算全部在背景工作者內，主執行緒只負責畫面。

降速實測要怎麼讀

• CDP 的 CPU 降速（Emulation.setCPUThrottlingRate）只作用於分頁的主執行緒。同一段迴圈在降速 4 倍時，主執行緒從 42 毫秒變成 141 毫秒，同一份程式在專用 Worker 內卻是 48 毫秒對 33 毫秒，幾乎沒變。所以「降速 4 倍」的那幾列只能說明主執行緒在變慢時畫面仍可操作（最長的任務與畫面間隔見表），不能拿來推算 Worker 內的處理時間。
• 要讓 Worker 也變慢，這裡把整個瀏覽器放進 Linux cgroup，限制在單一核心的 25 ％。同一個迴圈主執行緒 201 毫秒、Worker 113 毫秒（正常速度時是 42 與 48）。這一列的處理時間約為正常速度的 4 到 5 倍，是「整體慢 4 到 5 倍的裝置」的粗略模擬，不是任何真實裝置的量測。
• 四種情境的載入、預覽與原尺寸處理加起來，主執行緒回報的長任務（超過 50 毫秒）最長為 107 毫秒。其中超過 100 毫秒的有 2 個：手機外觀 390×844＋CDP 降速 4 倍（掃描文件的預覽）107、105 毫秒。這幾個都出現在主執行緒被降速 4 倍的情境。

記憶體

瀏覽器行程（含瀏覽器本體、GPU 與頁面，合計）的常駐記憶體，在上面幾次 4000×3000 的原尺寸處理後約為 969 到 1039 MB（粗略值，每次測量都包含瀏覽器本體；不是只算本工具）。套用到原尺寸之前，程式會先用保守公式估算尖峰記憶體，超過保護上限就不執行並說明原因：

保護上限預設 1536 MiB；瀏覽器回報裝置記憶體時，取「裝置記憶體 ×0.3」（最低 0.5 GiB）與預設值中較小者；沒有回報但主要輸入方式是觸控時降為 0.9 GiB。這個公式是按每一步的輸入、輸出與工作平面保守加總的設計值，沒有和實際的記憶體用量逐項對照；在較舊的裝置上仍可能失敗，失敗時會顯示「記憶體不足」的說明，而不是當機。

常見誤解

「增強之後看到車牌或人臉了。」

如果原圖有拍到，增強可能讓它比較好認；如果原圖沒有，銳化、放大與區域對比會製造看起來像字、像臉的紋理。請對照原圖，不要把副本裡新出現的筆畫當成原圖內容。

「放大 4 倍會更清楚。」

放大只是內插。×4 只會得到更大、更軟的圖；字是否可讀取決於原圖的像素。

「分數變高就是更接近真相。」

PSNR、SSIM 都要有乾淨原圖才算得出來，真實案件沒有。工具內的「清晰度指標」只是拉普拉斯變異數，雜訊與壓縮痕跡也會讓它變大，僅供參考。

「預覽就是最後的結果。」

預覽在縮圖上計算，接近但不承諾逐像素相同；下載的是在原尺寸上重新處理的結果。

「有處理紀錄就沒人能質疑。」

紀錄只是文字檔，可以被編輯，時間來自本機時鐘。它記錄做法，讓別人能重做並比對；它不替內容背書。

「JPEG 比較小，輸出 JPEG 就好。」

JPEG 有損，輸出時會再壓縮一次，可能把你剛處理好的細節抹掉或製造方塊。要保存工作副本，建議輸出 PNG。

「去模糊可以救回拖影或失焦的照片。」

本工具的去模糊假設模糊近似高斯，只適合輕度失焦。動態模糊、嚴重失焦與重度壓縮的圖，效果有限，也可能出現振鈴。

「換一個瀏覽器，結果也要逐位元相同。」

不承諾。數學函式與影像編碼器的差異可能造成末位不同；因此像素雜湊適合在同一個瀏覽器引擎下核對，檔案雜湊適合核對「這個檔案」。

「預設組合適合所有圖。」

不是。預設是針對常見情況的起點，實測中也有在個別圖上讓某項分數下降的例子。