AI线稿二值化阈值：过审图库QC的实战经验

一批60个AI线稿素材提交到Adobe Stock审核，一个下午就回来了——11个被拒，理由完全一致：描边边缘存在可见的灰色像素。同样的提示词、同样的导出器、同样的阈值设置，用了好几周都没出问题。直到我把被拒文件放大到800%才看清：每条线周围都有一圈近乎黑色的模糊光晕，而这正是审核员标记为"非干净矢量就绪素材"的东西。

那天下午的代价是一周的返工，也让我明白了一件事：二值化不是细节，它是决定你整批素材能否过审的关键步骤。以下是带具体数据的完整复盘。

为什么AI线稿天生"脏"

扩散模型输出的不是线条，而是看起来像线条的概率场。落到PNG里，就是一条核心值在RGB 20-40、边缘经过80、120、160一路衰减到背景的描边。在100%缩放下看是干净的黑白，但在图库审核员高倍放大检查时，就变成了低对比度的软边——多个平台都会将其判定为质量缺陷。

Adobe Stock的插画审核检查技术洁净度：伪影、噪点和看似机器劣化的边缘。Vecteezy和Dreamstime在各自的审核环节也做同样的检查。灰色光晕是AI线稿中最常见的伪影，也是选对阈值后最容易去除的一个。

扩散模型输出概率场的含义

要理解灰边问题，先要理解扩散模型实际输出的是什么。Stable Diffusion 一类模型在去噪过程中，每一步预测的是"当前像素属于某个内容的概率"，最终解码器将这些概率加权平均成像素值。因此，一条"黑线"在模型内部并不是一个边缘锐利的二值掩码，而是一个从线条中心（归属概率接近1、像素接近纯黑）向外逐渐衰减到背景（概率接近0、像素接近纯白）的连续场。采样步数越多、CFG 越低，边缘过渡越柔和；即便看起来"很硬"的线稿，放大后也会呈现几个像素宽的灰度过渡带。这正是灰度直方图上中间值（约80-200）不为零的根源，也是任何固定阈值都难以一刀切干净的原因：阈值的本质是把这个连续场"截断"，截断位置决定了灰边是保留在线内还是被切到线外。

真正有效的阈值策略

我在200个素材上测试了三个固定阈值，记录了各自的拒稿率：

• 阈值100（0-255范围）：线条偏细，浅淡细节消失。约14%的批次丢失了胡须线、内部细节线等小特征。
• 阈值160：灰色光晕存活。我那11个拒稿就来自这里——光晕像素落在120-155区间，160的阈值根本切不掉它。
• 阈值128：直觉上的中点值，表现更好，但柔软渲染下光晕仍会在约十分之一的文件中泄漏。

真正有效的不是某个神奇数字，而是两步处理：

1. 先对灰度图做自动对比度或归一化，让背景推向纯255、线条核心推向0。
2. 再在128处做二值化。归一化后光晕像素压缩到极窄的区间，128正好从中间干净地切过去。

对那11个被拒文件重新处理后全部通过；后续300个素材，边缘相关拒稿为零。

归一化为什么能把灰边"压扁"

自动对比度或归一化（如 OpenCV 的 normalize、PIL 的 ImageOps.autocontrast）做的事情是把整幅图的实际灰度范围线性拉伸到 0-255。原图中线条核心可能只到 RGB 30、背景只到 RGB 230，中间有80-200 一整段灰带；拉伸后核心被推到 0、背景被推到 255，原本宽达120个灰阶的过渡带被压缩到只有十几级，且集中在明暗交界处。这样一来，阈值就不再需要"精挑细选"——无论取128还是130，切出来的线宽差异都只有一两个像素，避免了对某个"魔法数字"的依赖。需要留意的是归一化对全图统一线性变换，因此对局部光照不均（例如扫描稿或带渐变的背景）效果有限，这种情况下应先做背景减除再归一化，否则暗角处的灰边仍会残留。

形态学处理：单靠阈值还不够

即使阈值干净，仍有两个问题会出现在审核中：背景里的孤立杂散像素（扩散噪声留下的灰尘），以及粗线条内部的针孔。我按以下顺序处理：

• 先用中值滤波或"去除小斑点"，消灭孤立的背景像素。
• 再对反转图像做去斑，闭合线条内部的针孔。

顺序很重要。如果在去尘之前就去斑，灰尘斑点会被焊接到附近的线条上形成小团块，比单独任何一个问题都更糟。

还有一个习惯：在低分辨率下检查，而不是高分辨率。渲染4000px预览来找光晕既浪费内存又不如600px缩略图有效——后者能让残余灰带表现为可见的浑浊。在我的1 vCPU、2GB内存机器上，把检查渲染从300 dpi降到60 dpi，峰值内存大幅下降，彻底不再触发swap。我用resource.getrusage(RUSAGE_SELF).ru_maxrss确认了内存上限而不是凭猜测，并让每个文件在独立子进程中处理，使重渲染在素材之间将内存归还给操作系统。

JPEG是二值图的陷阱

即使阈值完美，以默认质量保存为JPEG也会在每条线周围重新引入振铃伪影，因为JPEG用块变换编码边缘。审核员放大后看到的，就是你刚去除、又被导出步骤加回来的同一个模糊光晕。

修复方式很无聊：线稿存为PNG；如果平台强制要求JPEG，以质量95以上保存，并在上传前放大验证。我又因为这个问题损失了一小批文件——阈值没问题，是导出器把它毁了。

JPEG 振铃伪影的成因

JPEG 使用 8x8 的离散余弦变换（DCT）块编码。当一块内同时出现纯黑和纯白（正是二值线稿的典型特征）时，DCT 需要大量高频系数来近似这种近乎阶跃的边缘；量化步骤会丢弃部分高频信息，解码后重建的波形就在边缘两侧出现上下起伏——表现为黑白交界处多出一圈明暗交错的细纹，即"振铃"或"蚊噪"。质量参数越低，丢弃的高频越多，振铃越明显。对灰度线稿而言，这圈细纹恰好落在审核员关注的"描边边缘"区域，看起来就像你刚二值化掉的灰晕又回来了。PNG 使用无损压缩并保留精确像素值，因此是线稿的唯一安全选择；若平台强制 JPEG，把质量设到95以上只能减轻而非消除振铃，上传前仍应放大抽查。

把检查写进流水线，而不是靠眼睛

手动放大检查不可规模化。替代方案是机械化的、每文件毫秒级的检查：

• 二值化后统计灰色带（约60到200）的像素数。干净文件接近零；超过小阈值则标记为二值化失败，进入重试队列换阈值再处理。
• 验证直方图真正双峰：近黑和近白两个峰，中间几乎没有值。

这套自动检查让我能安心在小服务器上跑夜间批次。流水线一次处理一个进程，每个素材后调用gc.collect()，任何未通过灰带检查的文件进入重试队列而非上传目录。上传账本确保不会重复提交——双发是账号被标记的最快方式。

那次被拒批次还教了一课：保留原始输出。每个失败文件都是关于哪些提示词和设置能产生干净线条的数据点。我现在把研究笔记和抓取日志保存在固定的文件夹结构中，再也没删过原始批次。幸存下来的目录布局很简单：原始素材、待提交输出、成品包、研究资料，各自独立。

工具化与打包

以上全部已固化进我日常使用的工具链。Pipeline Starter Kit包含该流水线的四个脚本：一个元数据构建器，写入Adobe 5列、Vecteezy 4列和Dreamstime 15列CSV表头（这些平台会因为你写错表头而拒稿）；一个防重复提交的上传追踪器；一个Markdown转PDF转换器；以及一个打包器，生成带1280x720封面和600x600缩略图的产品zip。总共两个依赖，元数据和追踪工具仅用标准库，全部在1 vCPU、2GB RAM、无GPU环境下验证，打包了39个产品和856MB输出后才发布。

如果你正在为线稿或任何数字资产构建批处理流水线，这就是我希望第一天就拥有的打包层。