1. 三个数据集分别解决了什么问题1.1 Pittsburgh250k视觉地点识别模型的标准训练场做视觉地点识别Visual Place Recognition简称 VPR的人基本都绕不开 NetVLAD 这条经典路线而 Pittsburgh250k 就是 NetVLAD 论文里用来训练端到端地点识别模型的大规模数据集。它采集自美国匹兹堡的 Google Street View 全景图像整套数据包含约 25 万张街景图每张图都带对应的 GPS 坐标。这里说一句我自己的理解这个数据集的定位是训练场不是考卷。官方配套的测试协议更多使用 Pittsburgh 30k 这样的子集所以很多论文里写的是在 Pittsburgh250k 上训练在 Pittsburgh 30k 上测试下载前最好看清楚你要的是 25 万张那部分还是连测试协议和索引文件一起拿。这个数据集为什么重要因为 VPR 模型和图像分类模型不一样它学习的不是这是什么物体而是这两张图是不是同一个地方。要做到这一点模型需要见过海量不同视角、不同距离下的同一地点图像。Pittsburgh250k 的价值就在于它提供了这种极其丰富的正样本来源同一段街道街景车从不同位置拍到的多张全景图配合 GPS 距离就能自动构造出数千上万组同一个地方的训练对。1.2 Tokyo247专门用来考验跨域泛化能力的评测集Tokyo247 的规模比 Pittsburgh250k 小得多总共 247 张查询图像配套的参考图库数量也在千到万级具体以官方页面标注为准。规模虽小难度却一点不低。它的难点不在数量而在域差距。查询图像是拿手机在东京街头实际拍摄的参考库则是 Google Street View 街景图。相机型号不同、拍射时间不同、光照和季节也不同这正好戳中了 VPR 模型最容易翻车的点训练集里没见过这样的视角和成像风格模型还能不能认出来所以 Tokyo247 非常适合做快速验证。我自己的习惯是模型先在 Pittsburgh250k 上训练好然后直接拿 Tokyo247 评测一轮检索精度半天就能得到一版有说服力的跨域结果不用像其他数据集那样先折腾一整天的格式转换。1.3 TokyoTimeMachine为长时重定位准备的连续时间序列TokyoTimeMachine常被简写为 TokyoTM解决的问题和前面两个不一样同一个地方白天和黑夜、晴天和雨天、三月份和九月份视觉外貌可能完全是两个样子。这个数据集取东京某段城区路线在多个时间点对同一路径做连续拍摄记录了大量按时间组织的遍历序列traversal同时配有街景参考图库和 GPS 轨迹。它和前两个数据集最大的区别是连续。图像不是一个个孤立的样本而是构成一条有前后顺序的序列。这意味着你可以评测带时序约束的重新定位算法比如根据前面几帧的结果推断当前帧更可能出现在哪里。做机器人和自动驾驶长期运行定位的朋友基本都会用到它。下这种序列化数据集时目录结构就是命根子我在后面会专门讲怎么保住它。为了方便下手我把三个数据集的核心信息归纳成一张表数据集主要内容典型用途数据集形态Pittsburgh250k约25万张匹兹堡街景图带GPS坐标VPR模型训练尤其适合NetVLAD类方法单一大压缩包解压后大量jpgTokyo247247张手机实拍查询图 街景参考图库跨域检索评测、模型快速迭代参考库查询图体积中等TokyoTimeMachine东京城区多条时间序列图像 参考图库长时重定位、序列级VPR评测多traversal目录按时间组织注具体图像张数和压缩包体积请以官方页面当时显示的数据为准这里给的是数量级参考避免你拿着我的数字去比对发现对不上。2. 官方下载渠道从 NetVLAD 主页到文件落盘2.1 定位 NetVLAD 项目主页的 Dataset 区域三个数据集的官方入口都集中在 NetVLAD 项目主页地址是 http://www.di.ens.fr/willow/research/netvlad/ 。打开页面后不要急着找 Download 按钮往下滚动到 Dataset 部分。项目方把 Pittsburgh250k、Tokyo247、TokyoTM 以及相关的预处理工具脚本放在一起每个数据集名称后面跟一个下载链接。我建议第一次访问时先用 CtrlF 搜Dataset或Download把这一整块内容截图存档。原因很实际学术项目的下载链接和文件名会随时间调整存档后你核对下载文件时有个依据不至于过两天回来看发现页面改版了对着已经下载到一半的文件发愣。顺便说一句页面上往往还有 NetVLAD 预训练模型权重它和数据集的链接长得很像别下错。2.2 不同数据集的下载形态实际点开下载链接后你会遇到两种常见形态。第一种是直接返回压缩包比如 .tar 或 .zip 文件里面是全部图像和标注文件。这种最简单浏览器或命令行直接拉就行。第二种是跳转到一个文件索引页让你自己选下载哪个分卷或哪个版本。Pittsburgh250k 因为文件量大经常是分卷打包需要把全部分卷都下完整只下第一个分卷是解不开的。Tokyo247 和 TokyoTM 相对小一些但 TokyoTM 的多趟序列图像加起来也不少官方可能把每条 traversal 单独打包也可能全部合成一个大包。下载前一定先读页面上的说明文字看清楚每个包是干什么的哪些是必需的哪些是可选的其他分辨率版本。2.3 动手指前先确认磁盘、工具和授权第一件事是磁盘空间。Pittsburgh250k 解压后的图片数量在 25 万级别这远超一般人的直觉。下命令前在目标目录执行df -h .确认剩余空间至少是压缩包体积的三倍以上。压缩包本身不小解压出来的文件更大提前留足余量能帮你避免下载到一半磁盘爆掉的尴尬。第二件事是解压工具。Linux 和 macOS 上直接用 tar、unzip 就行Windows 上强烈建议用 7-Zip或者直接用 WSL 里的 tar 命令原因后面在第 6 节细说。第三件事是授权约定。NetVLAD 页面通常会在数据集部分标注引用要求一般要求引用 NetVLAD 论文。个人学习和科研复现没有障碍但如果你想商用或者把数据二次分发务必要先读页面上的 terms of use这是基本的职业习惯。3. 下载方式选择断点续传、并发参数与控制台托管3.1 为什么别用浏览器直接下大文件第一次下载这种几个 GB 起步的文件很多人习惯用浏览器点链接。浏览器不是不能用但一旦断网、笔记本休眠、或者误关标签页进度条就从零开始。学术服务器的带宽情况通常也就那样下载速度忽快忽慢是常态所以我后来完全改用命令行工具。最底线的方案是 wget 加断点续传参数wget -c -t 0 --timeout60 -O Pittsburgh250k.tar.gz 官方下载链接解释一下参数-c表示续传中断后重跑同一命令会接着上次进度走-t 0表示无限重试--timeout60表示 60 秒没有数据传输就断开当前连接并重试。这三个参数组合起来非常能扛。如果你还担心终端关了任务就没了先在命令行执行tmux new -s download开一个会话把下载命令放进去跑关掉终端窗口也不影响。3.2 用 aria2 做多线程下载的参数参考wget 对很多学术服务器已经够用但如果网络条件允许用 aria2 可以明显提升速度aria2c -c -x 8 -s 8 -k 1M -d . -o Pittsburgh250k.tar.gz 官方下载链接含义分别是-x 8向同一服务器最多发起 8 个连接-s 8把文件切成 8 块并行下载-k 1M每块大小 1MB-d指定保存目录-o指定文件名。再加两个参数能提高容错性--max-tries0表示无限重试--retry-wait5表示失败后等 5 秒再重试。有一点必须提醒并发连接数不是越大越好。学术服务器的连接数和带宽限制各不相同开太高可能触发限流甚至短时间内连不上。我自己的经验是从 4 到 8 开始试发现速度没有明显提升就降回 4不要盲目开 16 个连接。3.3 下载完成不等于数据可用压缩包落到本地后先做两件事校验完整性再看解压能否通过。如果官方页面提供了 MD5 或 SHA 校验和下载完立刻执行md5sum Pittsburgh250k.tar.gz sha256sum Pittsburgh250k.tar.gz即使没有校验和也可以用 tar 列出压缩包内容的前几项tar -tzf Pittsburgh250k.tar.gz | head -20能正常列出文件列表说明这个包至少是完整可读的。如果解压到一半提示 unexpected end of file基本可以断定下载不完整。这时候回到 wget -c 继续续传或者用 aria2 重新下载不要心存侥幸去解压第二次。判断一个文件是真完整还是假完整解压过一遍才算数。3.4 分卷包别漏合包有讲究如果你下载的是分卷压缩包比如part1.tar.gz、part2.tar.gz这种第一个要注意的就是把全部分卷下齐一个都不能少。第二个要注意的是解压方式有的分卷需要先合并再解压有的分卷用 tar 直接指定第一个分卷就能连续读取。稳妥做法是把所有分卷放在同一目录然后用对应工具按官方文档提示的步骤操作。如果页面没写先试直接解压第一个分卷失败再考虑用cat合并cat Pittsburgh250k.part1.tar.gz Pittsburgh250k.part2.tar.gz Pittsburgh250k.tar.gz合并后文件大小等于各分卷之和再用tar -tzf验证。4. 解压后的目录与组织方式4.1 通用的 database / queries 结构这类图像检索数据集的组织逻辑是相通的一个参考图像库database一组待检索的查询图像queries外加记录图像位置的 GPS 或里程计信息。我拿到的版本大致是这个结构Pittsburgh250k/ ├── database/ │ ├── 000000.jpg │ ├── 000001.jpg │ └── ... ├── queries/ │ ├── 000000.jpg │ └── ... ├── utm/ │ ├── database_utm.mat │ └── queries_utm.mat └── readme.txt具体文件夹命名会随打包版本变化但图像文件夹 位置文件的大结构基本不变。有一点要特别注意NetVLAD 官方代码读取数据依赖 .mat 格式的索引文件而不是自己递归扫描目录。也就是说代码里写好了要加载pitts30k_test.mat之类的索引文件通过里面的数组索引去图片目录里取具体图像。所以你拿到数据后先别急着按自己的喜好改名改目录先看官方代码期望的是什么样的数据布局。4.2 TokyoTimeMachine 的多遍历序列结构TokyoTM 解压后你会看到一长串按编号命名的目录每个目录对应一次独立时间点的采集。这种结构下单张图像属于第几趟、在序列里排第几都隐含在目录名和文件名里。做序列级重定位时这些信息就是你的时间约束来源。我自己的经验是拿到 TokyoTM 后先读 readme 和目录清单统计有多少个 traversalls -d */ | wc -l然后把每条 traversal 对应的时间信息整理成一个文本文件记录下来。因为很多复现代码是按时间排序做序列检索的如果目录结构被打乱或者你把所有图片摊平到一个目录时间顺序就丢了下游实验没法做。另外文件名如果只是纯数字编号建议给每趟加一个可辨识的前缀比如t00_0001.jpg这样后面写 dataloader 时一眼能看出图片属于哪一趟。4.3 用脚本快速摸清数据的真实情况目录解压完先用一段小脚本做个体检避免实验跑起来才发现文件缺失或尺寸异常。下面这段用 Python 统计图片数量和抽查尺寸from PIL import Image from pathlib import Path import random img_dir Path(Pittsburgh250k/database) images list(img_dir.glob(*.jpg)) print(总图片数:, len(images)) for f in random.sample(images, min(20, len(images))): with Image.open(f) as im: print(f.name, im.size, im.mode)如果打印出来的尺寸不是统一的说明这个版本可能包含了不同分辨率的图像或者存在极少数的坏图需要提前做筛选处理。注意这里我用了im.size检查宽高但图像内容是否损坏还需要额外检查可以读取像素时加个 try 捕获异常把打不开的文件单独列出来。5. 第一次跑通前的自检图像、位置、索引三对齐5.1 图片文件数量与位置文件行数对应很多复现失败的根因不是模型写错而是数据没对齐图片有 25 万张位置文件却只有 24 万行或者顺序错乱。拿到数据后第一件事就是数数find database -type f | wc -l再把位置文件读出来比对行数和图片数量。对 .mat 文件用 scipy 读取import scipy.io as sio gnss sio.loadmat(Pittsburgh250k/utm/database_utm.mat, squeeze_meTrue, struct_as_recordFalse) print(gnss.keys()) # 常见变量名是 utm、pose 或 gps形状一般是 Nx2 或 Nx3 for k in gnss: if hasattr(gnss[k], shape): print(k, gnss[k].shape)如果你的版本是 .txt 或 .csv直接读文本确认行数即可。这一步多花五分钟能帮你省掉后面调试 bug 的五个小时。5.2 用 GPS 分布图验证数据没有张冠李戴一个简单但有效的验证随机抽取几十张图像的 GPS 坐标画个散点图看它们是否聚集在匹兹堡或东京区域。用 UTM 坐标的话分布应该在某个小区间里不会出现离谱的跳变。import matplotlib.pyplot as plt import scipy.io as sio gnss sio.loadmat(Pittsburgh250k/utm/database_utm.mat, squeeze_meTrue, struct_as_recordFalse) utm gnss[utm] # 按实际字段名调整 plt.scatter(utm[:, 0], utm[:, 1], s0.5) plt.axis(equal) plt.show()如果坐标点散落得到处都是或者出现明显的异常离群点说明位置文件的读取方式可能有问题或者文件和位置不是一一对应这时候不要继续往下做训练先排查清楚。这里用axis(equal)是为了避免 UTM 两个轴比例不一致导致区域形状看起来变形。5.3 把数据整理成官方代码能直接读取的形态NetVLAD 官方训练代码对数据目录有约定常见做法是准备项目要求的 .mat 索引文件里面记录训练集图像索引、测试集查询图像索引和对应 GPS。网上很多复现项目也会直接提供这些索引文件你可以基于官方数据自行生成。我的建议是不要盲改图片文件名而是用配置文件或符号链接的方式把路径指到正确位置。比如在项目目录里建一个data软链接指向你解压后真实的图片目录ln -s /path/to/Pittsburgh250k/database data/database这样既满足了代码的路径要求又不破坏原始数据的完整性。换机器或者换环境时重新建一下软链接就能跑不需要重新整理。6. 我在下载和处理过程中踩过的坑6.1 磁盘空间没算够inode 先爆了25 万张小文件对文件系统 inode 的消耗非常夸张。我有一次在服务器上下完 Pittsburgh250kdf -h看磁盘还剩 20GB但解压到一半开始报No space left on device排查半天才发现是 inode 配额用完了不是存储空间不够。所以解压前除了df -h .还应该执行df -i .看看索引节点余量。小文件越多inode 消耗越快很多人容易忽略这一点。如果你的文件系统 inode 本身就不多建议先把压缩包放到别的分区解压时直接指定到 inode 配额更大的目录。6.2 服务器不支持断点续传时wget -c 也会从零开始不是所有学术服务器都支持 Range 请求。wget -c 在服务器不支持 Range 的情况下会重新从零开始下载看起来像续传失败。判断方法很简单服务器返回的头信息里没有 Accept-Ranges 字段就说明它不支持分段下载。遇到这种情况单纯的-c参数没有意义。我的处理方法是先做一次完整的连接测试看平均下载速度然后挑连接质量最好的时段一次性下完如果中途断了就换 aria2 加--continue再试如果还是不行找找官方有没有备用镜像。另外提醒一句重试不要太频繁尤其是连续失败时。有些服务器对短时间内的连接次数有限制你可以把--retry-wait调到 10 秒甚至更长避免被短暂限流。6.3 Windows 上解压 25 万张小图片不只是慢的问题Windows 上直接双击解压大压缩包可能遇到两个问题一是 7-Zip 在 25 万张小文件上的解压速度骤降文件数量越多每个文件的操作开销越大总时间被拖得很长二是文件名过长触发系统的 MAX_PATH 限制解压到一半直接报错。我的经验是装好 WSL在 Linux 环境里用 tar 解压速度明显更快也绕开了长路径限制。如果必须用 Windows 原生环境至少先开启系统的长路径支持并且把解压目标放在磁盘根目录附近的短路径下比如D:\data\pitt而不是D:\Users\你的名字\Downloads\压缩包解压临时目录\pitt。6.4 第三方镜像下载后核对工作不能省官方服务器带宽有限高峰期速度慢是常见现象。很多研究者会把数据集镜像到公共数据平台或者网盘用来救急确实有效。但第三方镜像有时候打包逻辑和官方不同我有一次从网盘镜像下载的 TokyoTM解压后发现少了后面几趟 traversal要是直接拿去跑实验结果可想而知。从镜像下载完至少做三件事对比官方页面列出的文件数量、确认必需的目录都存在、跑一遍第 4.3 节的图片体检脚本。只有核对通过的数据才值得写进你的实验配置。另外也提醒一句不要在评论区和论坛里留下不恰当的下载渠道相关发言注意数据使用的合规性。最后说个我的习惯每次拿到这种大体积数据集我会立刻把校验和、目录结构和文件数量记录到项目 README 里。换机器、换环境或者同学问我要数据时直接照着这份清单重新下载核对省掉了大量重复排查时间。数据下载本身不产生论文但这一步做得扎实后面复现任何 VPR 相关的工作都会顺很多。