重复图片查找工具全链路：感知哈希、汉明距离阈值与安全去重

硬盘容量告急的红条弹出来的那一刻大多数人第一反应是删视频第二反应是删照片但真动手翻两遍就会发现一个更扎心的事实真正占地方的往往不是照片多而是同一张照片存了七八份。手机自动备份一遍、聊天软件缓存一遍、手动整理时又复制一遍、换机迁移再来一遍同一个画面就在不同目录里以不同的文件名躺着。这也是重复图片查找工具存在的意义——它把肉眼看不出差别这件事变成可计算的判定把散落在几十万张图里的重复组挑出来交给人工做最后的取舍。这类工具核心干三件事扫描指定目录、按某种口径判定重复、给出可执行的删除或移动方案。适合谁看图库过万的重度拍照用户、做素材库的内容从业者、需要清理服务器或 NAS 存储的运维以及想自己写一套去重脚本的开发者。下面我按工程实现的顺序把这件事从头拆一遍包括判定口径怎么选、感知哈希的阈值怎么定、扫描链路怎么排、哪些边界情况会让结果翻车以及删除前必须留的那道后悔药。1. 先把重复这个词拆开三种判定口径的取舍1.1 字节级重复零误判但只能抓到最老实的那一批字节级重复指的是两个文件的内容完全一致逐字节相同。判定方式很直接读文件、算密码学哈希SHA-256 或 BLAKE2、比对摘要值。哈希相同文件就相同概率上可以认为零误判。这类重复的典型来源是复制粘贴、备份工具重复执行、网盘同步客户端把同一份文件拉了两个名字回来。它的成本也最低因为你可以先按文件大小分桶——两个内容相同的文件大小必然相同所以只需要在大小相同的候选集合里算哈希能砍掉九成以上的读取量。这是我每次做批量清理时的第一道筛子跑得快、结论硬、不需要人工判断。但它抓不到的东西同样明显同一张图被聊天软件重新压缩过一遍文件大小变了、像素值也变了哈希完全不同同一张图从 JPEG 转成 HEIC更是两个世界。所以字节级只能当第一层不能当唯一一层。我见过有人拿它当唯一标准跑完整个图库删了两千多个文件结果打开一看占用空间只降了百分之三——因为真正的大头是那些被重新编码过的近似副本。1.2 视觉重复像素不同人眼看着一样这一层才是重复图片查找工具的主战场。典型场景是同一张照片一份是原图、一份是被聊天软件压缩后的版本、一份是被截图工具二次保存的版本、一份是从相册里导出时被顺手转成小尺寸的版本。它们的字节内容天差地别但缩到 8×8 的灰度缩略图之后几乎一模一样。工程上的做法是感知哈希perceptual hash把一张图压缩成一个定长的指纹然后比较指纹之间的汉明距离。常用的有三种算法计算方式对缩放/压缩的鲁棒性对调色/裁剪的鲁棒性计算成本aHash缩到 8×8 灰度与均值比较得 64 位中等差极低dHash缩到 9×8 灰度比较相邻像素大小得 64 位较好较差极低pHash缩到 32×32做离散余弦变换取低频 8×8好中等中等我的经验是dHash 做初筛pHash 做复核。dHash 对亮度渐变比较敏感速度快十几万张图跑下来占用很低pHash 因为做了频域变换对轻微的重新压缩、色彩偏移更宽容适合在 dHash 给出可疑候选之后再做一次确认。两者都用 64 位指纹比对时算异或后数 1 的个数就行。1.3 语义近似同一次连拍、同一场景的多张、裁切与调色第三层已经不算严格意义的重复了属于高度相似。连拍十张选一张、同一景点不同曝光、同一张图裁成横竖两个版本这些都落在这一层。判定它需要更宽松的阈值和更多人工介入工具一般会把它做成相似组而不是重复组提示你去看一眼而不是建议删除。这里必须说清楚一个取舍阈值越松召回越高误判也越多。如果你把汉明距离阈值设到 15 以上一张人像和同一背景下另一张人像很可能被判成一组因为它们的低频结构高度一致。我一般把精确重复阈值设在 0 到 2视觉重复设在 5 到 8相似组放到 10 到 12并且明确告诉使用者超过 10 的那一档必须人工过一遍不能自动执行。2. 感知哈希的工程细节从灰度矩阵到汉明距离阈值2.1 一个 64 位指纹到底是怎么算出来的拿 dHash 举例。第一步把图片读进来转灰度按 EXIF 里的方向信息做旋转纠正然后缩到 9×8 的尺寸。缩放的插值方式会影响结果我用的是面积平均在 Pillow 里对应Resampling.LANCZOS或Resampling.BILINEAR大图缩小时 LANCZOS 更稳。第二步逐行比较相邻两个像素左边比右边亮就记 1否则记 0。9 列像素每行产生 8 个比较结果8 行就是 64 位。第三步把这个 64 位整数存下来。from PIL import Image, ImageOps def dhash(path, hash_size8): with Image.open(path) as im: im ImageOps.exif_transpose(im) # 先按 EXIF 方向纠正 im im.convert(L).resize( (hash_size 1, hash_size), Image.Resampling.LANCZOS ) px list(im.getdata()) bits 0 idx 0 for row in range(hash_size): for col in range(hash_size): left px[row * (hash_size 1) col] right px[row * (hash_size 1) col 1] if left right: bits | 1 idx idx 1 return bits这段代码有两个地方特别容易出错我在项目里都栽过。第一是exif_transpose如果跳过这一步一张竖拍照片和它旋转 90 度后的副本会得到完全不同的指纹工具会把它们判成两张无关的图等于漏检。第二是模式转换有些 PNG 带 Alpha 通道直接convert(L)会把透明区域当成黑色混进灰度值里导致两张视觉一致的图指纹偏差很大正确做法是先合成到白色背景再转灰度。2.2 汉明距离阈值别拍脑袋用法定的数据定汉明距离就是两个 64 位指纹异或之后 1 的个数范围 0 到 64。距离 0 表示指纹完全一致通常意味着两张图缩到这个尺寸后像素级相同。我实测过的分布大概是这样图片关系典型汉明距离区间处理建议同一文件的不同副本0自动归组原图与重新压缩版0 到 2自动归组原图与缩放到 50% 的版本0 到 4自动归组保留大图原图与加了水印/文字的版本6 到 14人工确认同一次连拍的两张8 到 20人工确认同一场景不同角度15 以上不建议自动处理定阈值的方法不是查表而是自己标一小批样本。我的做法是从图库里随机抽 300 张人工标出 50 组确定是重复再随机凑 100 组确定不是重复然后跑一遍计算距离分布看两个分布的交叠区在哪。多数情况下 5 到 7 之间会有一个明显低谷那个位置就是你的阈值。这件事花半小时能省掉后面几千次误删的复核。注意不要用同一个阈值同时处理手机截图和相机原图两个数据集。截图的压缩噪声模式和相机 raw 转 jpg 完全不同同一个阈值在其中一类上会明显偏松或偏紧。我一般按文件来源分桶每桶用各自的阈值。2.3 六十万张图的比对不能靠两两循环假设图库有 20 万张图两两比对是 200 亿次运算就算每次只要 0.1 微秒也是大半天。必须做索引。有两种做法我实际用过并且效果稳定。第一种是分桶法基于鸽巢原理如果两个 64 位指纹的汉明距离不超过 k那么把 64 位切成 k1 段至少有一段是完全相同的。取 k3切成 4 段 16 位把每张图按 4 个段值放进 4 张倒排表里。查候选时只拿同一段值相同的图出来算距离候选集通常能压到原来的千分之一。def bucket_keys(h, parts4, bits64): seg bits // parts mask (1 seg) - 1 return [((h (i * seg)) mask, i) for i in range(parts)] # 建索引 index {} for img_id, h in fingerprint.items(): for key in bucket_keys(h): index.setdefault(key, []).append(img_id)第二种是BK 树以汉明距离为度量构建一棵树查询时按三角不等式剪枝。它在十万级规模下表现很好缺点是树的结构依赖插入顺序重建成本高适合一次性扫描而不是增量更新。我现在的习惯是数据量小于五万用分桶就够了超过就上 BK 树或者换成分段索引加并查集归组。归组这一步也值得说一下。候选对算出来之后不能简单地两两标记重复那样会得到一堆互相重叠的小组。正确做法是用并查集把有边相连的图合并成连通分量一个连通分量就是一组重复图。但连通分量有个副作用如果 A 像 B、B 像 C但 A 和 C 其实差得远也会被并成一组。这种情况在连拍序列里特别常见处理方式是对组内再做一次全对比把距离超标的成员拆出去或者干脆把这种大组标记成链式相似交给人工。3. 一次完整的去重作业从摸底到落盘的执行链路3.1 第一阶段目录摸底先搞清楚你在处理什么拿到一个未知图库别急着算哈希。先跑一遍轻量的目录统计文件总数、总大小、按扩展名分布、按顶层目录分布、按年份分布。这一步能暴露出很多信息。比如我发现过某个目录里有 4 万个小尺寸 PNG全是某个设计工具的图标缓存也发现过某个备份文件夹里全是几 KB 的占位文件是同步失败留下的残骸。这些都不该进入哈希流程直接按规则排除更省事。摸底时重点看三件事文件大小分布大量集中在几百 KB 以下的多半是缩略图缓存、扩展名分布HEIC、DNG、CR3 这类需要额外解码器得先确认环境能不能处理、目录深度深度超过 15 层的警惕符号链接造成的循环。import os from pathlib import Path from collections import Counter SKIP_DIRS {.thumbnails, cache, .git, node_modules} def walk_photos(root): for dirpath, dirnames, filenames in os.walk(root, followlinksFalse): dirnames[:] [d for d in dirnames if d.lower() not in SKIP_DIRS] for name in filenames: p Path(dirpath) / name try: st p.lstat() except OSError: continue if not p.is_file(): continue yield p, st.st_sizefollowlinksFalse这一句必须显式写。我踩过一次坑图库里有个软链接指向上层目录默认跟随之后遍历进入了死循环跑了四十分钟还没结束日志里全是同一批文件名的重复记录。3.2 第二阶段分层计算别一上来就算哈希我的执行顺序固定为四层每层只处理上一层剩下的候选第一层是排除规则跳过隐藏目录、跳过小于 8KB 的文件基本是图标和占位文件、跳过纯文本和视频除非你确实要处理视频封面。第二层是同大小分组把所有文件按字节大小分组只有大小相同的文件才可能字节级重复。这一步不读文件内容纯靠stat几十万文件几秒钟就完成。第三层是字节哈希对第二层里组内成员数大于 1 的组读取内容算 BLAKE2b 摘要。用 BLAKE2b 而不是 MD5一是速度快二是digest_size可以设成 16 字节够用且省内存。第四层是感知哈希对没有在第三层找到字节级重复的文件计算 dHash然后走索引找近似。注意这里要把第三层已经判定为完全重复的文件排除掉否则同一组的图会重复进入感知流程白跑一遍。这四层的好处是成本递增、收益递减你随时可以在某一层停下来拿到的都是有效结果。我通常让它在第二层和第三层跑完全量第四层只对文件大小大于 100KB 且不是已知重复的集合跑一次能覆盖九成以上的实际空间浪费。3.3 第三阶段分组打分给每张图算一个该留的分数重复组出来之后最麻烦的问题不是要不要删而是留哪一张。工具默认的规则通常是留文件最大的或者留最早的但这两种都经常出错。我现在的打分维度是这样的分辨率权重最高像素总数越大越优先保留这是最硬的指标。文件大小次之同等分辨率下文件大的通常压缩损失小。EXIF 完整度加分有拍摄时间、相机型号、GPS 信息的说明是原始文件而非二次导出。非截图加分文件名或元数据里带截图Screen Shot字样、或者分辨率精确等于某款屏幕尺寸的优先级降低。路径稳定性加分位于相机导入目录的比位于下载聊天缓存目录的优先。def keep_score(meta): score 0 score meta[width] * meta[height] / 1e6 * 10 # 分辨率 score min(meta[size] / 1e6, 20) # 文件大小封顶 score 5 if meta[has_exif_time] else 0 score 3 if meta[has_camera_model] else 0 score - 8 if meta[is_screenshot] else 0 score 2 if meta[in_import_dir] else 0 return score这个打分没有绝对正确的答案但它把主观判断变成了一个可调、可解释的过程。你完全可以按自己的习惯改权重关键是先把规则写死再让它批量执行而不是一组一组地点开看——后者在图库超过一千组之后会彻底崩溃。3.4 第四阶段两段式下线先移动后删除这一步是整个流程里唯一有破坏性的环节我的做法是从来不直接删除。所有被判为重复且分数较低的文件一律先移动到同一个隔离目录保持原有的相对路径结构然后写一份清单记录原路径、新路径、所属组、保留的那张是谁、判定依据、时间戳。隔离目录至少保留七天确认无误后再清理。移动而不是复制是为了避免磁盘空间不足但跨盘移动本质是复制加删除中途断电会留下半个文件。稳妥的做法是同盘用os.rename跨盘先shutil.copy2再校验大小和哈希最后删源文件。import shutil, os, json def quarantine(src, dst_root, rel_path, manifest): dst dst_root / rel_path dst.parent.mkdir(parentsTrue, exist_okTrue) if src.stat().st_dev dst_root.stat().st_dev: os.rename(src, dst) else: shutil.copy2(src, dst) if dst.stat().st_size ! src.stat().st_size: raise IOError(fsize mismatch: {src}) src.unlink() manifest.append({from: str(src), to: str(dst)})清单文件我会直接写成 JSON Lines一行一条方便用grep和jq查。真出问题的时候靠这份清单能原路回滚这是唯一的后悔药比任何回收站都可靠。4. 那些让结果翻车的边界情况4.1 Live Photo、动态图和视频封面苹果的 Live Photo 在文件系统里是两张文件一张 HEIC 静帧加一段 MOV。很多工具只扫图片扩展名会把 HEIC 挑出来判成重复然后把 MOV 留在原地变成孤儿文件。更麻烦的是如果两张 Live Photo 的静帧几乎一样但动态部分不同按图片去重会误删掉唯一的动态记录。我的处理方式是把同名的 HEIC 和 MOV 视为一个不可分割的单元做去重时按单元整体决策任一方被保留另一方就必须保留。动态 GIF 和视频封面也有类似问题。GIF 抽一帧算哈希很可能和某个静态图撞上视频封面很多播放器 会在同目录生成同名 JPG本来就是缩略图和原视频内容重复但不能删。这类文件我建议在扩展名规则里直接排除别让它们进入感知哈希流程。4.2 RAWJPEG 双格式与文件名误导相机同时拍 RAW 和 JPEG 是标配这两张图内容完全一致但文件完全不同。如果按感知哈希去重工具大概率会把 JPEG 判成 RAW 的重复并建议删除——这显然是错的很多人就是要两个都留。正确的处理是把同文件名不同扩展名识别为配对关系标记为格式对从去重候选里剔除另外单独提供清理不需要的 JPEG 副本的选项。文件名误导的问题也很常见。IMG_2034.JPG在三个不同目录里出现但内容可能是三张完全不同的照片不同设备、不同次导入都会产生重名。所以任何基于文件名的去重都必须配合内容校验光看名字就删是纯粹的赌博。反过来同一张图在不同目录里叫IMG_2034.JPG和wedding-final-v2.jpg也很正常名字完全不同不代表内容不同。4.3 连拍、截图和聊天软件缓存连拍序列是误判重灾区。十张连续拍摄的照片相邻两张的汉明距离可能只有 6 到 10落在视觉重复区间里。如果阈值设得松工具会把整组连拍归成一类然后按分数只留一张剩下九张全进隔离区——当事人看到这个结果会直接卸载软件。我的处理方式是给连拍加一个识别规则拍摄时间间隔小于 2 秒、分辨率完全相同、文件名序号连续的标记为连拍序列序列内部不做去重只把整个序列当作一个单元对外比较。截图同理聊天软件缓存目录里的图更麻烦它们往往被重新编码过、尺寸被压过感知哈希能匹配上但这些图删了会影响聊天记录里的显示所以缓存目录整体列入跳过名单更安全。4.4 EXIF 丢失、时间戳错乱与硬链接从社交平台保存下来的图通常 EXIF 全空文件修改时间也被重置成保存那一刻。这时候按保留最早的规则会留下错误的那一张。我的做法是EXIF 缺失时优先用文件名里的日期模式再退回到目录名里的年份最后才用文件系统时间戳。这条链路写起来啰嗦但能救回大量被误判的老照片。硬链接是另一个隐形陷阱。同一个 inode 被链接到两个路径看起来是两个文件、占两份目录项但实际只占一份磁盘空间。如果你按路径去重把它们当成重复删掉一个并不会释放空间因为另一个链接还在反而可能让某些工具的预期收益落空。检测方法是比较st_dev和st_ino相同的就是硬链接应该标记为同一文件的两个入口而不是重复文件。5. 删除策略与后悔药删得干净不等于删得安心5.1 隔离区的目录结构该怎么设计隔离区不是简单地把文件堆在一个文件夹里。我的设计是三层最外层是本次作业的批次号带日期第二层是原始路径的相对镜像第三层是原文件名。这样做的原因是回滚必须能精确还原到原位如果所有文件扁平堆在一起重名一覆盖就彻底找不到北了。同时每个批次目录下放三个文件manifest.jsonl记录每条移动的完整信息groups.json记录每个重复组的成员和判定依据summary.txt记录本次扫描的参数阈值、排除规则、打分权重。这三份东西加起来等于给这次作业留了一份可复现的实验记录。半年后你突然发现某张照片不见了靠这些文件能在几分钟内定位到它被移到了哪、当时和谁被判成一组、依据是什么。存储成本上隔离区会占掉一份完整副本的空间。如果磁盘实在紧张可以只隔离高风险的组相似度在阈值边缘的完全字节级重复的组直接删——因为它的判定没有歧义误删概率接近于零。我一般按这个比例分配字节级重复直接删视觉重复进隔离区。5.2 阈值边缘的那批图必须人过一遍任何自动化去重真正的风险都集中在阈值边缘。距离 3 的判定基本可信距离 12 的判定基本靠猜。我的做法是把结果按距离分成三档用不同颜色标注在报告里绿色0-4可直接执行、黄色5-9建议抽查百分之十、红色10 以上逐组人工确认。人工确认这件事有个效率技巧不要一张一张看原图而是生成拼图预览。把同一组的多张图缩到 400×400横向拼成一张长图标注上文件名和分数。一组一眼几十组几分钟就能过完。这一步能拦下绝大多数误判而且成本极低。如果你用命令行工具做这件事可以直接调用图像处理库拼图如果不想写代码很多看图软件支持多选后生成联系表contact sheet。关键是把决策和查看分开先批量看再批量决定不要陷进单张图的细节里。5.3 校验与回滚删完之后还要做什么批量操作完成后必须做一次完整性校验。校验的内容包括隔离区文件数量与清单条数是否一致、每个隔离文件的哈希是否与清单记录一致、原目录里是否还残留零字节文件、以及磁盘可用空间是否真的增加了。最后这条经常被忽略。如果去重后空间没怎么变很可能是因为你删的都是硬链接或者删除操作只是把文件移到了同一个分区的另一个目录空间并不会释放。真正释放空间需要清空隔离区或者在确认无误后对隔离区执行删除。我就遇到过有人跑完工具看着报告说清理了 120GB实际磁盘只多了 8GB因为隔离区和原目录在同一个盘上。回滚脚本要提前写好不能等出事再写。基本逻辑是读manifest.jsonl逐条检查目标位置是否为空然后把文件移回原路径。写的时候要注意处理原路径已经存在同名文件的情况这时候不能覆盖应该加后缀保留两份。def rollback(manifest_path): with open(manifest_path) as f: for line in f: rec json.loads(line) src, dst Path(rec[to]), Path(rec[from]) if not src.exists(): continue if dst.exists(): dst dst.with_name(dst.stem _restored dst.suffix) dst.parent.mkdir(parentsTrue, exist_okTrue) shutil.move(str(src), str(dst))6. 自建脚本还是用现成工具三条路线的实际对比6.1 三条路线的成本与适用边界做重复图片清理摆在面前的基本是三条路用现成的成品工具、用开源的命令行脚本、自己写一套。三条路我都走过结论是取决于你的图库规模和你的控制欲。路线上手成本可控性适合规模主要风险成品图形工具低装完就能扫低参数基本固定一万张以内判定规则不透明结果无法复现开源命令行脚本中需要读文档调参数中高阈值和规则可配十万张级依赖环境、格式支持不全自己写脚本高要处理解码和索引完全可控任意规模性能和边界情况全靠自己踩成品工具最大的优势是省事最大的问题是你不知道它为什么把这两张判成一组。我见过一款工具把两张完全不同的人像判成重复原因只是背景墙面纹理一致而它用的是全局平均哈希对背景权重过高。这种时候你既没法调参也没法看中间结果只能整个结果都不敢信。自己写的价值在于每一步都能验证。哈希算错了可以单独测一张图索引漏了可以打印候选集阈值不合适可以重新跑一遍分布统计。代价是你要处理一堆琐碎问题HEIC 解码、CMYK 色彩空间、超大图超过一亿像素的内存占用、损坏文件的异常捕获。6.2 大图库的 I/O 与内存控制十万张以上的图库瓶颈几乎从来不是 CPU而是磁盘 I/O 和内存。这里有几个我实测有效的做法。第一控制并发读的进程数。机械硬盘上并发读不但不提速反而因为寻道抖动变慢进程数设成 2 到 4 就够固态盘可以开到 CPU 核数的一半。我一般用进程池而不是线程池因为图像解码是 CPU 密集型的Python 的 GIL 会让线程池几乎没收益。第二先读文件头拿尺寸。绝大多数图片格式的宽高信息在前几百字节里用不着解码整张图。拿不到尺寸的文件直接跳过能省掉大量解码开销。这一步对筛选缩略图尤其有用——分辨率小于 400×400 的直接归到缓存类不进主流程。第三及时释放。用上下文管理器打开图片处理完立刻关闭。我见过脚本跑着跑着内存涨到 20GB原因就是Image.open之后没关几百张图的解码缓冲区全挂着。第四分批落盘。指纹不要一直存在内存里每处理一万张就写一次中间结果文件用二进制或者 JSON Lines断了可以续跑。长任务最怕的就是跑到百分之九十崩了从头再来。6.3 把去重变成定期巡检而不是一次性大扫除一次性清理完过三个月又会攒出一堆重复。原因很现实手机还在备份、聊天还在存图、下载还在重复。所以真正省心的做法是把这套流程做成定期任务比如每月跑一次增量扫描。增量扫描的关键是记录已处理文件的状态。我维护一张 SQLite 表记录每张图的路径、大小、修改时间、字节哈希、感知哈希、所属组。下次扫描时只要大小和修改时间都没变就直接复用旧指纹不重新读文件。十万张图的增量扫描通常几分钟就能跑完。import sqlite3 DDL CREATE TABLE IF NOT EXISTS photos( path TEXT PRIMARY KEY, size INTEGER, mtime REAL, bhash TEXT, phash INTEGER ); def need_rehash(path, size, mtime, conn): row conn.execute( SELECT size, mtime FROM photos WHERE path?, (str(path),) ).fetchone() return row is None or row[0] ! size or abs(row[1] - mtime) 1巡检结果我建议只做提示不做自动执行。每次都生成一份报告列出新增的重复组和建议保留项由人决定要不要处理。全自动删除在这个场景里风险太高一次误判可能就是几百张照片而人花十分钟看报告的成本远低于恢复数据。另外一个容易被忽略的点是扫描范围要排除隔离区本身。如果隔离区和图库在同一个父目录下下一次扫描会把隔离区里的文件也扫进来然后发现它们和原图重复再移一次目录就乱套了。我现在的做法是给隔离区目录名加固定前缀扫描时按前缀跳过。最后分享一个我自己一直在用的习惯每次跑完批量操作先不解压隔离区先随机抽十张从隔离区里还原打开看一眼能不能正常显示、EXIF 还在不在。移动操作理论上不会破坏文件内容但跨盘复制加删除的路径上我确实遇到过两次因为中断导致的文件截断。这一步花两分钟能确认整批操作没有系统性问题比事后翻备份强得多。