前言
最近女朋友彻底迷上拼豆了。
工作日下班拼，周末直接泡拼豆店，属于实打实的上头状态。拼得多了我发现，耗费时间最多的反倒不是动手拼的过程，而是找图纸。网上现成的拼豆图纸数量有限，尺寸、色号、画风未必合心意。她想复刻一张自己喜欢的图，往往要翻很久资源。
我当时扫了一眼需求：不就是把图片缩成格子，每个格子匹配对应拼豆颜色吗？感觉花半天时间就能撸出一个工具。于是动手写了个拼豆图纸生成网站：https://webfem.com/tools/pindou/，英文版本：meltbead
真正上手开发才明白，这件事远不止简单缩小图片这么轻松。
一张普通图片能够拥有上百万种色彩，可拼豆实物只有一百多种固定色号；原图里过渡自然的渐变，落到拼豆板上，很容易变成满屏杂乱噪点；数学计算出来的平均色看着逻辑通顺，实际效果却会把黑色轮廓和粉色皮肤糅合成一块脏兮兮的灰调。
这个工具前后迭代了好几个版本，下面主要聊聊v3版本的算法逻辑。这一版的处理链路已经比较完整，又不至于过度晦涩，刚好可以拆解开发中遇到的各类现实问题。
要解决什么问题
输入一张普通图片，输出固定行列的格子图纸。每一格只能放置一颗拼豆，豆子颜色必须选用市面真实在售的色板。
换句话讲，算法的目标不只是让输出结果视觉上贴近原图，还要兼顾一堆现实约束：
- 格子总数有限，原图细节没办法全部保留；
- 颜色只能从现成拼豆色号里挑选，不能凭空生成任意RGB色彩；
- 最终用到的颜色种类不能过多，不然采购豆子、动手拼制都会十分麻烦；
- 原图连续的渐变效果，需要转化为离散色块，同时不能糊成一团；
- 生成的图纸要具备可制作性，不能到处散落孤零零的零散豆子。
所以我对这个任务的定义，并不单纯是图片像素化，而是：在格子数量、可用色板、用色总量多重限制下，尽可能保留原图辨识度最高的关键信息。
v3完整处理流程大致如下：
原图
→ 判断是实拍照片还是平涂插画
→ 根据目标格子数对图片做分块切分
→ 计算每一个格子的代表颜色
→ RGB色彩转换至Lab色彩空间
→ 使用Median Cut算法生成初始颜色簇
→ K‑means算法迭代优化颜色中心点
→ 将计算出的颜色映射为真实拼豆色号
→ 合并近似色彩，清理画面细碎杂点
→ 输出可用的拼豆图纸
单独拆开每一步来看都不算新奇，麻烦在于各个环节会互相牵制。前面处理时丢掉一条轮廓线条，后面再精巧的算法也补不回来；后期降噪清理力度过大，前面好不容易保留下来的眼睛、高光这类细节，也可能直接被抹除。
第一个坑：单个格子该取什么颜色
最直观的实现思路，就是取格子范围内所有像素的RGB平均值：
R = 格子内全部像素R通道之和 / 像素总数量
G = 格子内全部像素G通道之和 / 像素总数量
B = 格子内全部像素B通道之和 / 像素总数量
这套方案处理实拍照片尚且勉强可用，放到卡通插画上就很容易翻车。
举个例子，一个格子主体是粉色，但刚好跨到一道黑色轮廓线。做平均计算之后，得到的既不是粉色也不是黑色，而是原图根本不存在的暗灰粉色。格子分辨率越低，这类问题就越突出。
v3版本没有单一依赖平均色，会同时统计四类数据：格子平均色、出现频次最高的颜色、格子内部颜色方差、主色的像素占比。
统计高频色的时候，不能直接拿原始RGB值作为统计key。JPEG压缩、图片缩放之后，肉眼看着完全一致的粉色，像素值会出现细微浮动，例如(250, 190, 195)、(249, 191, 194)、(251, 189, 196)。如果直接用完整RGB去计数，这些本属于同一种的颜色会被拆分成多个独立类别。
我的处理方式，是把RGB每个8位通道压缩到4位，先把视觉相近的颜色归入同一个颜色桶：
bucket = ((r >> 4) << 8) | ((g >> 4) << 4) | (b >> 4)
统计桶内出现次数最多的一组，作为该格子的高频色，之后再拿桶内原始像素重新计算平均值，避免颜色被粗暴压缩。
面对平涂插画，算法会优先参考高频色，以此守住干净利落的色块边界。处理照片则会优先看格子内部的颜色方差：如果格子刚好压在图像边缘，并且某一种主色占比足够高，就选用高频色；其余场景依旧使用平均色，保证肤色、天空这类连续区域过渡柔和。
这是一套很朴素的边缘感知策略，没有引入复杂神经网络，也不用重型边缘检测算子。逻辑很简单：先判断格子内部色彩是否杂乱，再决定采信像素平均值，还是像素多数派。
针对照片还有一处小调整：代表色会轻微抬升饱和度与对比度。多次取平均运算之后，图片色彩很容易发灰，而拼豆实物本身色彩饱和度偏高。这一步只是补偿采样损耗的色彩张力，并不会给图片叠加滤镜效果。
第二个坑：RGB数值距离近，不等于人眼看着接近
拿到每个格子的代表色之后，下一步就是匹配对应的拼豆色号。
最开始我直接在RGB空间计算欧氏距离：
d² = (R₁‑R₂)² + (G₁‑G₂)² + (B₁‑B₂)²
写法简单，运行速度快，但存在底层缺陷。RGB是面向显示设备设计的色彩体系，并不贴合人眼的视觉感知。同样是20的数值差值，落在暗部、亮部、绿色、蓝色区域，人眼实际感知到的差距完全不一样。
所以v3把全部色彩转换到CIELAB空间。
Lab模型中L代表明度，a轴大致对应红‑绿，b轴大致对应黄‑蓝。这套体系算不上完美，但相比RGB，更贴合人眼对色彩差异的判断。在Lab空间做距离匹配，选出来的拼豆色会自然很多，尤其是肤色、浅粉色这类低饱和色彩。
工程上还有个小优化：只做距离对比排序的场景，不需要计算平方根，直接对比距离平方即可，排序结果完全一致。
d2 = (L1 - L2) ** 2 + (a1 - a2) ** 2 + (b1 - b2) ** 2
单看一次计算节省的开销微乎其微，但一张图纸有成千上万个格子，每个格子还要对比大量色号，累积下来性能收益很可观。
第三个坑：不能放任每个格子各自选色
如果让每一个格子独立去找距离最近的拼豆色，生成结果往往会非常花哨。一张肉眼看只有十几种主色的照片，匹配之后可能直接冒出七八十种豆子。大量颜色仅仅只出现一两颗，不管是采购豆子还是手工制作都十分折磨。
简单粗暴截取出现频次最高的N种颜色也不可行。眼睛、唇色、图案标识这类关键色彩，像素占比很小，很容易直接被过滤掉，可恰恰是这些小色块决定了画面辨识度。
v3处理照片时，会先执行全局色彩量化，采用Median Cut搭配K‑means的组合方案。
Median Cut可以通俗理解为不断切割颜色盒子。把全部颜色丢进同一个盒子，找到Lab三轴当中色彩跨度最大的那一轴，沿着这个方向切分盒子；反复挑选跨度最大的盒子继续切分，直到产出目标数量的颜色簇。
切分位置也不是简单取数组中点，而是按照颜色实际出现次数加权计算。出现几百次的肤色，权重理应远高于只出现一次的图片压缩噪点。
Median Cut优势是速度快，生成的初始颜色中心分布比较分散。但切割得到的中心点并不是最优解，所以后续会运行加权K‑means做迭代优化：
- 将所有颜色分配给距离最近的中心点；
- 依据颜色出现频次，计算出新的加权中心点；
- 循环迭代，直到中心点位移幅度足够小，或是抵达最大迭代次数。
v3最多迭代12轮，中心点最大位移小于0.25个Lab单位就提前终止迭代。没必要追求数学意义上的完全收敛，毕竟后续还要映射到有限的实体拼豆色号，中心点数值再精细，现实里也没有对应的豆子。
这里有一处容易忽略的细节：K‑means输出的只是理想虚拟颜色中心点，市面上并不一定有对应的拼豆。需要把每一个中心点映射到真实存在的拼豆色号，所有格子再归属到对应颜色簇，拿到最终豆子色号。
色板原始数据也需要校验清洗。同一个拼豆编号，如果对应两组不一样的RGB值，导出的采购清单就会产生歧义。遇到这类冲突，我会直接舍弃这条冲突色号，降级选用邻近色，绝不输出模棱两可的色号。
经过这一套流程，整张图纸共用一套统一配色方案，不再是各个格子各自为政，画面观感协调，输出的采购清单也真正具备实用性。
第四个坑：看着像原图，不等于可以动手拼
走到这一步，图片大体已经还原原图样貌，但直接拿去拼依旧很难受。
照片自带的纹理、压缩噪声、细微渐变，映射到离散格子之后，会产出大量孤立色点。在屏幕上缩小预览看着细节丰富，实际制作的时候苦不堪言，东一颗西一颗完全不连贯。
为此v3做了三层后置整理逻辑。
第一层，近似色合并。已经选中的拼豆色号，如果在Lab空间差距很小，优先保留出现次数更多的那一个。去掉肉眼几乎分辨不出差别的颜色，能够大幅降低手工难度。
第二层，带约束的邻域平滑。算法读取单个格子周边8个相邻格子，统计高频候选颜色。但不会简单遵循少数服从多数直接替换；替换前还要核算，更换颜色之后和原图的Lab色彩误差。只有误差低于阈值，才允许修改当前格子颜色。
这一步至关重要。单纯的多数投票降噪，固然能把画面处理干净，却极易抹除眼睛、高光、嘴角这类细小关键元素。叠加原图误差约束之后，平滑只会处理“换完差别不大”的噪点格子。
第三层，连通区域清理。采用8邻域算法检索同色连通块，面积小于等于2格的块标记为疑似噪点，替换为周边占比最高的颜色，循环多轮直到不再产生新的细碎色块。
这里只能标记为“疑似噪点”。一两格大小的色块，有可能是噪声，也有可能就是五官高光。这也是拼豆算法最棘手的矛盾点：画面干净度和细节保留天生互斥。降噪阈值不能脱离图纸尺寸、图片题材单独设置。
为什么要区分照片和插画
实拍照片和平涂插画的色彩分布差异巨大。
照片充斥光影、纹理与大量渐变，适合全局聚类的处理思路；卡通插画大多是大块纯色搭配锐利轮廓，如果套用照片那套偏向平滑的流程，黑色线条、小面积装饰色块很容易直接被算法吃掉。
v3会对原图做稀疏采样，统计三项指标：量化之后的总颜色数、相邻像素完全一致的占比、相邻像素近似一致的占比。
如果大量相邻像素色彩相同，整体颜色种类偏少，平涂特征明显，就走插画处理分支；反之按照片流程处理。特意加入“近似相同”的判断，是因为JPEG压缩会给纯色区域叠加肉眼难以察觉的噪点。如果只判断像素严格相等，大量卡通插画会被误识别成照片。
当然这套判别逻辑无法做到百分百精准。带渐变的插画、重度磨皮人像、多次压缩的表情包，都会处于两种类型的交界地带。v3没有追求学术级完美分类，只是用低成本的统计特征，让绝大多数图片进入适配的处理链路。
移动端额外难题：不要把界面直接卡死
K‑means迭代、逐格采样、邻域循环处理，都是开销不小的运算。如果全部同步阻塞跑在主线程，图片尺寸稍大，页面加载动画就会彻底僵死。用户感受不到“正在运算”，只会误以为工具按钮失效。
所以v3设计了同步、异步两套执行入口。异步版本算法逻辑完全不变，只是在K‑means每一轮迭代、平滑每一轮处理结束之后，主动交还主线程执行权。算法输出结果和同步模式完全一致，但UI可以正常刷新加载状态。
这么做并不会缩短总的运算耗时，却极大改善用户使用体验。移动端图像算法，运算速度固然重要，不阻塞交互界面同样不可忽视。
说到底，难点从来不是某一个数学公式
写完v3版本，我最大的感悟是：算法不是越复杂越好。关键在于每一步新增逻辑，到底是为了解决前一环节暴露出的什么缺陷。
取平均色会吞噬轮廓，就补充高频色与格内方差判断；RGB距离不符合人眼感知，就迁移到Lab色彩空间；逐格独立选色画面杂乱，就引入全局颜色聚类；聚类之后依旧残留碎噪点，就增加带误差约束的平滑、小连通块清理。
整套逻辑并不是一开始就完整规划好的架构，大多都是遇到具体图片翻车之后，一点点迭代补全出来的。
而且不存在一套万能参数适配全部图片。32格的小图纸，天生承载不了64格图纸的细节；限定只用8种颜色，脸部层次必然比不上32色；降噪清理越激进，误删五官细节的风险也就越高。算法能做到的，只是在种种现实限制中间，权衡出一张既贴近原图、又适合手工拼制的图纸，做不到无损把原图压缩进拼豆格子。
工具至今还在持续迭代优化，后续版本会进一步考量格子内部完整色彩分布、自定义色板、相邻格子联合优化。但我依旧觉得v3最值得拿出来分享：用到的都是通用经典算法，可每一处改动，都对应着真实使用场景里实打实的问题。
女朋友不会关心什么Median Cut，也不会深究Lab空间a、b轴的含义。她看完生成图只会直白反馈：“这个脸怎么灰蒙蒙的？”“眼睛怎么没了？”“颜色也太多了吧。”
老实说，这种来自真实使用者的反馈，远比标准测试集来得直接有效。
而我的工作，就是拿着这些反馈回去继续打磨算法。
