ARTICLE DETAIL

资讯详情

深耕编程入门与网站建设的一线实战洞察。

CUHK02行人重识别数据集:从解压到加载的完整指南

CUHK02行人重识别数据集:从解压到加载的完整指南 简介CUHK02数据集压缩包是一份面向人脸识别研究人员、算法工程师以及计算机视觉学习者的人脸图像资源包其核心用途在于应对光照变化、姿态角度差异、面部表情变化、局部遮挡以及跨视角识别等非理想条件下的算法评测与模型训练。压缩包内共包含7270个文件其中7264张人脸图像全部采用PNG格式并且已按照个体身份划分至不同子目录中。每个子目录内同时含有实验室环境采集的高分辨率人脸图像和街头监控摄像头捕捉的低分辨率人脸图像每张图像均附有精确的人脸边界框标注这为后续的特征提取、切割比对以及深度学习模型训练提供了标准化的数据基础。除了图像数据之外包内还提供了一个Python脚本和一个TXT说明文档分别用于数据预处理、格式转换以及数据集整体结构的解读便于研究者快速上手整个资源包压缩后大小为122.61MB。目前已有1034人浏览与学习这份资源。利用这份数据研究者能够直接开展人脸检测、人脸识别与人脸验证等方向的对比实验尤其是双摄像机多视角拍摄设置为跨视角人脸识别提供了不可多得的测试样本室内外场景与画质差异也帮助算法更好地适应真实环境中出现的模糊、弱光等问题从而提升泛化能力与鲁棒性。 很多跑行人重识别Person Re-IdentificationReID实验的同学第一次拿到香港中文大学公开的cuhk02_release(dataset).7z这个文件第一反应基本都一样直接双击解压。然后就会遇到各种意想不到的情况——默认解压软件报错、解压到一半磁盘满了、好不容易解压完又发现目录结构和预期完全对不上。我在这份数据上前后折腾过好几天踩了不少坑写这篇文章把从下载到成功加载数据的完整链路捋一遍重点是解压和校验这两个环节因为绝大多数问题都出在这里。如果说你是第一次接触 ReID或者正准备在服务器上跑 CUHK02 的 baseline这篇文章可以帮你省下大量试错时间如果你已经解压过不少数据集也可以重点看看后面的哈希校验和目录结构部分很多细节平时容易被忽略。1. 先搞懂这份数据的价值再决定要不要折腾1.1 它解决的是“跨摄像头认人”的问题CUHK02 是行人重识别领域早期的公开基准数据集之一由香港中文大学多媒体实验室整理发布。ReID 任务的核心一句话就能讲清楚给定摄像头 A 中某个人的一张图像要求算法在摄像头 B 拍摄的所有图像中把同一个人的图像全部找出来。听起来简单实际做起来却非常难因为不同摄像头之间的光照、视角、分辨率、遮挡情况差异极大同一个人的外貌特征可能被严重扭曲。CUHK02 的样本来自校园场景中的多组摄像头对官方发布的数据包含五个摄像头对的数据每个摄像头对之间任务难度也不同。相比后来的 CUHK03、Market-1501 这些大数据集CUHK02 的规模不算大但它的结构非常规整特别适合用来做算法验证和 baseline 对比。很多经典 ReID 论文在早期阶段都会先在 CUHK02 这类小数据集上跑通再迁移到更大的数据集上。我记得官方统计里面包含了上千个行人身份总身份数在 1800 上下每个身份对应在不同摄像头视角下的多张图像。不过要注意不同摄像头对覆盖的行人身份并不是完全相同的有的身份只出现在某一个摄像头对里有的则跨多个摄像头对出现。这个特性在做训练集和测试集划分时需要特别留意否则容易出现数据泄漏。1.2 为什么偏偏是 7z而不是 zip 或者 rar学术数据集的分发格式看起来是个小问题但实际影响很大。CUHK02 选择 7z 格式最重要的原因是压缩率高。行人图像虽然经过了裁剪和缩放但 JPEG/PNG 这类格式仍然存在大量冗余7z 采用的 LZMA 算法在压缩图像文件时压缩比通常明显优于 zip甚至比 rar 更稳。第二个原因是 7z 支持分卷压缩和加密这两个特性对数据集发布者来说非常实用。分卷可以把一个大文件拆成多个小体积的分卷文件方便学术资源站逐卷上传下载加密则可以让发布者对数据集设置访问控制。虽然后来很多镜像站会把 7z 重新打包成 zip 方便 Windows 用户但官方原版依然是 7z。也就是说如果你手上的文件叫cuhk02_release(dataset).7z它大概率是官方原始版本没有经过第三方二次打包保留着最原始的目录结构。这一点对你后续写数据加载代码很重要因为网上不少教程里提到的目录路径对应的其实是第三方重新整理过的版本和官方结构不一定一致。2. 跨平台解压实操从服务器到个人电脑2.1 Linux 下用 p7zip 解压别让文件名括号坑了你绝大多数深度学习实验是在 Linux 服务器上跑的所以先说 Linux。大部分发行版默认不会预装 7z 支持Debian/Ubuntu 用户需要先装 p7zipsudo apt update sudo apt install p7zip-fullCentOS/RHEL 系的发行版则用sudo yum install p7zip p7zip-plugins装好之后解压命令本身很简单7z x cuhk02_release\(dataset\).7z这里有一个非常容易踩的坑文件名里有左右括号(dataset)。在 bash 里括号是有特殊含义的元字符直接输进去会被当作子 shell 语法解析导致命令报错。上面我用了反斜杠转义更省事的做法是给整个文件加引号7z x cuhk02_release(dataset).7z如果你想解压到指定目录用-o参数注意-o后面紧跟路径中间不能有空格7z x cuhk02_release\(dataset\).7z -o/data/ReID/CUHK02这条命令执行后7z 会按压缩包内的目录结构自动创建文件夹并解压文件。如果你只想先看看压缩包里到底是什么结构可以用l参数列出清单这个习惯强烈建议养成7z l cuhk02_release\(dataset\).7z输出里会显示每个文件的原始路径、大小和压缩后大小你可以据此估算解压后的总占用空间避免解压到一半磁盘写满。2.2 Windows 和 macOS 上的快捷解法Windows 用户最省事的方案是安装 7-Zip这个软件无广告、无捆绑安装完成后右键点击 .7z 文件选择“解压到当前文件夹”或者“解压到 cuhk02_release(dataset)\”。需要提醒的是这两个选项的区别很大前者会把所有文件直接散落在当前目录后者会先创建一个以压缩包名命名的文件夹再把文件放进去。大多数情况下选后者更合适避免解压后一堆文件直接污染你的工作目录。macOS 自带的归档实用工具对 7z 的支持很有限某些版本直接打不开或者解压出来文件名乱码。我测试过比较可靠的方案是用 Homebrew 安装 p7zipbrew install p7zip然后在终端里用和 Linux 完全一致的命令解压。嫌命令行麻烦的话也可以装 The Unarchiver它能无缝处理 7z 格式而且基本不会出现文件名编码问题。2.3 先小范围试解压再全量解压这是一个很多人忽略的技巧。CUHK02 压缩包体积不小如果直接全量解压遇到磁盘空间不足或者压缩包损坏会浪费大量时间。正确做法是先用7z l看清单然后挑其中一两个小目录试解压7z x cuhk02_release\(dataset\).7z -o/tmp/test */Camera1/*这样只解压 Camera1 目录下的内容到/tmp/test用来验证压缩包是否完好、目录结构是否符合预期。确认没问题后再全量解压到目标路径。这招在处理任何一个大型 .7z 数据集时都非常管用。3. 哈希校验动手解压前唯一值得做的一件事3.1 为什么学术数据集的哈希校验不能跳过从网盘、学术站点或者实验室内部服务器上传下载大型数据集中途发生损坏的概率比很多人想象的高得多。网络抖动导致文件不完整、服务器存储故障、镜像站同步出错任何一个环节出了问题你拿到手的都可能是一个“看起来正常但解压失败”的坏文件。CUHK02 这类 7z 压缩包一旦文件头损坏解压时往往卡在 99% 然后报错非常让人崩溃。所以我的习惯是下载完成后先做两件事——比对文件大小再计算哈希值。文件大小是最粗粒度的校验如果和发布页面标注的大小不一致直接删掉重新下载不用犹豫。大小一致再进入哈希比对环节。3.2 三种系统下的哈希计算命令计算 SHA-256 校验和的命令其实都很好记。Linux 下用sha256sumsha256sum cuhk02_release\(dataset\).7z输出类似这样3f44e1c23a5c9bb8e3d09f84a7c4456dbb7a5a6d65f7e58b8e0f2a13c6a7f3b1 cuhk02_release(dataset).7zmacOS 自带的是shasum加-a 256参数指定算法shasum -a 256 cuhk02_release\(dataset\).7zWindows PowerShell 用户可以用Get-FileHash .\cuhk02_release(dataset).7z -Algorithm SHA256拿到这串哈希值后和发布方官方页面或者 README 里给出的校验值逐字符比对。注意比对的时候别只比对前几位哈希值的分布是均匀的前面几位一样后面不一样的情况很常见全部一致才算完整。3.3 比对哈希时容易忽略的两个细节第一发布方可能给的不是 SHA-256而是 MD5 或者 SHA-1。MD5 虽然不再适合作为安全校验但在文件完整性校验场景下仍然可用。如果你的发布页面给的是 MD5那就用md5sum或者Get-FileHash -Algorithm MD5来计算不要拿 SHA-256 的值去硬比。第二注意发布方给出哈希值时有没有包含文件名后缀。有些校验文件里记录的是3f44e1c23a5c9bb8e3d09f84a7c4456dbb7a5a6d cuhk02_release(dataset).7z有些则只有纯哈希值。在线哈希计算工具生成的结果通常不含文件名而命令行工具的输出默认带文件名。比对时建议只比对哈希字符串本身忽略文件名部分避免因为文件名差异造成误判。另外说一句网上很多人喜欢用“在线哈希计算网站”来算但这其实是个安全隐患——你把文件传到第三方网站等于把数据暴露给了别人。对于普通的公开数据集问题不大但如果你处理的是受控分发的数据集还是用本地命令行工具校验更稳妥。4. 解压之后的数据结构别急着写代码先看目录4.1 按摄像头对划分的顶层目录解压完成后打开目标目录你会看到一套按摄像头对组织的目录树。官方版本里最典型的结构是顶层先按摄像头对分目录常见的命名有c1_2、c3_4这样表示“摄像头 1 和摄像头 2 数据对”的形式再往下是 train 和 test 的划分最底层才是行人的身份编号目录。每个身份编号目录下存放的是该行人在这一摄像头视角下拍摄到的所有图像。这种组织方式非常直观——训练阶段你从 train 目录下的身份中随机挑图测试阶段在 test 目录中构造 query 和 gallery。需要提醒的是如果你下载的版本来自第三方镜像目录命名很可能被重新整理过可能是cam1、cam2也可能把 train/test 直接合并。所以拿到数据后第一件事不是写加载脚本而是把7z l输出或者解压后的目录结构完整看一遍摸清楚三层关系摄像头对 — 训练/测试划分 — 身份编号。4.2 图像命名里藏着的信息ReID 数据集的图像文件名通常不是随机字符串而是携带了编码信息。比如一个典型文件名可能形如0001_1_1.png或者0012_c2_f003.png不同的发布版本编码规则不同但核心含义通常是身份编号、摄像头编号、帧序号或图片序号。理解命名规则对你做实验很有帮助。比如在构造跨摄像头匹配时「同一个身份编号在摄像头 A 下的所有图像」和「同一个身份编号在摄像头 B 下的所有图像」分别构成 query 和 gallery这个划分完全依赖文件名中的身份和摄像头字段。如果命名规则理解错了构造出来的训练测试对就是错的实验结论完全不可信。碰到命名含义不清楚的情况不用急着猜可以翻一下随数据集一起发布的 README或者从下载页面找说明文档。CUHK02 这类老牌数据集网上也有不少研究者整理过字段说明搜索一下就能找到。4.3 写一个不依赖任何深度学习框架的加载脚本在正式用 PyTorch 或 TensorFlow 写 DataLoader 之前我建议你先写一个纯 Python 的目录扫描脚本确认数据读得进来、标签映射正确。这个脚本后续也可以直接改造成自定义 Dataset 类。下面这个脚本用递归方式扫描目录返回(图像路径, 身份编号, 训练/测试标记)的元组列表import os from pathlib import Path def scan_cuhk02(root): samples [] for cam_pair in sorted(Path(root).iterdir()): if not cam_pair.is_dir(): continue for split in [train, test]: split_dir cam_pair / split if not split_dir.exists(): continue for person_dir in sorted(split_dir.iterdir()): if not person_dir.is_dir(): continue person_id person_dir.name for img_file in sorted(person_dir.glob(*.png)): samples.append((str(img_file), person_id, split, cam_pair.name)) return samples扫描完成后检查一下总样本数是否和官方说明一致再随机打印几条记录确认路径拼接正确。这一步做完、确认无误再去接 PyTorch 的ImageFolder或者自定义Dataset能省掉大量调试时间。5. 实战里绕不开的坑与经验5.1 解压慢、磁盘占用翻倍根源是文件数量很多数据集压缩包解压慢瓶颈不在 CPU 而在文件数量。一个 7z 压缩包里的文件数量可能多达数万甚至数十万每个小文件创建时都要消耗系统调用整体耗时自然就上去了。CUHK02 的行人图像都是小文件几千上万个文件很正常。如果你在服务器上解压时发现速度慢得离谱可以先看一下磁盘空间和 inode 是否充足。Linux 下可以用df -h看磁盘空间用df -i看 inode 剩余量。inode 耗尽时磁盘明明有空余却提示“No space left on device”非常容易让人误判。另外解压前后的临时空间也要留足。7z 在解压过程中需要一些临时空间如果磁盘剩余空间刚好接近压缩包解压后的体积很容易在最后关头报错。建议预留至少 1.5 倍于解压后体积的磁盘空间再动手。5.2 不要用7z e替代7z x这算是一个经典误区。7z e命令会把压缩包内所有文件解压到同一个目录忽略原始目录结构7z x则保留完整路径。对于 CUHK02 这种靠目录层级组织信息的数据集一旦用了7z e所有身份目录会全部拍平结果就是不同身份的文件混在一个目录里数据直接废掉。有人可能觉得“我后面反正要自己整理”但 ReID 数据集的目录结构包含摄像头对和 train/test 划分等语义信息拍平之后再恢复成本极高。所以任何时候都优先用7z x。如果你已经不小心用7z e解压了且原始压缩包还在最省事的办法是重新找一个干净目录用7z x再解压一次别在原目录上试图恢复。5.3 关于加密 7z 压缩包的一个补充前面提到过一些数据集发布方会用 7z 的加密特性做访问控制。如果你拿到的不是公开的 CUHK02而是某个受控分发的 7z 包解压命令会略有不同7z x encrypted.7z -p你的密码如果不直接写密码7z 也会在解压时交互式提示输入。注意-p参数和密码之间也不要加空格。另外加密 7z 包的解压速度通常比未加密的慢因为需要额外解密这是正常现象。如果你在解压加密包时长时间卡住不动优先检查是不是密码错误——7z 在密码错误时可能不会立刻报错而是持续尝试。CUHK02 本身是公开数据集正常下载的版本不需要密码。如果你在网上某个渠道下载后发现需要密码大概率是镜像站二次打包时自行加的建议回官方源重新下载。5.4 给 ReID 实验的几点建议数据解压好、加载脚本跑通之后还有几个细节会影响你后续实验的复现效果。第一建议统一图像预处理方式。CUHK02 不同摄像头对的图像尺寸可能不一致训练前最好统一缩放到固定尺寸比如 128×64 或者 256×128否则一个 batch 里的图像无法直接堆成张量。缩放时建议记录原始尺寸方便后续做分辨率相关的分析。第二训练集和测试集之间不要混用身份。前文说过CUHK02 的身份分布在多个摄像头对之间有重叠构造训练测试划分时一定要确认同一个身份不会同时出现在 train 和 test 里否则会出现“模型见过这个人的测试图”的泄漏问题指标虚高但实际无用。第三如果实验需要和论文结果对比尽量用官方提供的标准划分不要自己随机划分。每个数据集的标准评测协议不同用错划分方式会导致结果完全不可比。很多论文对 CUHK02 的测评方法其实不太统一动手前先去查一下目标论文具体用了哪一套划分再做实验。最后一点老数据集在今天的硬件上跑起来非常快几分钟就能训出一个 baseline很适合用来验证新想法是否有效。但也正因为体量不大结果方差相对较大跑实验时建议固定随机种子多跑几次取平均不要拿单次结果下结论。本文还有配套的精品资源点击获取
返回列表