Real-ESRGAN GUI 開源放大工具實測，任意尺寸與 GIF 都在本機跑完

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

把一張 640×360 的小圖放到 1600×900，能走的路不少：丟給線上 AI 放大網站，圖得先上傳；用 waifu2x 系工具，模型選擇要自己做功課；裝 upscayl 這類知名桌面 GUI，功能齊全，但它是 Electron 應用，安裝後將近 400MB。還有一條比較老派的路：Real-ESRGAN GUI。純 tkinter 寫成的跨平台開源工具，Windows 主程式只有 10MB 出頭，把 2022 年那顆命令列放大引擎 Real-ESRGAN-ncnn-vulkan 包成拖放就能用的介面，專案在 GitHub 累積超過 1,500 顆星，最新一版 Windows 包被下載了 1.4 萬次。

它在同類工具裡不算新，也不算最漂亮，但有兩個少見的堅持：整支程式完全離線（這點我逐檔讀過原始碼驗證），以及「任意尺寸放大」，你指定想要的確切寬度或高度，它想辦法算出來。我在 Mac 上實際跑過它的放大流程，這篇把這幾件事拆開來看，順便講清楚下載和選模型時容易踩的坑。

它跟 upscayl 差在哪裡

作者的 README 裡有一段很少見的自白：為什麼不直接用現成的 GUI。比較對象之一是 upscayl，理由寫得很具體。upscayl 用 Electron 實作，跨平台、介面漂亮、還有原圖對比功能，文件也詳細，但當時缺少 GIF 處理、自訂後處理命令和多語言支援，而且「又要多裝一個 Chromium 核心」：upscayl 安裝後約 400MB，Real-ESRGAN GUI 的 Windows 版（不含引擎與模型）只有 10MB 左右。這是作者自己的宣稱，數字與功能缺口以他的測量為準，我沒有復測 upscayl 的體積。

另一個比較對象更有故事性：Waifu2x-Extension-GUI。這個「全家桶」工具箱一度整合了 waifu2x、Real-ESRGAN、RIFE 補幀等一大串引擎，功能極多，但 2021 年 5 月的 v3.41.01 起改成閉源，並在每次啟動和處理完成時顯示購買高級版的廣告。作者明說，正是這個變化讓他動了「寫一個符合自己需求的輕量 GUI」的念頭。所以這個工具的存在本身就是一種路線選擇：功能做窄、體積做小、授權保持開放。

表裡的「無」是作者宣稱的功能缺口，出處是 2024 年 5 月之後就未再更新的 README；upscayl 這幾年持續更新，現況請以它的官方頁面為準。

公平地說，upscayl 的強項這個工具也給不了：前端技術做出來的介面和互動容易精緻，它有放大前後的對比預覽，文件寫得詳細，發版也勤。如果你重視的是「用起來的爽感」和持續收到更新，upscayl 仍然是合理選擇；Real-ESRGAN GUI 換到的是體積、GIF、自訂命令和多語言這幾張牌。兩者授權同為 AGPL-3.0，不算二選一的死局，硬碟夠的話並存也行。

任意尺寸放大的真實機制

Real-ESRGAN 引擎本身只會做固定倍率放大，2 倍、3 倍或 4 倍，用哪個倍率取決於模型。那「放大到寬度 1600」這種需求是怎麼來的？答案是兩段式組合：先讓 AI 用固定倍率放大到超過目標，再用傳統縮放演算法降到精確尺寸。降採樣演算法預設是 Lanczos，介面上能換成 Bicubic、Hamming、Bilinear、Box、Nearest 五種。

尺寸的指定方式有五種：固定倍率、等比放大到指定寬度、指定高度、最長邊、最短邊。搭配輸出路徑還有個貼心設計：輸出檔名會自動加上模型和倍率標記，例如「photo (realesrgan-x4plus-anime x4).png」或指定寬度時的「w1600」，批次處理一整個資料夾時不會互相蓋檔，回頭找「哪張是用哪個模型放的」也有線索可查。

作者在 README 舉的例子用 2 倍模型：640×360 放大到寬度 1600，實際是先放大到 1280×720，再放大到 2560×1440，最後降到 1600×900。我自己用 4 倍模型跑同一組數字，流程縮成一趟：AI 直接放大到 2560×1440，然後降到 1600×900，日誌裡明確打出 Downsample from 2560×1440 to 1600×900 這行。整趟在 Apple M4 Max 上花 1.85 秒。換成照片類素材（480×270 放大到剛好 4 倍的 1920×1080）更單純：AI 跑完就是精確尺寸，連降採樣那步都省了，1.21 秒。

Pin

給一個量化參考：同一張測試圖，AI 輸出在邊緣像素上的拉普拉斯回應大約是純 Lanczos 放大的 7 到 9 倍，兩者整體結構的 PSNR 是 35.6dB，意思是骨架沒變、細節被重繪過，圓形邊緣的鋸齒會被重新畫成平滑曲線。這是單張圖的量測，不同素材差異會很大。

Pin

理解這個機制有個實際好處：非整數倍輸出（例如 2.5 倍）的畫質，一半來自 AI 的固定倍率放大，一半來自你選的降採樣演算法。對畫質敏感的話，Lanczos 是穩妥的預設值，沒必要動。

實際操作的面貌是這樣：把圖片或整個資料夾拖到視窗上，輸入輸出路徑自動帶出，選模型、選尺寸計算方式，按開始，下方日誌區會即時捲出引擎的進度和它挑到的顯示卡。整個介面只有三個分頁（基本設定、進階設定、關於），沒有嚮導、沒有帳號登入、沒有雲端空間要綁定，是那種「打開就能工作」的老派桌面軟體性格。

Pin

放大後檔案會長多大也要有預期：我這組測試裡，27.9KB 的 640×360 動漫圖放大到 1600×900 後是 288KB；113KB 的照片放大到 1920×1080 後逼近 3.1MB。輸出想控制體積，靠輸出端的 WebP 有損壓縮或自訂命令轉檔，這在後面會講到。

「預放大」打開後，AI 可能根本沒跑

進階設定裡有個「預放大」（preupscale）選項，名字聽起來像加強版，實際行為相當反直覺。我做了對照：同樣把 640×360 的圖放大到寬度 800（1.25 倍），預放大關閉時，AI 跑一趟 4 倍放大再降到 800×450；預放大打開時，日誌只出現 Pre-upscale from 640×360 to 800×450 一行，引擎完全沒被呼叫，整個過程 0.01 秒結束，輸出是純 Lanczos 縮放，AI 一點都沒參與。

原因在它的邏輯設計：開啟預放大後，程式會先用傳統演算法把圖調整到「模型倍率的整數次方正好落在目標尺寸」的大小，代價是目標倍率低於 2 時，調整完就已經到位，AI 步驟直接跳過。所以結論要反過來記：想要「AI 版的 1.5 倍、1.25 倍輸出」，預放大要保持關閉；這個選項只在特定場景（大倍率、分階段放大）才有意義。預設值是關，維持預設就好。

同一段進階設定裡還有 TTA 模式。作者自己的實驗是：把幾張 1200px 以上的圖縮到四分之一再放大，比較和原圖的 SSIM，開 TTA 只比不開高出 0.002 左右，肉眼看不出差別，處理時間卻是好幾倍。他的原話是「一般情況下沒有開啟的必要」。預設同樣是關。

顯卡需求與拆分大小

引擎跑在 GPU 上：Windows 和 Linux 環境需要支援 Vulkan 的顯卡，我這次在 Mac 上實測跑的則是直接使用 Apple 晶片 GPU 的組建，日誌開頭就列出偵測到的裝置和 fp16、int8 支援狀態。沒有獨立顯卡的老機器要先確認這件事，否則引擎會直接起不來。

進階設定裡的「拆分大小」（tile size）對應引擎的 -t 參數，指的是把圖切成多大的區塊分批送進顯示卡運算。README 的建議是：自動設定就夠日常使用，想手動調的話，在顯示卡記憶體夠用的前提下用較大的值，處理速度更快、放大後的品質和細節也略好。切太小速度慢，切太大超出記憶體會出錯，拿不準就留在自動。另外兩個小細節：Windows 上它整合了工作列進度條和處理完成的通知（程式碼用 Windows Taskbar API 和 notify-py 實作），批次放一整個資料夾時不用盯著視窗等。

GIF 動圖與後處理命令

GIF 處理是這個工具相對少見的完整度。流程是把 GIF 拆成單幀並記錄每幀時長，逐幀放大後再合併回去。我拿一張 6 幀、200×150 的測試動圖跑 2 倍放大，全程 2.02 秒，輸出 400×300、6 幀時長原樣保留，中間幀用無損 WebP 暫存避免二次損失，檔案從 3.6KB 長到 39.7KB（逐幀放大本來就會讓動圖變大，輸出端的有損壓縮選項就是為了壓回來）。

針對帶透明背景的 GIF，它還有一個實驗性選項。GIF 的透明通道只有「透明／不透明」兩檔，直接放大邊緣會出現明顯鋸齒和顏色不可預期的雜邊；開啟後會強制把透明部分填成白色固定雜邊顏色，並對透明通道先做 3px 高斯模糊再套一條增對比曲線壓掉雜邊。作者自己標註這是實驗性的，建議只在 GIF 確實有透明部分時手動開，沒有透明部分時開著反而會出現奇怪的顏色。

輸出環節還有兩個進階開關。有損壓縮可以針對 JPEG 或 WebP 輸出設 0 到 100 的品質（預設 80），不開的話 WebP 走無損；自訂壓縮命令則把後處理完全交給你，用 {input} 和 {output} 當佔位符，README 給的示例包括用 avifenc 轉 AVIF、用 cjxl 轉 JPEG XL、用 gif2webp 把放大後的動圖轉成 WebP，甚至用 ImageMagick 加浮水印再轉格式。想把放大接進批次腳本的人，這一格命令欄比多數 GUI 的全部功能都值錢。

有個小邊角順便記下：帶透明通道的圖如果輸出成 JPG，引擎會強制把檔名換成 PNG 副檔名（JPG 不支援透明），這個 GUI 會自動把檔案搬回你指定的輸出名稱，不會讓你在資料夾裡找不到檔案。

五個內建模型怎麼選，附加模型怎麼裝

官方包裡帶了 5 個模型，選擇邏輯不複雜。照片、真實場景素材用 realesrgan-x4plus；動漫、插畫類用 realesrgan-x4plus-anime；帶 animevideo 字樣的三個模型（x2、x3、x4）針對動畫影片截圖，模型檔小、速度快，作者自己的測試是比 realesrgan-x4plus-anime 快 1.5 到 3 倍，但這個 GUI 明確不做影片處理功能，它們適合的是「影片截圖批次修清晰」這類用途。如果手邊只有 2 倍和 4 倍兩個版本而目標是 3 倍，選 4 倍那個再降下來，寧可選大不選小。

常被問到的兩個疑惑順便回答。放大等於修復嗎？不等於：模型做的是把邊緣和紋理重畫得乾淨，已經徹底丟失的細節（嚴重馬賽克、全糊的失焦）救不回來，它能把 640×360 的乾淨線稿放大到 1600×900 依然銳利，但變不出原本沒有的東西。要付費嗎？不用，AGPL 開源，連「專業版」都不存在，唯一的金流是「關於」頁裡作者自己的贊助連結。

想再進階，專案在 GitHub 單獨發了一個附加模型包，收錄約 27 組社群模型，來源是 Upscale Wiki 的模型資料庫和 Real-ESRGAN 官方 release，從寫實到動漫都有，各模型的適用範圍照模型作者的說明挑。書籍掃描專用的 SourceBook 不在包裡，要在 release 說明指到的下載點另外取得，還得替換引擎執行檔、改檔名後綴才認得，想用的人要照說明走。安裝方式很直覺：把同名的 .bin 和 .param 檔案丟進 models 資料夾，下次啟動就出現在下拉選單。有一個必須記住的警告：倍率不在 2 到 4 倍範圍（例如 8 倍模型）的檔案雖然讀得進來，但輸出圖片是壞的，別裝。

另一條路是換引擎。Real-ESRGAN-ncnn-vulkan 從 2022 年 4 月後就沒再更新，README 直接建議把仍在維護的分支 upscayl-ncnn 釋出的 upscayl-bin 放到主程式旁邊，程式會優先使用它；想改用 B 站的 Real-CUGAN 引擎也行，在 config.ini 把 upscaler 指過去、放入對應的 models-nose、models-pro、models-se 模型資料夾即可，Real-CUGAN 的降噪等級（保守、不降噪、降噪 1 到 3 級）會一併列成獨立選項。喜歡比較不同引擎效果的人，可以參考我們寫過的 AnimeSR 和 CYKSM 兩篇。

抓哪個版本，macOS 使用者先看這段

下載頁有三平台多種包，差異值得看清楚。Windows 有兩種：純 GUI 的 7z 檔約 9.7MB，不含引擎和模型，要自己去 Real-ESRGAN 的 release 下載補齊；bundled 版約 50MB，引擎加 5 個官方模型一次到位，多數人直接抓這個。Ubuntu 同樣有兩種（約 27MB 和 68MB）。macOS 的 appbundle 約 91MB，但主程式是單架構組建，最新版只編了 Apple 晶片的 arm64，Intel Mac 抓最新版會打不開主程式，附帶的引擎反而是雙架構。

這裡有個容易誤會的點：GitHub Releases 頁面上最新的可下載檔案停在 2024 年 6 月 2 日，看起來像停更了，但原始碼倉庫到 2026 年 5 月還有實質修復，2026 年 2 月修了 HiDPI 縮放問題，2026 年 5 月移除了相容 Python 3.12 的暫時補丁，建置流程同一天也跑成功了。「活躍度」和「發版週期」是兩回事：作者持續收 commit，只是不再往 Releases 頁發新包。想拿最新程式碼，要嘛按 README 的腳本自己打包（Apple 晶片打 arm64 單架構，效能比通用雙架構好），要嘛直接用 Python 3.10 以上跑原始碼。

把時間線攤開看會更清楚：專案 2022 年 5 月建立，2023 年 3 月發附加模型包，社群貢獻了烏克蘭文、土耳其文、西班牙文、法文翻譯，2024 年 6 月發了最後一個 Releases 組建，之後維護進入低頻但未中斷的狀態。對照之下，上游引擎 2022 年 4 月就凍結了，這個 GUI 的「殼」其實比裡面的「引擎」活得勤快得多。

macOS 使用者另外要知道幾件事。解壓後要先在終端機給主程式和引擎加上執行權限（chmod u+x），再清掉隔離屬性（xattr -cr），README 寫了完整命令，不熟終端機的話這步會有門檻，打不開的回報至今還掛在 issue 區。深色模式在 macOS 上不保證可用，README 原文寫「不適用（？）」，連作者自己都打了問號，官網腳註也註明因缺少測試環境，macOS 相關問題難以處理，白底介面是常態。介面語言有繁體中文（跟隨系統語言，42 條介面文字全數翻譯），但用詞看得出是簡體直轉，會出現「輸入（文件或文件夾）」這種混搭，台灣的說法是「資料夾」。

隱私與授權的分層

隱私這層可以說得很乾淨：我把整包原始碼逐檔掃過，沒有找到任何自動連網的程式碼，遙測、更新檢查、當機回報一概缺席，唯一會碰對外連結的是「關於」頁裡的 GitHub 與贊助按鈕，以及找不到引擎時自動開啟的下載頁。圖片從頭到尾不出本機，這和多數線上放大服務是本質差異，後者的商業模式決定了你的圖會經過別人的伺服器。習慣雲端工具的人可以對照我們整理過的 Picwish 圖片放大 一類服務的邊界。也因為沒有更新檢查，版本要自己留意，這是同一件事的另一面。

授權要分三層看：這個 GUI 本身是 AGPL-3.0；底下的 Real-ESRGAN-ncnn-vulkan 引擎是 MIT 授權；模型檔案各有各的授權範圍，附加模型包裡的社群模型尤其要逐個確認。個人放大圖片隨便用，要整合進商業產品或改作散布，三層都得過一遍，特別是 AGPL 對「網路服務也算散布」的認定比一般開源授權嚴格。

誰適合裝它

適合的人畫像很具體：手邊有批次舊圖、動圖或截圖要修清晰，不想一張張上傳雲端，對輸出尺寸有精確要求（例如電商圖一定要 1920 寬、社群封面一定要 1600×900），偶爾還想自己接管壓縮格式的，這個 10MB 級工具很難被取代。掃描文件、老照片、動漫截圖這類「一次幾十張」的場景正是它的主場。反過來，追求現代介面質感、需要影片放大（它明確不做）、或希望「下載永遠是最新版」（發版停在 2024 年）的人，upscayl 或 圖片壓縮工具 一類替代品會更省心。

我的判斷：如果你的需求是「本地、免費、任意尺寸」，它值得放進工具箱，記得從 bundled 版本抓起、模型按素材類型選、預放大別亂開。至於它會不會被繼續維護，引擎凍結在 2022 年是事實，但 GUI 層還在動，加上 upscayl-bin 隨時可替換引擎，這條路短期內不會斷。