InferNews

ComfyUI-OCIO：ComfyUI 直通 ACES 與 HDR 的色彩管理節點

Share to X

由模型輸出到 ProRes、EXR 或 HDR 交付，ComfyUI-OCIO 保留更多影像色彩與亮度資訊。

OCIO Nodes for ComfyUI - by AI VFX NEWS, Slava Sexton

由 LTX、Flux 或其他影像流程產生的 HDR、Cineon 及 10-bit 影片，可以在 ComfyUI 原生 VIDEO wire 內完成色彩管理、ACES 調色及輸出。ComfyUI-OCIO 屬於 ComfyUI 自訂節點項目，處理的是模型解碼後容易被截斷、降位深或轉成 4:2:0 的影像資料。

核心差異在於 OCIO VAE Decode 以 float32 解碼，而且不會把數值夾到固定範圍；低於 0 的值亦會保留，讓超出工作色域的顏色和場景線性動態範圍交由 OpenColorIO 轉換。普通 SDR 生成不會因取消 clamp 自動變成 HDR，素材本身沒有相關範圍時，收益亦會有限。

LTX-2.5 可經由 ACEScct 路徑接入其 HDR path，補足 ComfyUI 原生流程未能直接觸及的部分。輸出可包括 32-bit float EXR、ProRes 4444 10-bit 4:4:4、DPX log，以及 Rec.2100 PQ／HLG；FFV1 才能做到無損保存，ProRes 讀回則以 12-bit 處理並承載 10-bit 資料。

ComfyUI-OCIO 提供的單一 LTX-2.5 測試中，模型浮點母片有 2304 個亮度級別，該項目的 ProRes 4444 版本保留 3520 個可辨識級別，與母片可辨識差異為 0.0001%；原生 10-bit 流程則為 882 級，出廠流程只有 220 級。安裝所需依賴包括 OpenColorIO、OpenCV、tifffile、Pillow、numpy 及 FFmpeg，但資料未提供完整圖形化操作步驟；較適合熟悉 ComfyUI、ACES 和影片編碼的 VFX、影片生成及後期團隊。

  • 保留 float32 解碼結果，不強制限制亮度範圍
  • 支援 ACES、HDR、Cineon、LTX、Flux 及 10-bit 影片流程
  • 可在原生 VIDEO graph 內讀取序列、調色及寫出影片
  • LTX-2.5 可經 ACEScct 進入其 HDR path
  • FFV1 適合無損保存，ProRes 4444 適合交付

GitHub

Categories: 開源, ComfyUI, AI productions, Video, LTX

Diffusion Studio：智能影片剪輯工作流

Share to X

Diffusion Studio 將時間軸剪輯與 SolidJS 程式碼互相同步，讓 AI agents 可以直接協助製作影片。

Diffusion Studio

想用自然語言叫 AI 整理素材、剪出精華片段，甚至加入動態圖像和旁白，Diffusion Studio 提供了一條由命令列控制影片編輯器的工作流。它屬於開源影片編輯工具，核心是以 SolidJS modules 作為文件來源，處理由原始片段到成片的剪輯、合成和影片理解。

畫布與程式碼可以雙向修改：在畫布調整內容，變更會寫回程式碼；直接編輯程式碼，影片畫布亦會重新繪製。配合 dapi CLI，Claude Code、Codex、Cursor、Copilot 或 Gemini CLI 等 agents 能以文字指令操作時間軸，亦可要求系統摘要影片、搜尋場景，或找出附有時間戳的引述。

  • 影片剪輯、Motion graphics、社交平台短片重製
  • 以程式碼宣告圖片、影片和 voiceover，再合成到時間軸
  • 由命令列觀看及聆聽素材，交由 agents 協助處理
  • 可在 macOS Apple Silicon 使用桌面版本，並透過 skills 接入工作流

相比只在時間軸介面操作的編輯器，程式碼成為可保存、修改和交給 agents 處理的文件來源，較適合需要重複產出、批量改版或以生成式資產組成影片的團隊。代價是使用者要同時理解畫布、SolidJS modules 和 CLI 的關係；項目資料亦未提供獨立性能指標或完整平台支援範圍，不能單憑介紹判斷長片剪輯效率。

Diffusion Studio 連接 AI agents 之後可透過程式碼與影片時間軸進行編輯。內容創作者可先下載 macOS Apple Silicon 版本，再安裝官方 skills，透過自然語言要求建立影片，並在畫布中檢查結果；熟悉編程的團隊則可直接維護可重用的影片程式碼。

GitHub

Categories: 開源, Agentic, AI productions, IDE, Mac, 蘋果, Skill 技能

WeMM-Embedding：對齊文字、圖片、影片的多模態檢索

Share to X

騰訊微信視覺團隊把文字、圖片、影片、視覺文件等多種輸入收進同一個嵌入空間，推出涵蓋 2B／4B／9B 三個尺寸的 WeMM-Embedding 系列，主打檢索與多模態理解一條龍。

WeMM-Embedding Performance Overview

把文字、圖片、短影片、文件截圖一次過丟進同一個嵌入空間做檢索，一直是多模態團隊頭痛的工程難題。WeMM-Embedding 系列由騰訊微信視覺團隊開源，正是針對這個場景而來：三個規模（2B／4B／9B）都用同一套介面，輸出可直接比對的向量，免卻多模型串接的麻煩。

向量從模型最後一層的 <embedding> token 位置取出，再做 L2 正規化，方便直接接入既有向量資料庫。對想做跨模態檢索或 RAG 的團隊而言，這類統一模型比起同時維護 CLIP 系、BGE 系、影片模型幾套 pipeline，部署成本明顯較低。

官方推薦 transformers==5.2.0 以保證預處理一致性，亦支援 SentenceTransformer 直接載入 Hugging Face 模型 ID。比較有彈性的是 Matryoshka Representation Learning（MRL）：例如 9B 版本支援 64 到 4096 多段維度，開發階段可以用低維度快速迭代，再逐步切到高維度；2B 與 4B 版同樣提供 64 至 2048 左右的選項。已驗證 vLLM 0.27.0 與 SGLang 0.5.9 兩套推理引擎，兩者都以 pooling runner 啟動，搭配專屬的 chat template 即可提供 embedding 服務。

與同類開源嵌入模型相比，WeMM-Embedding 強調「影片與視覺文件也在同一個向量空間」，而不是只覆蓋到圖文。短影片摘要、PDF 截圖理解、社交媒體（X Demo）多模態內容推薦等場景，會比純圖文模型更貼地。音訊輸入目前不在支援範圍內，是規劃時要留意的限制。受惠對象包括做多模態 RAG、跨模態檢索、商品搜尋及內容審核的中小團隊，因為他們通常缺乏同時訓練多個專門模型的資源。

重點：

  • 統一嵌入空間：文字、圖片、影片、視覺文件、交錯輸入共用同一向量表示，免除多模型串接。
  • 三種規模：2B、4B、9B 同步開源，可在準確度與成本之間靈活取捨。
  • Matryoshka 維度彈性：支援 64 至 4096 多段可選維度，平衡儲存與效果。
  • 生態友善：兼容 transformers、SentenceTransformer，並已驗證 vLLM 與 SGLang 部署。
  • 目前限制：音訊輸入未支援，預處理對 Transformers 版本敏感，需固定在 5.2.0。

GitHub · 模型

Categories: 開源, 騰訊, AI productions, RAG, Embedding, 模型, Video, Image, Dataset 數據集

阿里巴巴 PAI 以 PDD 加速 MiniMax-H3 影片生成

Share to X

阿里巴巴 PAI 團隊把 MiniMax-H3 變成少步數就能出片的版本。你可以把它理解成針對影片生成速度做加速的 LoRA。

Og image

阿里巴巴 PAI 團隊針對 MiniMax-H3 做了 Parallel Decoding Distillation（PDD），目標是用更少推理步數完成影片生成。這份項目同時保留 MiniMax-H3 的兩條路線，分別對應 FL2VA 和 Ref2VA，方便按不同基礎版本套用加速 LoRA。

兩個官方 8-step Acc LoRA，檔名分別是 MiniMax-H3-FL2VA-Acc-8Step.safetensors 和 MiniMax-H3-Ref2VA-Acc-8Step.safetensors，兩者都標示 rank=64、network_alpha=64，並以 BF16 形式提供。這表示它們不是完整底模，而是掛在對應 base model 上的加速適配器。

8-step Acc LoRA 可配合 768p 生成流程，並對比 baseline、Turbo 4-step 版本和 8-step Acc LoRA。

實務上，8-step Acc LoRA 代表在速度和畫面穩定度之間做取捨，重點是把影片生成的推理成本壓低，而不是追求最長流程。相較原始 MiniMax-H3，這類 LoRA 的用途更偏向快速出樣和迭代，適合需要較短等待時間的影片生成工作流。

  • 開發團隊是 Alibaba-PAI，並以 MiniMax-H3 做 PDD 加速
  • 提供兩個 8-step 官方 Acc LoRA，分別對應 FL2VA 和 Ref2VA
  • 檔案以 BF16、rank=64、network_alpha=64 方式發布
  • 頁面有 768p Demo，但未交代 GGUF、mmproj 或硬體需求

項目主頁 · 模型

Categories: 開源, 阿里巴巴, AI productions, 多模態模型, 視頻模型, Video, MiniMax

TLive-Omni：專攻直播電商的多模態理解模型

Share to X

TLive-Omni 將影像、影片、語音和文字統一成文字輸出，特別適合要即時理解直播內容的場景。它同時處理商品畫面、聲音與對話脈絡，目標是減少直播電商裡資訊斷裂的問題。

logo

TLive-Omni 是一個多模態理解模型，針對直播電商場景，把影像、影片、語音和文字整合到同一個文字輸出介面。對做直播監控、商品理解、內容標註或客服輔助的人來說，它處理的是同一場直播裡多種訊號難以對齊的問題。

這個項目建基於 Qwen3.5 backbone，再接入 AuT audio encoder 和輕量 MLP 對齊層，並用 timestamped Per-vGrid 把聲音片段和對應畫面放在一起。它支援最長 256K tokens context，適合長時間直播流的連續理解，而不是只看單段截圖或單句語音。

訓練流程分三階段 SFT，先做語音與語言對齊，再擴展到完整多模態指令跟隨，之後加入 Faithful-RFT，強調回答要貼近直播場景的即時需要。README 亦列出聲音辨識、講者分析、商品視覺定位、文字辨識、時序定位、影片密集描述和 omni-modal QA 等能力，顯示它不是單一功能模型，而是面向直播任務的綜合型系統。

  • 4B 和 9B 版本都已公開，方便按算力和部署成本選擇。
  • 在直播電商的音訊、影像和影片任務上有不錯表現。
  • 對一般基準也有泛化能力，不只局限於單一場景。
  • 更適合需要長上下文、多訊號同步分析的團隊。
  • 取捨在於它很聚焦直播電商，未必是通用多模態助手的最佳替代。

整體來看，TLive-Omni 把直播場景最麻煩的訊號對齊、長上下文理解和即時回答放在同一條路徑處理，對做電商直播分析、內容審核和銷售輔助的團隊會更實用。它的價值不在於把功能堆滿，而在於把多模態理解收斂到直播工作流裡真正會撞到的問題。

項目主頁 · GitHub · 模型

Categories: 開源, AI productions, 多模態模型, Qwen, Video, Audio, 語音

[教學影片]MiniMax H3 六格分鏡生成多鏡頭 AI 影片

Share to X

MiniMax H3 加入六格分鏡網格參考功能，用戶可直接餵故事板圖，再生成多鏡頭連貫短片，解決單鏡頭 AI 影片動作細節不足的問題。

Og image

AI 影片生成最常見的痛點之一，是鏡頭內動作幅度細，剪接起來又欠缺段落感。MiniMax H3 這次加入的 6-Grid Reference（六格分鏡網格）功能，嘗試從輸入端就解決這個問題：使用者把一張包含六格分鏡的故事板圖丟入模型，H3 會按格子內容分別生成對應鏡頭，再組成一條多鏡頭短片，避免單次生成只能「前後郁幾吋」的局限。

對熟悉影視分鏡流程的人來說，這等於把前期 storyboard 直接搬進生成管線。對一般創作者而言，操作門檻也比逐個鏡頭獨立 prompt 再拼接低很多——畫好六格、寫好提示詞，剩下的運鏡與節奏交給模型處理。

以下是這次教學與功能值得留意的幾個重點：

  • 六格分鏡直接餵入：以一張 2×3 或 3×2 的網格圖作為視覺參考，模型按格生成對應鏡頭，無需逐個 cut 分開生成。
  • 多鏡頭連貫輸出：最終成品會包含多個 shot，而非單一長鏡頭，方便直接接上剪接流程。
  • 適合分鏡先行的工作流：對動畫短片、廣告腳本、遊戲過場等已有 storyboard 習慣的團隊特別受用。
  • 降低逐鏡 prompt 成本：一次輸入即可覆蓋多個鏡頭，減少重複描述角色、場景、風格的工序。
  • 與 H3 既有能力整合：可與 H3 的角色一致性與風格控制一併使用，保持多鏡頭之間的人物與美術統一。

教學影片示範的工作流程大致是：先準備好六格分鏡圖，每格代表一個鏡頭的構圖與動作重點，提示詞內描述場景氛圍與鏡頭運動方向，再由 H3 一次過輸出。對於想快速測試分鏡概念、或者要把動畫前期視覺化的人，這條工作流比起從零開始寫分鏡 prompt 更直觀。

需要留意的是，六格分鏡的格數、比例與每格內容差異會直接影響成品質素，每格的構圖與動作如果太擠迫或太模糊，模型理解鏡頭意圖時容易出錯。建議先用簡潔構圖測試，再逐步加入複雜元素。

影片主頁 • ComfyUI 工作流 • 特別版 H3 模型

Categories: 開源, ComfyUI, AI productions, 多模態模型, Video, MiniMax

[影片教學] 利用開源探索 3D 世界

Share to X

這個開源項目讓你用一張圖或一段文字 prompt，在本地免費生成可自由行走的 3D 世界，毋須依賴雲端服務。

Og image

過往要把一張圖變成可探索嘅 3D 場景，往往需要動用雲端 GPU 或者封閉式商業工具。一個新開源嘅世界生成項目反其道而行，主打「本地、免費、完全開源」，用家只需要餵一張圖片，或者寫一段文字 prompt，就可以產出一個可以行入去慢慢逛嘅 3D 場景。對遊戲開發、空間設計或者 VR 內容創作嚟講，呢種「零門檻起手」嘅流程可以省卻大量建模時間。

同一般文生圖或者文生影片模型唔同，呢類世界生成系統要處理嘅唔係單一畫面，而係保持視點一致嘅連續空間。背後通常會結合影像生成、深度估計同體積渲染（volumetric rendering）等幾組技術，再用 NeRF（Neural Radiance Fields，神經輻射場）或類近嘅 3D 表徵方式重建場景，等用家可以即時改變視角行入去睇。

對玩家嚟講，最直接嘅體驗係輸入一張京都街景相或者一句「霧夜嘅科幻實驗室」，幾分鐘之後就有一個可以操控角色行入去嘅小型世界；對開發者嚟講，由於整套工具鏈都係本地行得通，唔使擔心 prompt 或者素材被上傳到第三方伺服器，私隱同成本都較易掌控。

不過本地跑呢類模型對 GPU 仍然有要求，視訊記憶體唔夠嘅話生成時間會明顯拉長；另外世界嘅規模同互動深度仲未去到遊戲引擎嗰種水平，比較適合作為概念驗證或者素材起手稿，而唔係完整場景嘅最終方案。

以下係幾個值得留意嘅重點：

  • 支援圖生世界（image-to-world）同文生世界（text-to-world）兩種入口
  • 完全開源，可在本地離線運行
  • 採用神經輻射場或類近技術做 3D 重建，保持視角一致
  • 私隱同成本上比雲端方案更具優勢
  • 對 GPU 仍有要求，目前較適合做概念驗證階段

項目主頁

Categories: AI productions, 世界模型, Image, 影像處理, 教學, 3D

WeMM-Embedding 統一多模態向量

Share to X

WeMM-Embedding 把文字、圖片、影片和視覺文件放進同一套向量空間，適合要做檢索、比對和跨模態搜尋的場景。它同時提供不同尺寸選擇，方便在準確度與成本之間取捨。

WeMM-Embedding Performance Overview

WeMM-Embedding 是一組多模態 embedding 模型，目標是把文字、圖片、影片、視覺文件和交錯式多模態輸入，轉成可直接比對的統一向量。對要做搜尋、相似度比對、內容檢索或跨媒體匹配的團隊來說，這種做法比逐一分開處理不同素材更省事。

它提供 2B、4B、9B 三個版本，還支援 Matryoshka dimensions，代表可以按需要輸出不同長度的 embedding，減少計算和儲存成本。README 也提到，向量來自 <embedding> token 的最後一層 hidden state，再做 L2 normalization；目前不支援 audio。

實作和試跑方式都算直接，既可以用 transformers，也可以用 SentenceTransformer 直接載入 Hugging Face 模型 ID。作者同時標明推理較建議用 transformers==5.2.0，原因是較新的版本在前處理行為上可能有差異；serving 方面則測過 vLLM 和 SGLang。

  • 統一處理 text、image、video、visual document 和 interleaved multimodal inputs
  • 支援 Matryoshka dimensions，可按成本需要縮短 embedding 長度
  • 適合做跨模態搜尋、內容去重、相似度比對和檢索索引
  • 推理可用 transformers 或 SentenceTransformer，部署可接 vLLM、SGLang
  • 現階段不支援 audio，做語音相關流程要另配其他模型

對要處理多媒體內容的應用團隊、檢索系統、內容平台和資料整理流程，這類模型最直接的價值是減少多套表示法之間的銜接成本。它在多個基準上取得領先結果，但實際選型仍要看你要的是完整維度、較低成本版本，還是偏向部署效率的配置。

GitHub · 模型

Categories: 開源, 騰訊, AI productions, Embedding, 模型, 多模態模型, Video, Image, Audio

ComfyUI-MiniMaxH3-Contex-Loop：讓 MiniMax H3 多場景影片可重試續作

Share to X

把多場景影片拆成可審核、可重試的製作流程，減少一次渲染失敗便要由頭再做的浪費。

MiniMax H3 Contex Loop v0.5 — scene plans that survive the render

多場景影片最麻煩的地方，往往不是生成單一鏡頭，而是其中一幕出錯後要重做整段流程。ComfyUI-MiniMaxH3-Contex-Loop 是一套開源 ComfyUI 工作流工具，利用一個可重用的 sampling body，按 scene Plan 逐幕生成 MiniMax H3 影片，並把已接受的片段從磁碟組合起來。

每個場景都可以獨立設定提示詞、seed、時間、圖片、動態影片及音訊參考；Review Gate 會讓使用者選擇批准、重試、reroll 或提早停止。candidate_count 亦可為單一場景生成多個候選，最後由使用者揀選指定 take，減少整條工作流反覆排隊的成本。

  • 支援中斷後 resume、partial assembly 及 atomic checkpoints
  • 可延續現有片段，處理 inpainting 和 two-ended bridges
  • Guide 與 protected AV-prefix transitions 有助維持畫面、動態及聲音連接
  • 支援 latent-to-PNG export，並可從已儲存資產恢復製作

v0.5 要求較新的 ComfyUI，包含原生 Add Guide for MiniMax H3。FFmpeg 放在 PATH 會較方便，沒有時可由 ComfyUI 內置 PyAV 處理 review 和 assembly，因此硬件、模型配置及渲染時間仍然是主要限制。倉庫目前以 main 作為支援的 0.5 發行線，已儲存的 0.4 workflows 和 checkpoints 仍然支援，較適合把生成流程分段管理的影片創作者及技術團隊。

GitHub

Categories: 開源, ComfyUI, AI productions, Video, Image, 框架, MiniMax

OpenChatCut：讓 Agent 編輯真正時間軸影片工具

Share to X

將 AI 代理直接接入影片剪輯流程，讓文字指令可以落到可編輯的時間軸。它同時保留多軌音訊、字幕、轉場與特效，適合想把剪片交給代理協作的人。

OpenChatCut

OpenChatCut 是一個本地優先的 AI 影片編輯工具，核心不是產生一段成品影片，而是把文字指令轉成可繼續修改的真實項目。AI agent 可以直接讀、改、匯出同一條時間軸，剪輯結果不會鎖死在單次生成裡。

它把代理工作流和傳統剪輯介面接在一起，支援多軌影片與音訊、轉場、特效、LUTs、縮放、關鍵幀、逐字稿剪輯、停頓處理、講者分離，以及連動字幕。換句話說，AI 不是只幫你寫文案，而是能進一步影響鏡頭切分、節奏和素材編排。

項目比較像一套框架加編輯器的結合，使用場景偏向需要反覆修正的影片工作，而不是一次過生成完就收工。它的取捨也很明顯：功能面走向完整時間軸與多代理共用工具，代價是整體更接近真正剪輯流程，學習成本自然高過單純的聊天式影片工具。

  • 支援 agent-native 工作流，內建 agent 和外部 MCP agents 共用同一組編輯工具
  • 保留 real timeline，方便逐格調整而不是只看輸出成品
  • 逐字稿驅動剪輯，適合訪談、Podcast、教學片段等內容
  • 可處理圖片、影片、語音、音樂、音效與線上媒體搜尋
  • README 標示為 active development，較適合願意接受快速迭代的人

從目前資料看，OpenChatCut 對內容團隊、獨立創作者、以及想把 AI 代理納入剪輯流程的人最有吸引力。它不是替你省掉所有剪輯工作，而是把最花時間的整理、切段和反覆修改，搬進一個仍可手動接手的項目裡。

GitHub

Categories: 開源, Agentic, AI productions, MCP, Video
Page 4 of 10
1 2 3 4 5 6 … 10