这个日本开发者花3个月，把「取色」这件事重新做了一遍

一个前端工程师在整理插画收藏时，发现所有主流取色工具都在「睁眼说瞎话」——它们提取的「主色调」，往往和肉眼看到的完全两码事。

2024年底，nazunya（なずにゃ）开始动手解决这个问题。三个月后，colorlip v1.0.0 发布，专门盯着动漫插画和产品照片做优化。上线首周，GitHub star 数破千，npm 周下载量冲到 4000+。

为什么通用工具在插画上会「翻车」

nazunya 最初的需求很具体：做一个本地服务来整理插画和参考图，需要按色系搜索。他试了平均色算法，也用了 Color Thief、node-vibrant 这些老牌库。

结果很尴尬。一张蓝发少女的插画，通用工具可能提取出一片灰蒙蒙的中间色——因为算法把背景和阴影的平均值算进去了。一张暖色调的产品图，输出的「主色」却偏冷，因为高光区域面积更大。

「现有方案是为通用场景设计的，」nazunya 在文档里写，「面对插画和 artwork 时，总觉得差口气。」

问题出在假设上。通用取色库默认所有像素「投票权平等」，但人眼看插画时，会本能地忽略背景、聚焦主体，还会对高饱和的「记忆色」更敏感。让算法模拟这种感知，需要重新设计整个流程。

colorlip 的解法：先「看懂」图，再取色

colorlip 的核心思路分三步，有点像人类看图的本能反应。

第一步是「缩略图预览」。把图压到 150×150，做步进采样（stride sampling），判断两个关键信息：整体饱和度的中位数和分布，以及边缘是集中在中央还是分散四周。nazunya 推断，边缘分散的大概率是照片或延伸至边界的构图，边缘集中在中间的则主体居中——这个判断会直接影响后续中央色和边缘色的权重分配。

第二步是「降噪」。过滤掉 alpha 低于 0.5 的透明像素，同时用饱和度下限和明度范围做硬截断，把白底、噪点清理出去。

第三步是「聚类打分」。在 Lab 色彩空间（一种更接近人眼感知的色彩模型）里量化像素，综合考量中央位置、边缘强度、饱和度、透明度四个维度给颜色打分，合并相似色形成色簇。最后从色簇里挑出代表色和强调色。

整个过程在浏览器和 Node.js 都能跑，输出格式除了常规的 Hex、RGB，还支持 HSL、Lab、oklch——后者是近几年 CSS 新支持的 perceptually uniform 色彩空间，方便直接用在网页样式里。

一个细节：为什么选 150×150

这个尺寸不是拍脑袋定的。nazunya 测试过多个分辨率，150×150 能在「保留足够色彩信息」和「控制计算量」之间找到平衡点。对于 4K 插画，压缩到 150×150 后，主体色块的分布特征依然清晰，但像素数从 800 万降到 2.25 万，处理速度提升两个数量级。

更关键的是，这个分辨率下，步进采样的步长设置能稳定捕捉边缘分布特征。分辨率再低，细节丢失；再高，边际收益递减，计算成本却线性上升。

「如果直接用原始像素，core 模块也支持，」nazunya 补充，「但 150×150 是性价比最优的默认策略。」

实际效果：创作者社区的反应

colorlip 上线后，最先被插画聚合站和电商工具采用。一个日本的同人图站把 colorlip 集成到搜索系统，用户反馈「按色系找图终于准了」。某跨境电商的批量处理脚本用它提取产品主色，生成同色系推荐搭配，点击率比原来的平均色方案高 23%（该数据来自开发者社区分享，非官方 benchmark）。

GitHub Issues 里最活跃的讨论，是请求支持更多色彩空间输出，以及针对特定画风（厚涂、赛璐璐、水彩）的调参指南。nazunya 的回应很克制：「v1 先保证通用场景的稳定性，细分优化留给后续版本。」

目前 colorlip 的体积控制在 12KB（gzip 后），零依赖。对于需要服务端批量处理的用户，core 模块可以脱离 DOM 运行；前端场景则提供完整的浏览器 API，支持 canvas 和 ImageData 直接输入。

如果你手头正好有张插画想试试，nazunya 搭了个在线演示页。上传图片，它会实时输出调色板，每个色块标注了在图中的大致来源区域——是背景、主体还是高光，一目了然。

这个工具最终会不会成为创作者 workflow 的标配，现在还不好说。但至少，它证明了「取色」这件事，还有被重新做的价值——不是加更多功能，而是把最基础的体验做对。

你平时用什么工具处理图片配色？遇到过「算法色」和「肉眼色」打架的情况吗？