BG0:把抠图搬进浏览器,图片一步都不出本机

BG0:把抠图搬进浏览器,图片一步都不出本机

一句话概括:它把「AI 抠图」这件事从云端 API 拽回了你自己的浏览器——选图、推理、出透明 PNG,全程在本地内存里完成,服务端连你的图长什么样都不知道。

一个老问题:抠图为什么非得上云

给图片去背景是刚需中的刚需:电商换白底、做海报抠人像、给证件照换底色、把产品图塞进详情页。这两年工具也确实好用了,一键就能出透明 PNG。

但大部分工具的默认姿势是:把你的图传到一个别人的服务器上

这带来一串很具体的麻烦:

  • 图片上传要等,几百张批量处理时网络成了瓶颈
  • 涉及人像、证件、未发布的产品图时,上传前得先想想合规
  • 免费额度用完就要开会员,处理量和钱包直接挂钩
  • 断网、内网、弱网环境下基本没法用

更微妙的是心理层面的:你不知道那张图在对方服务器上待了多久、有没有被留下来——很多服务条款里,这句话是模糊的。

这就是 BG0 想绕开的东西。它的口号只有一句:

Background → zero.

去背景,核销归零。不上传、不注册、不限次。

BG0 是什么

BG0 是一个完全跑在浏览器里的开源抠图工具,TypeScript 写的,Apache-2.0 协议,由 OpenCore 组织开源。有可选的 WebGPU 加速,跑不动就自动退回 WebAssembly,最终产出一张带透明通道的 PNG,而原图从头到尾没有被上传过

它有几种用法:

  • 打开 bg0.dev 直接用,拖拽或粘贴图片即可
  • 断网也能用(模型首次下载后会缓存到本地)
  • 通过 @bg0/browser 这个 npm 包,把同一套私有流程嵌进你自己的 Web 应用

对于批量做图、或者要在内网环境里处理敏感图片的人来说,这个形态本身就很有吸引力。

为什么「本地」是关键

README 里有一节叫 Why local,把动机说得很直白:

  • 图片和派生出的像素始终留在浏览器内存里
  • 没有账号、没有 API Key、没有服务端推理、没有计费、没有次数限制
  • 浏览器按当前硬件自动下载一个固定版本(pinned)的 BiRefNet ONNX 模型,并缓存在本地
  • @bg0/browser 可以把同一套私有流程接进你自己的 Web 应用

这四条里,第三条其实是最有技术含量的:它没有把”本地推理”当成口号,而是按设备能力挑模型,让普通笔记本和老手机也跑得起来。

数据流:一条线,全在浏览器里

官方 ARCHITECTURE.md 画的数据流非常干净,没有分支、没有回传:

文件选择 / 拖拽 / 粘贴
        ↓
   @bg0/browser
        ↓
按硬件选出的 BiRefNet ONNX 模型
        ↓
     WebGPU / WASM
        ↓
 浏览器内存中的透明 PNG
        ↓
     下载 / 复制

主站应用 apps/web 只是壳,真正干活的全部在 packages/browser 里:能力探测、模型加载与缓存、预处理、ONNX 推理、蒙版后处理、alpha 合成、进度回报、取消、错误归一化。UI 代码不允许直接碰 ONNX 或模型内部——这条边界在架构文档里是写死的。

而且文档明确列了当前产品里没有的东西:没有控制面、没有数据库、没有认证系统、没有计费、没有托管推理服务、没有公开图片 API、没有 Docker 推理服务器、没有 CLI、没有 SDK、没有 MCP server。

对于一个”工具类”项目,能把”我没有做什么”列得比”我做了什么”还清楚,反而让人更放心。

模型选择:一次真实的工程取舍

BG0 最值得看的部分,是它怎么决定”用哪个模型”。

它会先真实探测一次 WebGPU 适配器,再决定优先尝试哪个模型。Chromium 浏览器如果报告支持 fp16 shader、256 MiB buffer 上限、128 MiB storage binding 上限,且没有低于 4 GiB 的内存提示,就会尝试完整的 BiRefNet;拿不到内存提示不会被排除在外。

其余情况的降级路径是:

设备情况 选择
低内存 + WebGPU 尝试 lite 版(Swin-T)
无可用 fp16 GPU,但 ≥4 逻辑核且内存不低于 4 GiB 在 WASM 上尝试完整 BiRefNet
iOS,或核心数更少 / 未知 选 lite 版
完整模型加载或推理失败 同 provider 回退到 lite,必要时再退到 WASM lite

模型权重和处理器配置都按 revision 固定,避免”今天能用明天就变”的问题。完整模型用的是打过补丁的 512px 导出版,lite 的 Swin-T 导出同样吃 512px 输入。

作者还很坦率地标注了验证范围:本地验证是在 Apple M4 Max / 64 GiB / macOS / Chrome for Testing 153 上跑通了 full 和 lite 的 WebGPU 与 WASM;低内存和纯 CPU 的选择逻辑是在同一台 Mac 上用模拟的内存提示验证的——其他真实设备、Safari、Firefox、线上域名都还没验证

这种”哪些是实测、哪些是模拟”的分开表述,在开源项目里并不多见,但很有用。

模型缓存:省掉第二次下载

在 HTTPS 环境下,它用浏览器的 Cache API 缓存模型文件;本地开发这种用不了 Cache Storage 的场景,会退回 BG0 自己实现的 IndexedDB 适配器。

细节上有两点做得挺讲究:

  • 同一个页面里的多次调用会复用已初始化的引擎
  • 刷新页面后可以复用已存的模型文件,但仍然要重新初始化 ONNX、把权重上传到 WebGPU

当然,浏览器清理存储、隐私模式、或者你手动清站点数据,都会导致重新下载一次——这是浏览器 Storage 的固有行为,不是它的锅。

隐私边界写进了代码

这一节是我觉得 BG0 最有意思的地方:它不满足于”我们承诺不上传”,而是把边界写进了架构约束和代码规则

  • 选中的图片字节、解码后的像素、蒙版、预览、输出的 PNG,必须留在浏览器内存;绝不允许进入 analytics、日志、错误上报或任何其他服务
  • 结果被清空时,object URL 会被 revoke
  • 浏览器只从静态模型托管地址下载模型文件,那个地址看到的只是一次普通的资源请求,拿不到图片或图片元数据
  • 它可以采集粗粒度的产品事件(比如”一次去背景完成了”),但这些事件不允许包含文件名、尺寸、大小、URL、像素或任何图片相关信息
  • PostHog 的表单提交在代码层面被限制为固定的质量评分选项和预定义的失败原因,配置里不允许加自由文本
  • 异常上报只用受控的错误分类同源的 JS 源码位置,任意异常消息和堆栈文本留在浏览器里

“承诺”和”约束”的区别就在这里:前者靠自觉,后者靠代码。把隐私要求变成不能违反的架构边界,是更硬的保证。

怎么用起来

浏览器里用最省事:bg0.dev,拖进去就行,不需要注册。

想自己跑起来,需要先装 Bun 1.4,然后:

bun install --frozen-lockfile
bun run dev

Web 应用跑在 3000 端口,文档站跑在 4321 端口;开发时 Web 应用会在 /docs 路径下代理到文档站。

提交代码前该跑的检查:

bun run lint
bun run typecheck
bun run test
bun run build

它还给回归测试配了一套浏览器布局检查bun run --cwd apps/web test:layout),用官方那张猫的样例图跑真实的模型推理,在 11 种视口宽度下验证导出控件、透明输出、下载、重置和非法上传。第一次运行需要联网拉模型。

如果你是想把它接进自己的项目,包层面的 API 简单到一行:

import { removeBackground } from '@bg0/browser'

const result = await removeBackground(file, {
  quality: 'quality',
  onProgress: ({ progress, message }) => console.log(progress, message),
})

const url = URL.createObjectURL(result.blob)

能力探测、模型加载与缓存、预处理、推理、蒙版后处理、alpha 合成、进度、取消、错误处理——这些全部由包内部负责,业务代码完全不需要了解 ONNX 的任何细节。这是一个设计得很干净的分层。

仓库结构

目录 职责
apps/web TanStack Start 站点 + 匿名的本地抠图界面
apps/docs Blume 文档站,部署在 bg0.dev/docs
packages/browser 可复用的 WebGPU / WASM 推理与 PNG 输出
ARCHITECTURE.md 运行时、隐私与部署边界

它用 Turborepo 管 monorepo,用 Biome 统一 lint 和格式化。去背景本身不需要任何后端

谁适合用

一、要处理批量图的运营和设计师。 没有额度、没有排队、没有上传等待。图片越多,本地方案相对云端的优势越明显。

二、处理敏感素材的人。 人像、证件、未发布的产品图——只要不上传,合规讨论就简单很多。BG0 的隐私约束是写进架构的,不是写在条款里的。

三、想给自家产品加抠图能力的开发者。 @bg0/browser 提供了完整的能力探测和降级链(WebGPU → WASM,full → lite),你不用自己踩 ONNX 和兼容性的坑。

四、内网 / 离线环境。 首次下载后模型被缓存,之后断网也能继续用。

值得注意的取舍

本地推理是有代价的,得说清楚:

首次使用要下载模型。 完整 BiRefNet 体积不小,第一次打开会有等待;之后靠浏览器缓存。急着处理一张图的人可能会嫌它慢。

效果受设备影响。 低端设备会退到 lite 模型或者 WASM,质量与速度都会打折。它选的是”能跑起来”,不保证每一档设备都是最优解。

验证仍不完整。 作者自己写了:Safari、Firefox、大型真机覆盖面都还没验证。现在主要是在 Chromium 系 + Apple Silicon 上被充分测过。上生产前最好先在自己的目标浏览器上实测。

能力上限就摆在那。 它专注做一件事——本地去背景。不做批量队列、不做高级蒙版编辑、不做云端批处理 API。想要全流程修图的人会觉得它”只有一招”。

但换个角度说,肯把一件事在浏览器里做透、还把隐私边界焊死在代码里,本身就是很清醒的产品判断。它不追求功能大而全,追求的是”这件事在我这儿做,你可以放心”。

项目信息

  • 仓库github.com/opencoredev/bg0
  • 在线使用bg0.dev(无需注册)
  • 可复用包@bg0/browser(npm,v0.1.2)· 文档
  • 协议:Apache License 2.0(模型权重遵循 THIRD_PARTY_NOTICES.md 中列出的各自许可)
  • 技术栈:TypeScript · WebGPU / WASM · BiRefNet ONNX · TanStack Start · Turborepo · Biome
  • 环境:浏览器端无需后端;从源码构建需要 Bun 1.4

如果你手头正好有一批图要抠,又不想把它们传给别人,BG0 值得点开试一张——最快的方式是断个网再试,你会发现它照样能用

© 版权声明
THE END
喜欢就支持一下吧
点赞15 分享
评论 抢沙发

请登录后发表评论

    暂无评论内容