KOMA：開源漫畫整理工具箱，把散亂圖檔自動清 QR 廣告、轉 AVIF 或 WebP 並打包成 cbz

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

把幾千本掃描漫畫塞進 NAS 之後，真正頭痛的往往不是沒有閱讀器，而是進庫之前的整理工作。每本資料夾裡的推廣 QR、混亂的檔名、未壓縮的 PNG，全都得在餵進 Komga 或 Kavita 這類媒體庫伺服器之前先處理掉。KOMA 就是把這段前置處理自動化的開源本機工具：掃描清除結尾 QR 廣告、批次轉換成 AVIF 或 WebP、重新命名、查重、最後裝訂成 cbz。它不取代閱讀器，也不取代媒體庫，只填補「入庫前的清潔與壓縮」這一段。

對於在 NAS 上自行架設 Komga 或 Kavita 的玩家來說，這段前置處理通常是沒有標準答案的硬手工：有人寫 Python 腳本批次砍 QR、有人用 Photoshop 動作錄製一鍵壓縮、有人則靠各種更名工具湊合。KOMA 把這些零散工序收進一個用 Tk 寫成的桌面程式，並提供一份能逐項調校的設定檔，讓整個流程變成可重現、可審計的工作流水線。

KOMA 是 GitHub 使用者 GrassSand 從 2026 年 1 月底起開發的 Python 專案，以 MIT 授權釋出，主要部署形態是 Windows 桌面程式，原始碼也能在 macOS 與 Linux 上以 uv 跑起來。它的定位很明確：幫已經擁有大量本地漫畫收藏的人，把雜亂的掃描圖檔轉成標準化、體積合理、可被媒體庫刮削的 cbz。

KOMA 在漫畫工具鏈裡的位置

漫畫工具鏈大致分三層：來源整理、媒體庫伺服器、閱讀器。Komga 與 Kavita 是媒體庫伺服器，負責架構化管理已整理好的 cbz/zip 並提供網頁與 API 介面；Tachiyomi、Mihon 這類是閱讀器，從各來源拉取並顯示；至於把原始掃描圖檔整理進庫之前的「清潔」階段，長期以來缺少專用工具，多半人靠 Photoshop 動作、手寫 FFmpeg 指令或各種腳本湊合。KOMA 補上的是這一段。

把它跟同類定位的選項擺在一起，差異會比較清楚。

對已經架好 Komga 或 Kavita 的人來說，KOMA 等於把入庫前那一道人工清潔工序自動化；對只用資料夾管理的人來說，它是把幾十 GB 的 PNG 收藏轉成十幾 GB cbz 的批次轉檔器。功能定位跟 Komga/Kavita 完全錯開，並不會互斥。

另一個值得釐清的點是 KOMA 與通用媒體工具的差別。FileBot 主要處理影視與動漫的命名對齊，能抓 TheTVDB、AniDB 的元資料，但對漫畫掃描圖檔這種「一話一資料夾、每張圖檔名亂七八糟」的場景著力有限；FFmpeg 命令列能做到所有 KOMA 的轉檔工作，但對於「掃 QR、查重、裝訂成 cbz」這類需要影像理解與跨檔操作的任務，純命令列組合很笨拙。KOMA 的價值在於把這些原本散落的工序收進一個有圖形介面的工具，降低非技術使用者上手門檻。

五個功能模組拆解

KOMA 目前包含五個獨立但可串接的功能模組，下面依模組逐一拆解。

掃描清理：QR 廣告與雜項垃圾

掃描清理是 KOMA 最有辨識度的功能。它整合 OpenCV 的 WeChatQRCode 模組，辨識圖片裡的 QR Code，再把位於資料夾結尾、屬於推廣性質的 QR 廣告整張移除。嚴格說起來它偵測的是 QR Code，不是通用浮水印。半透明 watermark、文字浮水印、logo 浮水印都不在 WeChatQRCode 的處理範圍裡，必須靠 v1.5.0 新增的「自訂廣告圖比對」功能另行處理。

設定檔 config.example.toml 內建一份 35 個網域的白名單，涵蓋 Bilibili、Pixiv、Twitter/X、DLSite、Fanbox、Patreon、Discord、Telegram、Instagram、YouTube、Melonbooks、Booth、Skeb、Ci-en、Fantia、Gumroad、Ko-fi、Misskey、Mastodon、Pawoo、Lofter、Weibo、QQ、Facebook、Tumblr、WordPress、Bluesky、Crepu、DMM 等 29 個品牌。白名單上的 QR 視為作者宣傳管道，不會被當廣告移除；這意味 KOMA 的設計意圖是清除盜版網站的推廣 QR，而非清除作者本人的社群連結。

這份白名單透露出工具的目標受眾與預設情境。名單裡有 Bilibili、Lofter、Weibo、QQ 等中文圈平台，也有 Pixiv、DLSite、Melonbooks、Booth、Fantia、Fanbox、Ci-en、Skeb 這類日本同人創作通路，再加上 Patreon、Gumroad、Ko-fi、Discord 等英語圈支持管道。可以推測作者把 KOMA 設計給「中日語境同人漫畫收藏整理」這個相對具體的受眾，並假設使用者尊重創作者在作品結尾留下的宣傳 QR。實際使用時，使用者可自行增刪白名單，例如把自家網站 QR 加進 qr_whitelist 清單就能避免被誤刪。

另一個值得注意的細節是：enable_ad_scan 在預設 config 裡是 false。也就是說廣告掃描預設關閉，使用者必須在設定頁主動開啟。這是合理的保守設計，QR 偵測有誤判風險，預設關閉能避免首次跑就刪掉使用者想保留的圖。

Pin

重命名：自然順序排序

把資料夾裡的圖片依自然順序（natsort）重新命名成 000、001、002⋯。看似簡單，但掃描漫畫常見的命名瑕疵包含補零不一致、中文檔名、副檔名混用，都會讓 Komga 之類的媒體庫在排序時誤判冊數順序。KOMA 的重命名模組額外支援「壓縮包處理」與「跨資料夾合併」，這部分對已經把單話各自壓成 zip 的收藏特別實用。

格式轉換：四種編碼器可選

轉檔模組底層是 FFmpeg，但 KOMA 不只提供「轉成 AVIF」這種粗粒度選項。從 config.example.toml 看，format 欄位有四個值可選："avif (svt)"、"avif (aom)"、"webp"、"jxl"。SVT-AV1 與 AOM-AV1 是兩套不同的 AV1 編碼器：SVT-AV1 速度快，適合批次處理；AOM-AV1 是參考實作，畫質略好但慢。WebP 相容性最好，JPEG XL 則是無損選項，能無損來回轉換。這套選項讓使用者可依硬體與目標（省空間、求速度、要無損）細調。

轉檔也支援畫質（1–100）與無損模式切換，並能把結果輸出成 CSV 報表，列出每個檔案轉換前後的體積與壓縮率。對需要回頭檢視哪些檔轉得最兇的人來說，CSV 報表是少見但實用的細節。若想了解 AVIF 與其他現代格式的特性，可以參考我們對 aviftopng.io 轉檔工具 的分析。

實務上幾種格式各有適用場景。把大量 PNG 掃描漫畫轉 AVIF（SVT-AV1）配合 quality 75，是兼顧速度與體積的安全選擇；若在意極致壓縮且能接受較長編碼時間，AOM-AV1 在相同 quality 下通常還能再擠出一些空間，但編碼時間會明顯拉長。JPEG XL 的無損模式適合捨不得丟細節的收藏，但檔案不會比破壞性壓縮小。WebP 則是相容性最好的選項，對一些較舊的漫畫閱讀器仍是首選。max_workers = 0 預設讓 KOMA 自動使用系統 75% 的 CPU 核心，避免轉檔時把整台 NAS 拖到無法做其他事；以 8 核心機器跑千張規模的 PNG → AVIF（SVT-AV1, quality 75）大約落在分鐘級到十幾分鐘之間，實際速度仍視解析度與 CPU 而定。

歸檔查重：檔名比對 + 封面相似度

累積幾年下來的本地收藏，重複幾乎是必然。KOMA 的查重模組提供兩種模式：檔名模式與封面相似度模式。檔名模式會從壓縮檔名稱抽取「社團（作者）作品（系列）」這類標準化樣式來比對；封面相似度模式更激進，會呼叫 ONNX 深度學習模型分析封面影像的特徵向量，找出「檔名不同但封面相近」的重複品。後者對經歷過多次重新打包、命名混亂的收藏特別有用，但也代表第一次跑查重時 CPU 與記憶體會吃比較兇，ONNX 模型載入與推論需要數百 MB RAM，低記憶體 NAS 建議關閉其他大型進程再跑。

合集裝訂：把散落圖檔裝成一本

合集裝訂是 v0.3.0 才加入的功能，目的在把單張散圖、單話資料夾、零散 zip「裝訂」成完整的合輯 cbz。模組提供拖拽排序介面，能調整卷與話的順序，並把跨資料夾的圖依新順序重新命名。對從掃圖站下載下來的零散資源來說，這個模組能把一本完整作品從一堆碎片中拼回來。

授權組合：MIT 外殼與 FFmpeg 的兩層

KOMA 自己的程式碼是 MIT，但實際執行時呼叫了三個關鍵第三方元件：FFmpeg（LGPL v2.1+ 或 GPL v3，依編譯旗標）、7-Zip（LGPL）、OpenCV 與 WeChatQRCode（Apache 2.0）。這套組合在漫畫整理工具裡很常見，但有幾個合規細節值得說清楚。

FFmpeg 預設是 LGPL 授權，若啟用 --enable-gpl 與 --enable-libx264 等 GPL 旗標，整個 FFmpeg build 會變成 GPL。KOMA 需要的 --enable-libsvtav1、--enable-libaom、--enable-libjxl、--enable-libwebp 屬於 LGPL 範圍，理論上可維持 LGPL build。但官方下載的 FFmpeg 二制檔多半是 full build（含 GPL），使用者若直接拿來搭配 KOMA 一起散佈，就要注意整個組合的授權是不是符合自己的使用情境。對只是本機自用的人來說影響不大；對想打包 KOMA 重新散佈的人來說，這層細節不能跳過。

7-Zip 與 OpenCV 的授權就單純許多：7-Zip 是 LGPL，OpenCV 與 WeChatQRCode 是 Apache 2.0，兩者對商業使用與封閉散佈都相容。KOMA 把這些元件的著作權與授權清楚標在 README 的「第三方組件說明」段，這在小型開源專案裡是少見的誠實做法。

Pin

部署門檻與 Windows 優先

KOMA 在 README 提供兩種安裝路徑。第一種是下載 Windows 預編譯版：從 GitHub Releases 抓 Koma-Windows-x64_v1.5.0.zip（約 89 MB）或 Koma-Windows-x64-with-FFmpeg_v1.5.0.zip（約 158 MB）。前者假設你已經自備符合編譯旗標的 FFmpeg；後者把相容版 FFmpeg 一起打包，下載即用但檔案大。

第二種是從原始碼跑，用 uv 管理依賴：

git clone https://github.com/grasssand/koma.git
cd koma
uv sync
uv run koma

這條路徑對 macOS 與 Linux 使用者是必要的，但有兩個門檻：Python 必須是 3.12 以上版本（3.11 以下不相容），而且系統要自備編譯旗標正確的 FFmpeg。macOS 上若用 Homebrew 裝的 FFmpeg（brew install ffmpeg），預設會包含 SVT-AV1、AOM、libjxl、libwebp，所以多半能直接用；Linux 發行版的 FFmpeg 則視打包方式而定，Debian/Ubuntu 預裝版本可能缺 libjxl 或 libsvtav1，得自己重編。

Windows 使用者若不想碰 Python 環境，下載 with-FFmpeg 的 zip 解壓即用是阻力最小的路線。不過這個 build 也繼承了 FFmpeg 的 LGPL/GPL 授權條件，散佈時要連同 FFmpeg 授權一起處理。

安全設計與遙測

KOMA 的依賴清單（pyproject.toml）沒有 PostHog、Sentry、Firebase、Umeng 或任何通用 analytics SDK。整個專案唯一會主動發 outbound HTTP 的地方是設定頁的「檢查更新」按鈕，呼叫 GitHub Releases API 比對最新版號，是使用者手動觸發，不是背景遙測。

設定檔讀取順序是 ~/.config/koma/config.toml（XDG 風格）→ 程式所在目錄 → 當前工作目錄。首次啟動時會在使用者設定目錄產生一份預設 config.toml，這也是廣告掃描預設關閉、max_workers = 0（自動用 75% CPU 核心）、format = "avif (svt)"、quality = 75 的預設值來源。把這些值擺進設定檔而非硬編，方便使用者依硬體調校，也是 open-source 工具便於審計的優點。

清理掉的檔案也不是直接 unlink 永久刪除。依賴清單裡的 send2trash 表示 KOMA 把刪除的檔案送進系統回收桶，誤刪時能救回，這在批次處理幾千本收藏時是重要的安全網。

限制與風險

• 廣告掃描範圍限於 QR Code。WeChatQRCode 偵測的是 QR 圖樣本身，半透明 watermark、文字 logo、對角線網點這類常見 watermark 都不在自動清除範圍。v1.5.0 加入「自訂廣告圖比對」擴大了範圍，但仍要使用者提供樣本。
• 廣告掃描預設關閉。第一次跑 KOMA 不會自動清 QR，要先進設定打開 enable_ad_scan。這是保守設計，但也代表期待「裝完就能一鍵清乾淨」的人會失望。
• Windows 優先。只有 Windows 有預編譯版，macOS 與 Linux 必須從原始碼跑。Python 3.12+ 是硬需求。
• FFmpeg 編譯旗標門檻。標準 Linux 發行版打包的 FFmpeg 可能缺 SVT-AV1 或 libjxl，得自己重編或改抓靜態 build。
• 測試覆蓋有限。專案有 pytest 與 coverage 設定，但 pyproject.toml 明確 omit 掉 main.py、utils.py、ui/*，只有 core/* 真正有測試覆蓋。對重視自動化測試的人來說，UI 層與主入口沒測試是明顯弱點。
• dual-use 與版權。工具能清 QR 廣告、批次壓縮、查重，客觀效果之一是清理盜版掃描資源。作者在 README 加了免責聲明「僅供個人學習與本地檔案整理使用」，並要求尊重創作者版權。但工具本身無法判斷檔案來源是否合法，這層責任在使用者。
• 相對年輕。2026 年 1 月才首次釋出，75 star、4 fork、1 open issue。功能完整但生態尚小，長期維護仍看作者個人意願。

適合誰、不適合誰

KOMA 對以下讀者會明顯有用：已經在 NAS 上架構 Komga、Kavita 或類似媒體庫的人；本地有大量掃描漫畫、捨不得刪但硬碟吃緊的人；習慣用 FFmpeg 批次處理圖檔、想換成 GUI 工作流的人。對這些人來說，KOMA 等於把以前要用 Photoshop 動作、FFmpeg 腳本、各種更名工具拼湊的工作流程，整合進一個有 GUI 的桌面程式。

反之，若你的需求只是單次轉幾張圖，線上轉檔工具 或 一般媒體壓縮工具 可能更直接；若你在找的是漫畫閱讀器，KOMA 不處理閱讀；若你需要的是伺服器級的媒體庫管理，Komga 或 Kavita 才是答案。KOMA 的價值在於填補「入庫前」這一段，把它當作端到端方案會誤解它的定位。

對習慣本機工具鏈、想多了解 FFmpeg 編碼器選擇的人，可參考我們整理的 媒體壓縮工具 與其他相關資源；KOMA 的格式選項與那條生態系互補，能串成完整的本機圖檔處理工作流。

常見問答

KOMA 能移除半透明 watermark 嗎？

不能。內建的 WeChatQRCode 偵測器只認 QR Code 圖樣，主要針對結尾的推廣 QR 廣告。半透明 watermark、文字 logo、對角網點這類要靠 v1.5.0 新增的「自訂廣告圖比對」功能，而且要使用者自己提供樣本圖，工具才會依樣本比對清除。

轉檔實際能省多少空間？

依輸入格式與選的編碼器差異很大。把未壓縮 PNG 轉成 AVIF 或 WebP 通常能省下 40% 到 60%，但實際數字要看原始圖檔內容（線稿、網點、彩頁壓縮率不同）。JPEG 已經是破壞性壓縮，再轉 AVIF 的空間節省有限。KOMA 會在轉檔結束後產生 CSV 報表，列出每個檔案轉換前後的體積，可依實際數字判斷效果。

商業使用有哪些限制？

KOMA 自身是 MIT，商業使用沒問題。但打包進 KOMA 的 FFmpeg 若是 GPL build（例如官方下載的 full build），再散佈整個組合時要符合 GPL 條件；若僅本機使用、不散佈，FFmpeg 的授權條件相對寬鬆。提供商業服務前最好自行確認 FFmpeg 是 LGPL 還是 GPL build，再評估組合授權。

macOS 與 Linux 能用嗎？

原始碼可以，預編譯版不行。macOS 與 Linux 使用者要從 GitHub clone 下來，用 uv sync 裝依賴，再 uv run koma 啟動。Python 3.12 是硬需求。FFmpeg 要自備含 SVT-AV1、AOM、libjxl、libwebp 的 build，macOS Homebrew 的 ffmpeg 預設符合需求，Linux 則視發行版打包。

KOMA 會自動回傳任何資料給作者嗎？

不會。依賴清單裡沒有 analytics 或遙測 SDK，唯一會發 outbound 請求的是設定頁的「檢查更新」按鈕，呼叫 GitHub Releases API 比對版號，而且要使用者主動按下才觸發。設定檔與漫畫收藏都留在本機，不會上傳。

結論：把入庫前的最後一哩自動化

KOMA 的價值不在於「整理漫畫」這個廣泛口號，而在於它把過去散落在命令列與腳本裡的工作流程，收進一個可點擊操作的桌面介面，讓不懂 Python 或 FFmpeg 的人也能跑完整流水線。它的功能切分清楚、設定檔設計合理、對授權與第三方元件的揭露也夠誠實。如果你正苦惱於本地漫畫收藏整理到一半卡住，KOMA 是值得裝來試一次的工具，記得先在備份上跑，確認參數後再進全庫。

KOMA 專案網址：github.com/grasssand/koma。最新版本 v1.5.0（2026-05-28），Windows 預編譯版可直接下載，原始碼相容 macOS 與 Linux。