影像處理 – InferNews

Montara 本地優先影片工作台

2026 年 8 月 2 日

做影片流程最麻煩，往往唔係生成一段畫面，而係素材、剪接決定、旁白、輸出格式同後續修改散落喺唔同工具。

Montara 就係朝住呢個痛點而來：一個本地優先嘅開源影片製作工具／框架，用 Timeline IR 做唯一時間軸來源，將規劃、編輯、渲染同交接串返埋。

它吸引嘅地方，在於先處理「冇雲端都要交到片」呢個現實限制。就算零 API keys，仍可經 FFmpeg 走本地 fallback 輸出可觀看 MP4，連字幕卡、語音路徑同部分媒體都預留咗本地方案；有裝 Remotion 就做 native smoke，冇裝亦會退回 FFmpeg，呢種設計比起只展示理想雲端流程嘅項目踏實得多。

同類做法常見係綁死某個生成服務或者某款剪片介面，Montara 反而把 provider 放成可插拔層，會建立 request、做 redaction、支援 dry-run 同 live-audit，但付費雲端呼叫要明確開啟。代價亦好清楚：它而家最成熟嘅係時間軸驗證、編輯操作、渲染路徑、editor bridge 匯入匯出，同埋真實 MP4 渲染與 post-render QA；README 亦講明長片規模仍屬 roadmap，唔係所有電影級工作流都已全面驗證。

Timeline IR 把場景計劃、剪接決定、匯入 editor cut 同生成素材收斂成一份 JSON
本地路線完整，FFmpeg 係通用底線，部分 video/image/speech/music 有 fallback
可匯出 EDL、OTIO、FCPXML，方便轉去 Premiere、Resolve、Final Cut 繼續做
provider 機制重視審計與可驗證性，適合要保留流程紀錄嘅團隊較受惠嘅會係想把 AI 生成同傳統後期接埋嘅內容團隊、要保留本地控制權嘅創作者，或者打算讓 agent 參與影片流水線嘅開發者。

Montara 已經唔止係 demo 級拼裝，因為它把「可編輯來源」、「真實渲染結果」同「可交畀剪輯軟件接手」放埋同一條線；不過想追求高度成熟嘅長篇製作，仍要留意目前覆蓋範圍主要集中喺已測試嘅 renderer 同橋接能力。

GitHub

Categories: 開源, Agentic, API, Video, 影像處理, 框架, LTX

MPIE-Bench：多人修圖基準

2026 年 8 月 1 日

當多人影像編輯開始涉及互動動作、身體接觸，例如擁抱、攜帶或擒抱，同多角色參考圖，模型最常翻車的地方就不只是一張圖靚唔靚。MPIE-Bench 屬於基準測試資料集與評分工具，焦點是檢查編輯模型能否在跟從指令之餘，同時保住人物數量、身份一致性、肢體結構同互動幾何是否合理。

MPIE-Bench 不是再做一個生成模型，而是替多人編輯建立較完整的檢查方法。測試集有 2,500 個案例，並按接觸密度分成 C0 到 C3，意思是由沒有接觸到高密度接觸場景都會覆蓋；這種切法有助分辨模型是單純怕多人，還是特別怕擁抱、扶持、碰撞這類複雜互動。

評分設計亦有取向。六個軸線，除了身份、指令遵從、人物數量與整體畫質，亦把 anatomy 和 interaction 拉成重點，並用 mesh-anchored Anatomy / Interaction 來處理較難主觀判斷的部份。對研究團隊或做產品評測的人來說，這比只看美感分數更有參考價值，因為它直接對應多人編輯最容易出錯的位置。

官方提供 2,500-sample test set、evaluation protocol 同 scoring code
重點量度多人編輯中的身份保持、人物數量、動作互動同整體質素
測試案例按接觸密度 C0–C3 分類，方便看清模型失誤模式
可把模型輸出放到指定資料夾，再跑 E2E scorer 完成整體評分

部署資訊已有基本方向，安裝細節放在 docs/INSTALL.md，而且評分流程需要額外權重、環境設定，以及 AI_GATEWAY_URL、AI_GATEWAY_KEY 等配置；單靠儲存庫首頁未足以完整重現全部步驟。另有三個 closed-source baseline 的 frozen judgments，可作對照，但 open-source model dumps 沒有公開，這表示它更適合拿來評測自己的輸出，而不是直接比較所有現成模型結果。

對開發多人影像編輯、角色一致性編輯，或要驗證 VLM、影像生成模型在複雜人物互動表現的團隊來說，MPIE-Bench 的價值在於它把「多人」這件事拆成可追蹤的失敗類型。它未必能代替最終人工審美判斷，但很適合放進模型迭代流程，幫你更早發現哪些能力其實只在簡單場景先成立。

GitHub

Categories: 開源, 影像處理, 視覺模型

SpatialCLI 用空間工具補強視覺推理

2026 年 8 月 1 日

A comparison between a general VLM and a general VLM augmented with SpatialCLI tools

一到要指出物件位置、分清遮擋關係，或者估計深度與姿態，純 Vision-Language Model 往往會答到有方向但未夠準。SpatialCLI 把呢個落差處理得幾直接：它不是單靠一個大模型硬撐，而是把空間能力拆開，先讓模型懂得呼叫工具，再進一步把這些能力學回自己身上；整體定位更像一個結合模型、工具鏈與訓練方法的研究項目。

它最有意思的地方，在於三段式 Call-Learn-Internalize。第一步先接上做 localization、segmentation、metric depth、pose 的 specialist vision models，第二步用 Cold-Start SFT 與 agentic RL 訓練模型判斷幾時要用哪個工具、怎樣整合結果，第三步再把成功軌跡轉回模型能力。取向很清楚：寧願先借助外部工具拿到更可靠的局部感知，再追求把能力內化，減少每次推理都依賴外掛模組。

對研究團隊或做多模態 Agentic 工作流的人來說，這個項目值得留意，因為它同時放出 SpatialCLI code、SpatialCLI-8B 與 SpatialCLI-Data，不只是概念展示。理解它的部署方式也不難：代碼庫負責工具調用與訓練流程，Hugging Face 上的模型與資料集則對應推理、微調和重現實驗的核心材料；要完整驗證效果，通常要連同外部空間工具一併配置。

類型上屬於模型加框架的研究項目，目的是提升多模態模型在空間推理上的準確度與工具使用能力。
重點不只在「可呼叫工具」，而是進一步把工具使用經驗轉化成模型本身的能力。
已公開論文、SpatialCLI-8B 與 SpatialCLI-Data，方便重現與延伸訓練。
適合要處理定位、分割、深度、姿態等視覺任務的人員參考其工作流設計。

現有資訊未見 README 完整列出量化結果細節，但評測章節與 specialist models 章節已預留，顯示作者不是把它包裝成單一模型升級，而是把「何時調工具、如何學會不用工具也保留能力」當成核心問題。這種做法的代價也很明顯：系統整合與訓練鏈會比單純跑一個 VLM 複雜，不過換來的是更貼近真實空間任務的推理穩定性。

GitHub

Categories: 開源, Agentic, 多模態模型, 影像處理, 視覺模型

ID-V2V：先拍片後改風格的影像研究

2026 年 7 月 31 日

開發團隊來自 Netflix 與 Eyeline Labs。這個研究項目瞄準影像製作中最棘手的一段流程：想改影片風格、場景氣氛甚至補做光線，但又不想犧牲演員的表情、眼神、口型同步和肢體動作；ID-V2V 屬於 video-to-video 生成框架，處理的正是這種「保留身份與表演、再把風格傳播到整段影片」的問題。

現有做法常把影片重繪理解成一般風格轉換或逐格生成，作者認為這種範式很難同時守住 facial likeness 與細微 performance。ID-V2V 的切入點是把 identity preservation 重新表述成 video relighting，再把 edited keyframe 帶來的風格變化交給 controlled video synthesis 處理，並結合 relit facial regions、facial normal maps、edited keyframes 與 depth sequences，將身份約束與整體畫面變化拆開處理。

這個取向的價值很直接：你先拍好 source video，再準備一張 stylized keyframe，系統便嘗試把光線、場景與風格延展到整段片，同時盡量守住人物。原始資料亦提到 imperfect keyframe 的情況，即使首張風格幀和原片姿勢未必完全對齊，模型仍會在之後的幀數重新貼近 source video 的身份與表演，這點比只追求單幀好看更貼近製作流程。

提供兩個模型變體：idv2v 以及加入 normal-depth 訊號的版本
preprocess → generate 的推理流程與輸入輸出結構
環境集中在單一 uv 環境，另需下載多個 checkpoints，預設資源需求相當高
已測試於 8× A100-80GB，代表它較接近研究與製作級部署，不是輕量玩具
項目定位寫得很清楚，只供 demonstration and inspiration purposes

部署與測試資訊算完整，提供環境設定、checkpoint 下載、推理流程和多種案例，但門檻不低：需要 Python 3.10、torch 2.6+cu118、SAM3 權限，以及連同 Wan2.1 相關元件在內的大量模型檔案。性能方面，項目與首頁都表示在 preserving facial likeness 與 fine-grained facial performance 上明顯優於既有方法，並支援 single-subject 與 multi-subject 場景。

項目主頁 · GitHub · Paper

Categories: 開源, Video, Python, 影像處理, Dataset 數據集

Microsoft Mage：4B 多模態輕量路線

2026 年 7 月 31 日

當你想喺有限 GPU 預算下做影像生成、編輯，甚至延伸到影像與影片理解，Mage 這個開源模型家族的定位就相當直接：用固定 4B 參數規模，處理多模態理解與生成兩條路線，目標唔係堆大模型，而係保留研究可控性同部署可行性。

Mage 目前最完整的是 Mage-Flow，屬於模型家族中的生成與編輯分支。它把 Mage-VAE 同 Native-Resolution Multimodal Diffusion Transformer 組合起來，前者負責更高效率的 latent tokenizer，後者負責文字生圖與指令式修圖；同時提供 Base、RL-aligned 同 4-step Turbo 版本，方便按畫質、對齊程度與速度取捨。另一條線 Mage-VL 對準 image/video understanding，但程式與權重細節仍待釋出。

同類開源影像模型很多都靠更大參數量換效果，Mage 的判斷明顯不同：它把重點放喺 codec-aligned efficiency，同一個 checkpoint 已可覆蓋 512 到 2048、不同長闊比，連 4:1 這類極端尺寸都原生支援，減少多套模型或額外縮放流程。它在生成、編輯表現上可與 Qwen-Image 20B、FLUX.2 32B、FireRed-Image-Edit 20B 等較大型開源系統競爭，但取捨是 Mage-VL 仍未完整開放，整個家族現階段更適合關注研究與工作流整合的人先行評估。

Super fast Image Edit model Mage-Flow on 8GB VRAM

Watch this video on YouTube

固定 4B 規模，主打可訓練、可微調、可部署
Mage-Flow 已覆蓋 text-to-image 與 instruction-based image editing
Mage-VAE 以更低 encode/decode MACs 減輕高解析度瓶頸
單一 checkpoint 支援 512–2048 與多種 aspect ratio
Turbo 版本強調速度，1024² 在單張 A100 有明確推理數字

部署與測試方面，現有資料顯示 Hugging Face 已提供多個 Mage-Flow 與 Mage-Flow-Edit 權重，適合先用現成 checkpoint 驗證生成、修圖與速度，再決定是否進一步做微調。對做垂直領域影像項目、想研究後訓練方法，或者需要把高解析度生成放入較實際算力條件的人，Mage 的吸引力不在花巧包裝，而在它用一條輕量路線，把研究、性能與部署成本拉回較平衡的位置。

項目主頁 · GitHub · 模型

Categories: 開源, Qwen, 微軟, Stable Diffusion, Video, Image, Medical醫學, txt2img, 多模態模型, 影像模型, 影像處理, 模型, 視覺模型

ReDesign 把平面圖轉為可編輯設計

2026 年 7 月 31 日

設計原檔遺失之後，最麻煩唔係畫面睇唔到，而係改唔到字、拆唔開圖層、調唔到前後次序。ReDesign屬於Agentic取向的研究型工具，目標係由單張 raster image 重建出可編輯設計結構，輸出成帶有文字、向量形狀、群組同 z-order 的 JSON hierarchy。

它的判斷方式唔係一次過猜完整個版面，而係將設計當成 layer tree，由大區域開始逐層拆細，再用 verifier 檢查每一步成唔成立。呢個取向比起只做 OCR、只做分割，或者直接做多圖層分解更完整，代價就係系統較重，亦要配合多個視覺工具同較高 GPU 記憶體，當中 Qwen 相關 worker 官方已寫明大約要對應 55 GB 級別資源先容易跑得順。

相關模組之間的分工幾清楚：VLM controller 負責揀動作，文字會交由 PaddleOCR、字體辨識、Hi-SAM 同 LaMa 處理；物件與圖層則會用到 Qwen-Image-Layered、GroundingDINO、SAM 2、connected-component analysis 同 VTracer。換句話講，呢個項目唔係單一模型，而係把多個模型與工具串成一條可驗證的還原流程，較適合研究設計還原、可編輯圖形生成，或者想將靜態素材重新帶回設計工作流的團隊。

單張平面圖可還原成可編輯 JSON hierarchy
支援文字、向量形狀、圖片、群組與 z-order
採用 coarse-to-fine tree expansion，加上 verifier 修正分支
效能展示基於 Figma-909，指標上普遍優於多個 baseline

評測方面，項目頁面列出 Figma-909 這個 Dataset 數據集，並顯示 ReDesign 在 L1、PSNR、LPIPS、PQ 同 F1 等指標整體領先 baseline，說明它唔只重建外觀，亦較重視元素級別的可編輯性。儲存庫已提供 agent、baseline 同工具後端結構，但它更似一個研究系統而唔係輕量腳本；較值得留意的是多 GPU 分片、平行 worker 同視覺工具的資源安排，較適合有運算環境的研究者或產品團隊深入測試。

項目主頁 · GitHub

Categories: 開源, Qwen, Agentic, Image, 多模態模型, 影像處理, 視覺模型, Dataset 數據集

Krea 2 Outpaint：外擴 LoRA 補畫面

2026 年 7 月 19 日

畫面外擴最怕兩件事：原圖內容被改壞，或者延伸後透視、光線同結構接唔上。呢個項目明確建立在 Krea/Krea-2-Turbo 之上，並以 Krea 2 Raw 作訓練目標，形式係一個 rank-32 的 LoRA，用嚟做 image-to-image outpainting，重點唔係單純參考原圖，而係連原圖要放喺新畫布邊個區域都一併編碼。

它的做法是把來源 latent tokens 加上來自目標 bounding box 的 rotary coordinates，令 denoiser 能理解「已知畫面屬於整張新圖的哪個位置」。所以它比一般 image-reference adapter 更適合做左貼右擴、上貼下擴，甚至置中後向兩邊延伸，對透視、光照、紋理連續性的控制更直接。

檔案資訊相當清楚，但重點不在量化版本。頁面列出 krea2_outpaint_rank32.safetensors、pipeline.py、outpaint.py、example.py，另有授權與雜湊檔；同時明確說明 Hugging Face 自動產生的 Diffusers snippet 及一般 LoRA importer 不相容，要用隨附腳本與自訂 pipeline。這代表它不是即插即用型 LoRA，而係帶有功能性介面的適配器。

基礎模型已指明為 Krea/Krea-2-Turbo，並針對 distilled 8-step inference 設計。
核心差異在 registered reference_placements，可指定原圖在目標畫布的位置。
已測試寫實、水彩、stylized 3D 等場景，涵蓋橫向、縱向與置中延伸。
頁面沒有提供 GGUF、mmproj、llama.cpp、Ollama、LM Studio 或量化等資訊。

使用取向上，它更像為 Krea 2 編輯流程補上一個 UI 版的外擴能力，而唔係通用本地推理模型。由於依賴 diffusers 與自訂程式碼，適合已經在 Python 圖像流程中工作、需要穩定控制構圖位置的人。

項目主頁 · 模型

Categories: 開源, Image, Ollama, 影像模型, 影像處理, 視覺模型

MonkeyOCRv2 文件通用 OCR 底座

2026 年 7 月 17 日

文件 AI 最麻煩的地方，在於文字辨識、版面解析、文件理解、公式辨識，甚至竄改檢測，很多時都要拆成幾個模型串起來。MonkeyOCRv2 把自己放在視覺文字基礎模型的位置，核心不是只追單一 OCR 指標，而是想用同一個 encoder 同時覆蓋多語言文件 parsing、understanding、text recognition、formula recognition 以至 scene text detection。

它採取的路線很明確：不像部分做法會按任務各自訓練小模型，MonkeyOCRv2 強調 fine-grained text modeling、cross-task representation learning 同 cross-lingual generalization，等於先把「文字作為視覺內容」這件事學得更深，再把能力分流到不同文件任務。這種取向的好處，是同一套底座較適合研究團隊或產品團隊整合工作流；代價則是現有資訊仍以模型發布為主，完整效能對比與部署細節還要結合論文與 checkpoint 再判斷。

現階段最值得留意的，是項目已不只放出單一模型名稱，而是分成幾條較清晰的能力線。 MonkeyOCRv2 vision encoder，以及面向 multilingual document parsing 的 MonkeyOCRv2-Parsing、面向 efficient document understanding 的 MonkeyOCRv2-Und，並提供 Hugging Face 與 ModelScope checkpoint，代表測試方式大致會圍繞下載權重後，按任務接入 parsing、recognition 或 understanding 流程，而不是單純打開一個聊天介面就完成。

涵蓋 OCR、文件理解、公式辨識、竄改檢測、重疊文字分割等多類任務
提供 MonkeyOCRv2-S、MonkeyOCRv2-B、MonkeyOCRv2-AS，不同 backbone 對應不同場景
S、B 版本偏向 Recognition / Parsing / Understanding，AS 版本偏向 Detection / Segmentation
已公開 Demo、Hugging Face 集合與 MonkeyDocv2 數據集線索，方便交叉驗證

從現有公開資訊看，這個項目較適合做 Document AI、智能審核、票據與表單處理，也適合想比較 dots.mocr、PaddleOCR-VL、Qwen3-VL 這類路線差異的人。它未必是最輕量的選擇，但「一個編碼器橫跨多任務與多語言」這個方向，對需要長期維護文件工作流的項目有相當吸引力。

GitHub · Paper

Categories: 開源, Qwen, OpenAI, Medical醫學, 多模態模型, 影像處理, 模型, 框架, Dataset 數據集

RINO 用圖像編輯統一視覺任務

2026 年 7 月 16 日

RINO unifies vision under a single RGB interface: one frozen image editor, driven by a task-specific prompt, handles est

與其為每個視覺任務各自接駁 head、decoder 或 adapter，RINO 選擇更激進的路線：全部改寫成 RGB In, RGB Out。它屬於一個以 PyTorch 實作的研究型評測與實驗項目，核心問題是檢查單一凍結式 image editor，能否同時處理視覺理解與條件生成，而毋須為深度、segmentation、pose 之類任務另建模組。

這個定位帶來的吸引力很直接：流程統一、介面統一、後端也能互換。項目目前接上三個開源 image-edit 模型作為黑盒後端，包括 Qwen-Image-Edit、FireRed-Image-Edit 與 LongCat-Image-Edit；任務目錄結構一致，每個 task 都有獨立 evaluate 程式與 output 結果，方便逐項跑 benchmark，比起各任務各寫一套推理邏輯，整理與比較都省事得多。

但它的取捨同樣明顯。RINO 並沒有訓練新模型，也不做 fine-tuning，而是堅持用 released weights 直接測 zero-shot 表現；好處是比較乾淨，較能反映 image editor 本身的泛化能力，限制則是上限會被原生編輯模型綁住，對結構化輸出是否穩定、是否容易受 prompt 與渲染方式影響，仍要按任務逐個看。

重點不是追求單一任務最佳成績，而是測試「同一個 RGB 介面」能否橫跨多類視覺工作
三個後端可互換：Qwen-Image-Edit、FireRed-Image-Edit、LongCat-Image-Edit
採用 copied official metric code 評分，數字理論上較容易與既有文獻對齊
部署理解不複雜：安裝依賴後，按 task 準備 dataset，再選 BACKEND 與對應 MODEL 便可執行評測

較適合留意這個項目的，會是想研究 unified vision 介面、比較不同 image editor 泛化力，或者想把多個 benchmark 收攏到同一工作流的團隊。現有資訊未列出完整成績表，但它已清楚交代評測方法、資料夾規格與模型來源；作為研究驗證平台，價值在於提出一套可重覆比較的做法，而不是即刻取代每類任務的專用模型。

項目主頁 · GitHub

Categories: 開源, Qwen, Image, Python, 多模態模型, 影像處理, 模型, 模型訓練, Dataset 數據集

AMID 把醫學影像建模流程交畀代理協作

2026 年 7 月 15 日

醫學影像建模最麻煩的位，往往唔係只係揀網絡，而係每個任務都有唔同資料形態、指標、切分規則同提交要求。AMID把呢個痛點拉到枱面：它屬於一個 autonomous multi-agent framework，目標唔係產生一段建議文字，而係交出可訓練、可推理、可驗證、可提交的完整模型產物。

現有通用 MLE agent 往往沿用比較粗略的搜尋與試錯範式，先提方案、再寫碼、再靠結果反覆修補；作者認為放到醫學影像場景，呢種做法容易忽略資料條件、驗證協議同提交格式。AMID改用 Data-Conditioned Method Planning，先按任務資料與可運行資源整理出可執行的 method lanes，再用 Verification-Guided Two-Stage Optimization 由早期廣泛探索，轉去後期集中追蹤有潛力路線，同時持續檢查 metric computation、validation protocol 同 prediction artifacts。

呢種取向的差異，在於它把「做得出分數」同「流程可核對」放埋一齊處理。對醫療 AI 團隊、挑戰賽參賽者，或者要同時管理 2D 影像、3D volumes、segmentation masks、class labels 等異質資料的人，AMID的吸引力在於減少人手串接流程的時間；代價是它目前仍以技術報告與任務解法報告為主，README亦寫明 source code 尚未釋出，暫時未到可以直接部署測試的階段。

效能方面，AMID用 ReX-MLE 的 20 個 medical imaging challenge tasks 做基準，比較對象包括一般用途 MLE systems，同時拿 human-designed challenge solutions 作參照。作者指出它整體表現優於被評測的通用系統，部分任務接近或追平人手設計方案；現階段較適合把它理解成一套清晰的方法論與工作流藍圖，而唔係即裝即跑的開源工具。

核心定位係 autonomous multi-agent framework，處理醫學影像模型開發與驗證交付
主要方法包括 Data-Conditioned Method Planning 同 Verification-Guided Two-Stage Optimization
輸出唔止模型建議，仲包括 training code、inference code、weights、prediction files 同 audit trail
基準測試來自 ReX-MLE 的 20 個任務，整體表現優於通用 MLE systems
目前已公開 technical report 同 20 份 solution reports，source code 尚未發布

相關模型與系統脈絡方面，AMID直接對比的是 general-purpose MLE systems，同時以 human-designed challenge solutions 作為高水位參考。它未有把重點放在單一 backbone 或某個固定醫學影像模型，而是把多代理規劃、優化與驗證流程包成可重複的方法，呢點比單次調參工具更值得留意。

GitHub · Paper

Categories: 開源, 香港, 香港中文大學, 微軟, Agentic, Image, 3D, Medical醫學, 多模態模型, 影像處理, 模型訓練, Dataset 數據集, 框架

Page 1 of 20

1 2 3 … 20 Next »