VisionCull Pro：在電腦本機跑的 AI 選片工具，幫你先把模糊與閉眼照片挑出來

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

婚禮、活動、人像約拍一次拍下幾百到上千張 RAW，真正累的不是調色，而是回家後一張一張放大檢查誰跑焦、誰手震、誰剛好眨眼。VisionCull Pro 是一個在 Mac 本機跑的桌面選片助手（github.com/YuChiHuaCheng/vision-cull-pro，作者 YuChiHuaCheng 的個人專案，58 顆星，JavaScript 配 Python 分析器），它鎖定這段最耗時的初篩工作：用本機視覺模型把失焦、模糊、閉眼的照片標出來，再把判定結果寫成 Lightroom 能讀的 XMP 標籤，接進你既有的修圖流程。它不是要替你做最後的美感判斷，而是當一道前置的安檢門。

不過裝之前有兩件事要先講清楚。第一，這個專案截至目前並沒有附任何授權條款（倉庫裡沒有 LICENSE 檔，GitHub 的授權欄位是 None，API 的 license 端點回 404），原始碼雖然看得到，但法律上預設是「保留所有權利」，等於你並未取得使用、修改或散布的明確權利；ahhhhfs 的介紹文寫它「標註為 MIT 協議」，這與倉庫實際狀態不符，本文以倉庫現況為準。第二，它目前是 Electron 加 Python 的開發中版本，沒有簽署安裝包，要自己裝 Node.js 18 以上、Python 3.10 或 3.11、跑 npm install、用 uv 建 Python 虛擬環境，命令行門檻不低。這兩點決定了它現在適合誰。

它解決的是初篩，不是美感判斷

很多攝影師在找這類工具，本質上是想給後期減負。VisionCull Pro 把自己定位成第一道粗篩：你指定一個資料夾，它掃描裡面的照片，把跑焦、嚴重模糊這類硬傷挑出來，合格的會被複製到一個帶時間戳的新目錄，原始圖庫完全不動。這種非破壞性的設計對商業攝影很實際，至少不用擔心工具誤判把重要素材刪掉。

但它的能力範圍也在此劃清。AI 模型只會看「清晰度」和「睜眼狀態」，不會看「情緒」「氛圍」「構圖意圖」。一張刻意追焦的動態模糊、一張用淺景深表現的眼神特寫，在清晰度演算法眼裡可能跟失焦廢片沒兩樣，這類藝術性判斷它做不來，所以它只適合做粗篩，最終選片仍要人工複核。把它的定位想成「把明顯不要的先剔除，剩下的你自己看」，會比期待它幫你選出最好那張更接近事實。

Pin

模糊與閉眼兩條偵測路徑，背後是 OpenCV 加 ONNX 模型

VisionCull Pro 的本機分析主要靠兩套模型，而不是把照片丟給雲端大模型。在 python/analyzer.py 裡可以看見實際的偵測鏈路。

清晰度偵測用的是 Laplacian 變異數演算法，這是 OpenCV 領域很常見的銳利度評估法，概念是對影像做拉普拉斯運算後看變異程度，數值越低代表畫面越平、越可能模糊。當畫面裡偵測到人臉時，它會優先評估人臉區域的清晰度，因為人像攝影裡臉部通常是判斷焦點的依據；沒有偵測到人臉時，就退回全圖清晰度，讓風景、靜物這類非人像照片也能跑初篩。順帶一提，這套偵測同時會輸出曝光診斷，把明顯欠曝或過曝的照片送進複核佇列，這層是你看不到但會影響結果的判定。

閉眼偵測走的是另一條路。它先用 YuNet ONNX 模型（face_detection_yunet_2023mar.onnx）做人臉偵測，再換成 OCEC ONNX 模型（ocec_l.onnx）判斷眼睛開合，並用 MediaPipe Face Mesh 取得眼部關鍵點、算出 Eye Aspect Ratio 當輔助。當 EAR 低於設定門檻，就判定為閉眼。值得注意的是，OCEC 模型用了開放與閉合兩個機率門檻（原始碼裡寫死開眼 0.58、閉眼 0.42），中間地帶會被歸為不確定，這是一種偏保守的設計：不輕易把一張可能可用的照片判死。

這套組合的意義在於，偵測邏輯完全在你電腦上跑，模型檔（YuNet 約 232 KB、OCEC 約 6.4 MB）隨倉庫一起下載，不需要額外連到任何模型服務。對處理客戶未公開素材、商業拍攝原片的攝影師來說，照片不離開本機是這類工作流的硬需求，而這個工具在這一點上確實做到了，比把照片上傳到雲端選片服務穩當。這也是它跟同樣主打本機優先的 AiMaMi（把 AI 對話路由收進桌面管理面板）共通的設計取向：把資料與憑證留在裝置上，把要不要外送的選擇權交還給使用者。

Pin

隱私邊界比來源介紹說的更緊

這裡要點出一個跟 ahhhhhfs 介紹文不一樣的地方。原文提到專案碼裡保留了一條可選的外部 AI Vision API 路徑，擔心開啟後照片會被 base64 送到外部介面。實際去讀 electron/services/process-service.js，會看到這一行：const CLOUD_AI_ENABLED = false;。也就是說，這條雲端 AI 路徑在這個版本被作者主動關掉並鎖定，程式碼裡明白寫著「Cloud AI config was provided but local engine mode is locked for this build」，即使你在設定裡填了 API Key，這個版本也不會送出去。所以現況是：本機優先不只是宣傳話術，而是這個版本唯一會走的路。

這並不代表未來版本永遠如此，原始碼裡確實保留著那條雲端呼叫的程式碼骨架，作者哪天把開關打開、或你在別的分支看到 CLOUD_AI_ENABLED = true，那條路就會把照片編碼成 base64 送到你指定的 OpenAI 相容介面。所以正確的隱私姿態是：現況本機鎖定，但這個鎖是作者的自制，不是協議保證，把它當成「這個版本的照片流向」來理解，而不是「永遠保證不上雲」。處理敏感素材時，每次更新版本都重新確認這個開關狀態，是比較保隗的做法。對比 Image Provenance 那種「純瀏覽器檢視、根本沒有雲端程式碼」的設計，VisionCull Pro 多了一條存在但被關閉的雲端通道，這是兩者在架構上的具體差異。

Pin

RAW 支援與 Lightroom 整合，但有相容性但書

工具支援的格式涵蓋 JPG、JPEG，以及 CR2、CR3、NEF、ARW、RAF、DNG 等 RAW 副檔名。RAW 檔會先透過 ExifTool 抽出內嵌預覽圖，再拿這張預覽圖去做分析，而不是直接解 RAW。這個做法很合理，因為解 RAW 太慢，但代價是分析結果會受到「相機內嵌預覽的品質」影響，不同相機品牌、不同 RAW 結構抽出的預覽畫質不一樣，可能讓清晰度判斷失準。作者在文件裡也提醒，正式處理前先用備份目錄小規模測試，這是中肯的建議。如果系統裡沒有 ExifTool，RAW 預覽和元資料讀取會進入降級狀態，但 JPG、PNG 的篩選、人工複核、XMP 寫入仍能繼續，這層降級設計讓工具在缺工具的環境裡不會整個掛掉。

跟 Lightroom 的銜接是這個工具最實際的價值之一。篩選結果可以寫成 XMP sidecar 檔，支援保留、淘汰、全部三種模式，也能選擇跳過或覆蓋既有的 XMP，並回報寫入、跳過、失敗各多少筆。XMP 裡帶的是星級標記，匯進 Lightroom 後就能直接用星級過濾，不用在 Lightroom 裡重做一次篩選。對一個還在早期階段的專案來說，把匯出做成 sidecar 而不是直接改原始檔，是負責任的選擇。

跟 Photo Mechanic、Photolemur 擺在一起看定位

要判斷 VisionCull Pro 值不值得花時間部署，把它跟既有方案比一比最準。

從這張表能看出 VisionCull Pro 真正的位置。如果你的核心訴求是「在選片階段、照片不上雲、不花大錢買 Photo Mechanic」，它在一個沒有太多對手的位置：本機、免費、鎖定不上雲。Photo Mechanic 是專業選片的業界標準，但它靠的是極快的預覽速度和中繼資料工作流，判斷仍由人做，不幫你跑模糊偵測；Photolemur 3 走的是修圖而非選片，且是雲端 AI，照片要上傳，兩者跟 VisionCull Pro 解的問題不同。雲端 AI 選片服務能做到的事類似，但隱私代價就是把客戶原片交給第三方，這正是商業攝影師想避開的。VisionCull Pro 的差異化在這裡是成立的，但前提是你能接受它現在的部署門檻與無授權狀態。

適合誰，不適合誰

適合裝的人，大致長這樣：每次出片量大（婚禮、活動、人像約拍）、客戶素材有隱私顧慮不能上雲、熟悉 Node.js 與 Python 命令列、願意自己裝 uv 與 ExifTool、能接受原始碼公開但無授權條款的灰色地帶。對這群人來說，它在「本機跑、鎖定不上雲、寫 XMP 接 Lightroom」這幾項上確實填了一個空缺。

不適合的人也很明確。追求開箱即用、沒有命令列基礎的攝影師，現在會卡在裝不起來：作者自己寫的啟動說明提到 node server.js，但倉庫裡其實沒有這個檔案，真正的進入點是 electron .（看 package.json 的 scripts），這類文件與實際不一致的小問題在早期專案很常見，但對非技術使用者就是直接勸退。另外，如果你的選片會大量依賴氛圍、情緒、構圖這類藝術判斷，工具的清晰度與閉眼模型幫不上忙，反而可能把你要的動態模糊或淺景深特寫誤判成廢片，這類工作流不適合交給它做粗篩。

部署前的幾個確認

要實際跑起來，你需要先備齊環境：Node.js 18 以上、Python 3.10 或 3.11、ExifTool（RAW 預覽用，作者在 13.58 版驗證過）。裝完 Node 依賴後，Python 端用 uv 建虛擬環境：uv venv .venv --python 3.11，再 uv pip install --python .venv/bin/python -r python/requirements.txt。啟動完整桌面 demo 用 npm run dev:app，這會先起 Vite 再開 Electron。第一次跑務必拿一個小備份目錄測試，別直接對客戶原片跑全量，因為 RAW 預覽畫質差異、清晰度閾值的選擇都會影響判定，作者自己也提供 npm run eval:local 讓你先在樣例集上評估 keep、reject、needsReview 的分佈，這個評估報告會寫進 reports/local-engine-latest.json 方便你逐張查。

授權這關再強調一次。截至撰稿時，這個專案在 GitHub 上沒有 LICENSE 檔，原始碼看得到但法律上預設「保留所有權利」，你未取得使用、修改或散布的明確權利。個人單機試用風險較低，但如果你打算在公司內部部署、或改作商業流程使用，建議先到倉庫向作者確認授權狀態，或等專案補上正式 LICENSE 再動。這不是杞人憂天，而是「原始碼公開」與「可以合法使用」在法律上是兩回事。

常見問題

VisionCull Pro 是開源軟體嗎？ 嚴格說不是。原始碼公開看得到，但倉庫沒有 LICENSE 檔，法律上等於「保留所有權利」。ahhhhfs 的介紹文寫它標註為 MIT，這與倉庫實際狀態不符。要合法改作或商業部署，先向作者確認授權。

它會把照片上傳到雲端嗎？ 這個版本不會。雲端 AI 路徑在程式碼裡被作者用 CLOUD_AI_ENABLED = false 鎖掉了，就算你填了 API Key 也不會送出。但這條雲端程式碼骨架還在，未來版本可能改變，每次更新重新確認這個開關狀態比較保險。

它會誤判嗎？ 會。AI 只看清晰度與睜眼狀態，看不出情緒與構圖意圖。動態模糊、淺景深特寫這類刻意的效果可能被誤判為廢片，所以它只適合做第一道粗篩，最終選片仍要人工複核。

支援哪些相機的 RAW？ 支援 CR2、CR3、NEF、ARW、RAF、DNG 等副檔名，靠 ExifTool 抽內嵌預覽圖分析。不同相機的預覽畫質會影響判斷準確度，建議先用備份目錄測試。

需要什麼樣的電腦配備？ 沒有公開的硬體基準。它跑本機 ONNX 模型，理論上需要還過得去的 CPU，但作者沒有給出每分鐘處理張數或最低配備的實測數字，這部分只能你自己裝起來跑 eval 才知道。想了解本機 AI 工具的硬體需求通用判斷，可以參考 Can I Run AI 的檢測教學。

結論與下一步

VisionCull Pro 在「本機跑、鎖定不上雲、把模糊與閉眼廢片挑出來、寫 XMP 接 Lightroom」這個具體組合上，是一個思路明確、對隱私敏感的攝影工作流確實有用的工具。但它現在是早期開發中版本、無授權條款、文件與實際啟動方式有些對不上、沒有簽署安裝包，這組現實條件把它限制在「願意折騰命令列、能接受灰色授權、處理敏感素材的本機攝影師」這個很窄的人群裡。

如果你想試，建議照這個順序：第一步，到倉庫確認 CLOUD_AI_ENABLED 仍是 false、確認沒有新的 LICENSE；第二步，用 npm run eval:local 拿你自己拍過的一批樣例跑評估，看 keep、reject、needsReview 的分佈合不合理；第三步，把清晰度閾值調到適合你相機與風格的數值，再用一個小備份目錄跑完整流程，確認 XMP 寫進 Lightroom 後星級過濾如預期。走完這三步，你才會知道這個工具在你的工作流裡到底省不省時間，而不是只看星標數或 README 就下判斷。