FilmOps 將電影語言拆成可分析標籤

FilmOps logo

一段影片好不好,不一定只靠整體觀感判斷;鏡頭遠近、構圖、機位、色調同運鏡,往往先係影響觀感的核心。FilmOps 正正瞄準呢個缺口:它不是一般影片生成模型,而是一套開源 operator suite,用來把影片畫面映射成結構化的 cinematographic labels,處理的是電影語言難以被細緻分析與量化的問題。

現有影片 benchmark 多數集中在 general perceptual quality、text alignment 或 temporal smoothness,對專業 cinematographic language 仍然偏粗略;general-purpose MLLMs 又難以穩定辨認 film-specific attributes,而 aesthetic predictors 這類領域模型面對 cinematic content 亦有明顯 domain gap。FilmOps 的取向很清楚:不用單一大模型包辦所有判斷,而是把六個維度拆開,按任務特性分配不同 backbone,令 shot scale、composition、camera angle、color & tone、character layout 同 camera movement 可以分別處理。

它的價值在於更像一套分析管線,而不是只給你一個總分。項目覆蓋 55 個以上子類別,分類定義對齊 Film Art、ASC Manual、Cinematography: Theory and Practice,亦經過 practitioner 驗證;加上 modular architecture,可以獨立用單一 operator,或者走 unified pipeline。對要做影片生成評測、鏡頭標註、資料整理,甚至研究 FilmBench 呢類 cinematic benchmark 的團隊,這種拆解方式會比泛用多模態評分更有解釋力。

  • 屬於開源工具/模型組合,重點是把影片拆成電影語言標籤,而不是直接生成影片
  • 六個 operator 採用 task-specific backbone,包含 DINO ViT-B/14、BEiT Base、ResNet-18、InternVL3-14B
  • 支援 live-action、3D animation、2D animation 同 stylized content,強調 cross-genre consistency
  • 已交代基本部署條件,包括 Python、PyTorch、CUDA 與 ffmpeg,也提供 unified pipeline 與 checkpoints 準備方向

現有資料只明確指出它在所有維度都勝過 general-purpose MLLMs,但細節主要放在論文。配套的 FilmBench 亦用同一套 Cinematic Language 思路建立 benchmark,並聲稱 evaluator 在模型排名上與人工評分高度一致,說明 FilmOps 並非只為展示而做,而是服務整個影片評測流程。不過它始終偏向分析與標註基建,想直接拿來做完整產品,仍要自行處理 checkpoints 下載、推理資源,並接受部分 operator 對 CUDA 與較重模型的依賴。

GitHub · Paper

Categories: 開源, 阿里巴巴, Gemini, NVIDIA, 3D, AI productions, Python, 動畫, 多模態模型, 語音, Dataset 數據集

DriveDNA 將駕駛風格拆清楚

DriveDNA teaser

不少駕駛模型聲稱識別「駕駛風格」,但一換車款、路線或交通情境,學到的可能只是車主習慣路段與車輛特性。DriveDNA屬於多模態自然駕駛數據集與 benchmark,核心不是再加一批行車資料,而是把「邊個人在開車」與「開緊咩車、行緊邊條路」分開檢驗,直接處理個人化駕駛建模最常見的捷徑問題。

現有公開資源不是樣本太細、就是把車輛與路線幾乎固定,於是高分未必代表模型捉到穩定的個人風格。作者的做法更像重新定義評測:資料來自 465 位司機、115 款車、4,121 段駕駛,保留 CAN telemetry 與前向道路影片,並移除 automation-engaged frames,只留下 human-controlled driving,再配合 frozen evaluation protocol 與 leakage probes,要求研究者同時報告效用與洩漏風險。

它的價值在於評測不只看 re-identification 準唔準,還加入 personalized behavior prediction,以及在條件匹配下比較風格是否仍然存在。論文亦講得很直白:高 re-ID 可能只是 route leakage,能認出司機,不等於對未來行為預測更有幫助;相比只追單一識別分數,DriveDNA更重視模型有沒有學到可遷移、可解釋的駕駛表徵。

  • 規模夠大:465 位司機、975 小時 human-controlled driving、4,121 段駕駛
  • 模態完整:10 Hz CAN telemetry 配合同步前向道路影片
  • 評測設計針對混淆來源,明確檢查 vehicle、route、condition leakage
  • 倉庫已附 code 與 harness,但提供的是 benchmark 與研究流程,不是即插即用產品

私隱與資料治理亦寫得仔細:司機身份用 salted hashes,移除 VIN、裝置識別碼與 GPS,沒有車廂影片與音訊,受控影片版本會模糊人臉與車牌,並禁止 re-identification 與保險、就業、執法評分用途。較適合自動駕駛、駕駛行為建模、VLA 與多模態學習團隊拿來做表徵比較與洩漏檢查;現有資訊可確認倉庫附有 code & harness,但未見完整產品化安裝流程,重點仍是研究 benchmark 與可重現評測。

GitHub · Paper

Categories: 開源, 多模態模型, Dataset 數據集, VLA

ARI 用 RAG 修復韓國朝鮮古籍殘字

Method Figure

最值得留意的,不是模型把缺字補回來本身,而是它專門處理古籍修復最棘手的一類內容:人名、地名等 Named Entities。ARI 屬於一個結合 Retrieval-Augmented Generation(RAG)的文獻修復框架,針對朝鮮王朝實錄與承政院日記這類韓文漢字史料,補足只靠局部語境時經常失準的缺口。

現有做法多數依賴 masked language modeling,擅長根據前後文猜測一般字詞,但一遇到需要外部史實支持的專名就容易失手。ARI 的取向很清楚:先用 BM25 從歷史語料找出前 20 份相關文本,再以字串相似度 0.8 過濾重複內容,將這些外部證據交給模型一併生成,修正通用 LLM 容易出現的幻覺。

模型部分不是從零開始,而是建基於 Qwen3 32B 與 Qwen3 8B 微調成 ARI-32B 和 ARI-8B,並加入 25% named entity-prioritized masking 訓練策略,把學習重點放在知識密集片段。論文亦指出,對漢字材料而言,詞彙層面的 BM25 檢索比 embedding-based retrieval 更有效,這一點頗有說服力,因為表意文字的字形與字詞對應關係本身就影響檢索效果。

  • 適合歷史文獻整理、數位人文研究與古籍校勘團隊參考
  • 主要強項在於修復需要外部知識支撐的 Named Entities
  • ARI-32B 與 ARI-8B 同步提供,前者追求表現,後者較重視運算成本
  • 論文結果顯示,它在 named entity 與隨機遮罩字元修復都勝過多個基線與通用模型

把它視為一個已有公開模型與方法說明的研究項目。對需要先驗證效果的人來說,現階段較合理的路線會是先查看論文設定與模型頁面,再判斷是否足以接入自己的古籍修復工作流。

項目主頁 · GitHub · Paper

Categories: 開源, Qwen, Embedding, RAG, 模型, 語音, Dataset 數據集

CrossView 用 3D 數值控制鏡頭:LTX-Video 跨視角生成

Og image

想將一段現成影片改成另一個鏡頭角度,又唔想主體變樣或空間關係散掉,這正是此模型處理的問題。它明確基於 Lightricks/LTX-2.3,屬於 LTX-Video 2.3 22B 的 IC-LoRA 微調,重點不是純文字改鏡頭,而是用輸入影片加相機偏移數值,重建同一場景的新視角。

頁面提供的做法幾清楚:模型同時接收兩段參考影片,一段是由 CrossViewWarp ComfyUI node 產生的 depth-warp 影片,用來保留幾何結構;另一段是原始影片,用來維持主體 identity。這種雙參考分工,反映它優先解決「換角度後仍要似原片」的取捨,比單靠 prompt 描述鏡頭更穩定。

它與同作者的 CrossView Prompt LoRA 差異亦很直接:後者由文字提示選鏡頭角度,這個版本改為輸入 azimuth / elevation / distance 等數值,所以鏡頭控制更精確。頁面亦提到可以在 3D orbit picker 加 keyframes,逐幀插值相機姿態,代表不只可做固定新視角,也可做繞拍式 camera move。

  • 基礎模型已標明為 Lightricks/LTX-2.3,授權為 Apache-2.0
  • 主要檔案是 LTX2.3-22B_IC-LoRA-CrossView-Warp_v0.9_18000.safetensors
  • 依賴 ComfyUI-CrossViewWarpDepth Anything V2 節點提供 depth 輸入。
  • 示例包含固定視角偏移與 keyframed 軌道鏡頭,並說明輸出來自真實影片而非合成訓練片段。

這個項目目前仍是 PoC,它較偏向 ComfyUI 工作流驗證,而不是通用本地大語言模型部署。

模型

Categories: 開源, ComfyUI, Video, 3D, AI productions, 視覺模型, 視頻模型, LTX

Ollama 3.25 把開源模型帶回你部機

Repository image for ollama/ollama

想將開源模型放返本地處理,又要兼顧聊天、程式整合同 agent 工作流,Ollama 幾乎係目前最直接的一條路。它屬於模型執行與管理工具,核心作用係將本地大語言模型的下載、啟動、呼叫同整合收斂到同一套介面,令 Mac、Windows、Linux 甚至 Docker 部署都比較一致。

它吸引人的地方不只是可以對話,而係可以直接接去 Claude Code、OpenClaw、Codex、Copilot 等現有工具鏈。換句話說,Ollama 唔係只提供一個聊天殼,而係充當本地模型服務層;你可以用 CLI 跑模型、經 REST API 調用,亦可以配合 ollama-python、ollama-js,或者再接 Open WebUI、LibreChat、Lobe Chat、NextChat、Perplexica 呢類前端與應用。

同類做法入面,Ollama 的取向好清楚:它唔著重花巧介面,而係先處理「點樣穩定喺本地把模型跑起來,再供其他程式使用」呢件事。背後支援 llama.cpp,意味住它承接咗本地推理生態的成熟基礎;代價亦存在,本地效能仍然受你部機的記憶體、GPU 與模型大小限制,追求大型模型或高併發時,就未必有雲端服務咁輕鬆。

  • 安裝路徑完整,覆蓋 macOS、Windows、Linux 同 Docker,理解上可以當成一個本地 AI 服務。
  • 既可直接 run 模型聊天,亦可透過 REST API、Python、JavaScript 接入現有項目。
  • 跟 Claude Code、OpenClaw、Codex、Copilot 等整合,適合做本地 agent 與開發工作流。
  • 配合 Open WebUI、LibreChat、Lobe Chat、NextChat 等,可快速補上可視化操作層。

較受惠的一群,會係想保留資料喺本地的開發者、需要快速測試開源模型的團隊,以及想把 AI 能力嵌入內部工具的人。就產品定位而言,Ollama 最有價值的地方,係將「本地跑模型」由零散步驟變成可重用的基礎設施。

項目主頁 · GitHub

Categories: 開源, Agentic, API, Linux, Mac, Ollama, Python

TBSM 想把一步生成變得更實用

TBSM one-step samples across handwritten digits, fashion items, CIFAR-10, ImageNet, and text-to-image generation.

生成模型一路追求更快出圖,但速度一提升,訓練往往就變得更複雜。TBSM 把焦點放在one-step generation,而且唔係靠 adversarial critic、teacher queries,亦唔需要 batch-wide all-pairs field 去撐住整個流程;它屬於生成模型方法,處理的是怎樣用較直接的監督,把一次生成做得可訓練又可擴展。

這個項目的判斷重點,在於它不只是講快,而係試圖避開幾條常見路線的代價:GANs 容易受 adversarial min-max objective 影響,AR / Diffusion 要逐步解碼或反覆採樣,Drifting Models 會受 batch 規模拖高成本,diffusion distillation 又常常連帶額外模型、loss 或訓練技巧。TBSM 用 three-body scattering 連到 distributional energy,目標是把分佈層面的學習,壓成 sample-level supervision,令一步生成唔使再背住咁重的系統負擔。

它已展示多種資料與輸出空間,包括 handwritten digits、fashion items、CIFAR-10、ImageNet,以及 1024×1024 的 text-to-image。這代表它較像研究型項目而唔係即裝即用產品:你會先從 paper、示意圖與 quick start 去理解訓練與生成流程,再按資料集或任務類型測試效果,較適合有模型訓練環境的研究團隊、影像生成項目,或者想研究 one-step generation 取捨的人。

  • 核心賣點是一跳生成,不靠多步採樣換品質
  • 設計上避開 adversarial critic、teacher model 同 batch 全配對成本
  • 已展示多個資料集與 text-to-image,覆蓋面比純玩具示範更廣
  • 現階段更接近研究實驗框架,部署前要先消化方法與訓練設定

它吸引人的地方,在於把「生成速度」同「訓練系統複雜度」一齊拉入取捨表,而不只是追某個指標。現有資訊未見完整效能數字與部署細節,表示讀者現階段應把它看成值得追蹤的生成模型研究方向:概念清晰、定位明確,但要判斷是否適合生產環境,仍然要等更完整的評測與開源內容。

GitHub

Categories: 開源, Qwen, Image, txt2img

JoyAI-Image 想做懂空間的影像模型

Repository image for jd-opensource/JoyAI-Image

改圖最怕模型聽得明文字,卻改壞原本場景結構;生圖亦常見字排得唔準、物件關係走位。JoyAI-Image就係朝住呢個痛點落手,定位屬於多模態基礎模型,把影像理解、text-to-image 生成同指令式編輯放入同一個模型家族,重點處理空間理解不足帶來的失真與失控。

唔係把理解模型同生成模型鬆散拼埋,而係用 8B Multimodal Large Language Model (MLLM) 配 16B Multimodal Diffusion Transformer (MMDiT),強調理解、生成、編輯之間的閉環協作。換句話說,模型唔只讀圖後再畫圖,仲會利用視角變換等生成結果反過來補強空間推理,呢點令它在 grounded generation、關係定位同可控編輯上有更鮮明方向。

現有公開內容顯示,部署路線算完整,已提供 Hugging Face 權重、Diffusers 版本、ComfyUI 原生支援,同埋可直接參考的 workflow;另外亦有 Spatial Edit 同 General Edit 示範空間。對內容製作、電商視覺、設計流程或者研究多模態編輯的人,較值得留意的是它不只處理單次修圖,仲想處理長文字排版、版面忠實度、多視角生成,以及「指定物件移去指定位置」呢類容易出錯的操作。

JoyAI Image Edit Plus in ComfyUI - How Does it Compare?
  • 把理解、生成、編輯整合到同一條多模態流程
  • 核心賣點係較強的 spatial intelligence,而不只是畫面更靚
  • 已有 Diffusers 與 ComfyUI 兩條使用路線,測試門檻較研究原型低
  • 延伸到 OpenSpatial data engine 同 OpenSpatial-3M dataset,反映它連資料與訓練配方都一併公開

效能方面,儲存庫描述集中在能力展示與訓練設計,現階段較適合把它理解成一個方向清晰、工具鏈逐步成熟的開源影像模型項目。最吸引之處唔係單一指標,而係它把空間理解當成生成與編輯的核心能力,對需要更穩定版面、關係同位置控制的工作流,確實比單講畫質更實用。

GitHub · 模型

Categories: 開源, Qwen, ComfyUI, Image, txt2img, 多模態模型, 模型, 視覺模型, Dataset 數據集

FinanceComplexQA 點評:金融長文件問答基準

Finance-ComplexQA at a Glance

金融問答最容易失真的位置,不是模型識唔識術語,而是它會否真正在整份參考文件入面推理、比對同計數。FinanceComplexQA屬於數據集/Benchmark,焦點不是背答案,而是檢驗 LLMs 和 agents 能否根據完整 reference documents 回答複雜金融問題。

它修正了只靠 parametric knowledge 或抽取單一段落的評測範式。作者把重點放在 document-grounded complex financial QA,要求答案同問題及原始文件一致,並涵蓋 multi-hop reasoning、numerical calculation、comparison、implicit inference、planning、summarization 同 evidence-grounded verification,對 RAG、Agentic workflow 同長文本閱讀能力都有參考價值。

資料結構本身亦有取捨。FinComplexQA-Pro 收錄 2,026 組獨立 QA,按語言、金融場景與任務分類組織;同一題會以 scene_categories 與 task_categories 兩種視角出現,所以總記錄視圖有 4,052 筆。另有 overall 提供 agent_answer、agent_thinking 及 LLM-as-a-judge 分數,但這些分數只適合做診斷訊號,不能當 ground truth。

  • 支援中文與英文,但兩個子集覆蓋的文件領域不同,schema 亦不完全一致
  • 較適合逐個子目錄讀取 JSONL,而不是一開始合併全部資料
  • 可用 exact match、數值容差、F1、semantic similarity 等方法比對輸出
  • 附有 Reference_documents,方便追查 PDF 與 LaTeX 原文證據

部署和測試的理解方式相當直接:資料主要在 Hugging Face 發佈,研究團隊可先挑單一語言、單一 task category 載入,再把模型輸出對照 gold answer 或文件證據做評估。它較受惠於做金融 RAG、長文件 QA、Agent 評測或雙語研究的團隊;要留意的是金融事實具時效性,而且項目已明確標示僅供研究與評估,不應延伸成投資、會計、法律或財務建議。

項目主頁 · GitHub · Paper

Categories: 開源, 微軟, DeepSeek, Agentic, RAG, 多模態模型, 中國, Dataset 數據集

Sana 把高解像生成壓到快 100 倍

logo

高解像圖片同影片生成最常見的卡位,不是效果做不到,而是算力、延遲同部署成本太難接受。NVlabs/Sana 屬於生成模型代碼庫,集中處理這個矛盾:在維持高解析輸出的前提下,把訓練與推理做得更省、更快,並且一路延伸到圖片、影片、世界模型等多條分支。

這個項目唔係單一模型,而是一個家族。SANA 主打最高到 4K 的 text-to-image,README 直接給出「比 Flux-12B 細 20 倍、快 100 倍」的定位;SANA-1.5 進一步處理訓練期與推理期的 compute scaling;SANA-Sprint 則把重點放在 one/few-step 生成,官方數字提到 H100 上 1024px 圖片可做到 0.1 秒級。取向很清楚:不是一味追最大模型,而是用效率換取更可部署的生成流程。

影片部分同樣值得留意。SANA-Video 與 SANA-Video 2.0 把焦點放在 720p 長序列生成,做法上用 hybrid linear attention 配合 Attention Residuals,目的是減少 full-softmax attention 的成本,同時盡量保住畫質與長序列表達能力。公開資料提到 SANA-Video 2.0 在單張 H100 上,720p/5 秒影片可做到 13.06 秒,VBench 總分 84.30,也強調比 Wan 2.2 14B 有大幅速度優勢,但這類數字仍要連同硬件、步數與設定一齊理解。

  • 同一庫內含 SANA、SANA-1.5、SANA-Sprint、SANA-Video、SANA-WM、SANA-Streaming、Sol-RL
  • 提供完整 training 與 inference pipeline,唔止展示模型效果
  • 可透過官方 demo、Hugging Face、ComfyUI 整合去理解生成表現與部署方向
  • 重點不是極限參數量,而是高解像生成的速度、成本同可擴展性

部署與測試路線相對清晰:已有官方文件、網頁 demo、Hugging Face 集合,亦見到 ComfyUI、SGLang、Replicate 等接點,代表它較適合研究團隊、影像工作流開發者,以及想把高解像生成放進產品流程的人。 SANA-WM 的 2.6B controllable world model、6-DoF camera control,同 Sol-RL 的加速收斂能力,則顯示這個項目不只做靜態出圖,而是朝更完整的生成系統推進。

項目主頁 · GitHub

Categories: 開源, NVIDIA, ComfyUI, Stable Diffusion, Video, Image, AI productions, txt2img, 模型訓練, 世界模型

SoulX-Singer 把零樣本歌聲合成

SoulX-Logo

做歌聲生成,最難往往唔係「唱到」,而係未見過的聲線仍然要自然、準音、像本人。SoulX-Singer正是朝住呢個矛盾而來的開源模型項目,重點放在 zero-shot singing voice synthesis:唔使為每位歌手再微調,都可以用參考聲線配合旋律或樂譜生成歌聲。

它的定位幾清楚:一邊照顧創作控制,一邊盡量保住音色身份。你可以用 melody-conditioned 的 F0 contour 控制音高走向,亦可以用 score-conditioned 的 MIDI notes 對齊節奏與音符;對於需要改詞、換語言、保留同一把聲去做 demo、作曲草稿或虛擬歌手內容的人,這種控制方式比只靠文字描述更實際。README 亦提供 Hugging Face 模型與線上示範,部署理解上屬於下載預訓練權重後做推理的典型流程。

同類做法常見取捨,是控制愈細,聲線就愈易散;複製音色愈強,跨語言和改詞後又可能變得生硬。SoulX-Singer把 timbre 與 content 盡量拆開處理,目標是讓 Cantonese、Mandarin、English 之間仍能維持歌手辨識度,這點比單純追求「像真」更有產品意味。項目另外還有從 SoulX-Singer 微調而來的 SoulX-Singer-SVC,處理 singing voice conversion,直接由原始歌聲音訊轉換成目標歌手風格,連歌詞或 MIDI 標註都可省去。

  • 支援 F0 contour 與 MIDI 兩種控制,適合作曲草稿與精修流程
  • 主打 zero-shot,未見過的歌手聲線都可生成,減少逐人微調成本
  • 42,000+ 小時對齊人聲資料覆蓋 Mandarin、English、Cantonese
  • 可做改詞編修與跨語言合成,同時維持音色一致性
  • 另設 SoulX-Singer-SVC,補上 audio-to-audio 轉換場景

現有資料未完整列出量化指標細節,但項目已公開技術報告、arXiv 與示範頁,代表它不只停在概念展示。對音樂 AI 團隊、虛擬歌手內容製作、語音與歌聲研究者而言,SoulX-Singer吸引之處在於它把可控性、跨語言與免微調三件事放入同一條生成鏈,而限制則仍要留意倫理風險、聲線授權,以及最終作品是否需要後期混音補足細節。

GitHub · 模型

Categories: 開源, Audio, 模型, 聲效, 音樂

Page 4 of 66
1 2 3 4 5 6 66