避坑指南:MMDetection中test.bbox.json生成失败的5个常见原因及解决方法

避坑指南:MMDetection中test.bbox.json生成失败的5个常见原因及解决方法

如果你正在使用MMDetection进行目标检测任务,并且已经成功训练了模型,那么生成测试集的预测结果文件 test.bbox.json 通常是项目交付或参加竞赛前的最后一步。这个文件包含了模型在测试集上所有图像的预测边界框信息,是进行性能评估和结果提交的关键。然而,许多开发者在执行 tools/test.py 脚本时,常常会遇到一个令人困惑的情况:模型推理正常,日志也显示评估完成,但就是找不到那个至关重要的 test.bbox.json 文件。这就像一场精心准备的演出,最后谢幕的环节却出了问题,让人倍感挫败。

这篇文章就是为你准备的。我们假设你已经熟悉MMDetection的基本工作流程,包括配置环境、准备数据集、修改配置文件以及进行训练。现在,你正卡在生成预测结果这一步。我们将深入剖析导致 test.bbox.json “失踪”的五个最常见、也最容易被忽视的原因,并提供经过实战检验的解决方案。这些坑,有些源于配置文件的细微差别,有些与数据集的格式紧密相关,还有些涉及到评估器(Evaluator)的特定工作模式。理解这些,不仅能帮你快速解决问题,更能让你对MMDetection的评估机制有更深刻的认识。

1. 评估器配置:format_only 参数是开关

第一个,也是最核心的原因,往往出在评估器的配置上。MMDetection的评估流程分为两个主要模式:性能评估模式结果格式化输出模式。默认情况下,我们运行测试脚本是为了查看模型的mAP、Recall等指标,这时评估器处于性能评估模式。而生成 test.bbox.json 文件,则需要明确地将评估器切换到结果格式化输出模式。

这个模式的切换,由一个关键的布尔参数控制:format_only

1.1 理解 format_only 的双重职责

在MMDetection的 CocoMetric 评估器中,format_only 参数扮演着交通警察的角色:

  • format_only=False(默认值)时,评估器会读取数据集的真实标注(Ground Truth),将模型的预测结果与真实标注进行比对,计算并输出各类性能指标(如 bbox_mAP)。此时,它不会生成用于提交的JSON文件。
  • format_only=True 时,评估器会“忽略”真实标注(即使你提供了),它的唯一任务就是将模型的原始预测结果,按照COCO评估格式的要求,整理并保存到一个JSON文件中。这就是我们需要的 test.bbox.json

很多人在配置文件中直接使用了训练或验证时的评估器配置,而那里通常 format_only=False。因此,即使你指向了测试集,脚本也只会计算指标(如果测试集有标注的话),或者什么都不输出(如果测试集无标注),而不会生成文件。

1.2 如何正确配置

你需要在你的测试配置中,明确设置 test_evaluator。以下是一个标准的配置示例:

# 在你的 config.py 文件中,例如 faster_rcnn_r50_fpn_1x_coco.py
# 找到或添加 test_dataloader 和 test_evaluator 部分

# 测试数据加载器,通常与验证集配置类似,但指向测试集路径
test_dataloader = dict(
    batch_size=1,
    num_workers=2,
    persistent_workers=True,
    drop_last=False,
    sampler=dict(type='DefaultSampler', shuffle=False),
    dataset=dict(
        type='CocoDataset',
        data_root='data/coco/',
        ann_file='annotations/image_info_test-dev2017.json', # 测试集标注文件(通常只包含图像信息,无真实框)
        data_prefix=dict(img='test2017/'),
        test_mode=True,
        pipeline=test_pipeline))

# 关键:测试评估器配置
test_evaluator = dict(
    type='CocoMetric',
    ann_file='data/coco/annotations/image_info_test-dev2017.json', # 必须与 test_dataloader 中的 ann_file 一致
    metric='bbox',
    format_only=True,  # !!!核心:设置为 True 以启用结果输出
    outfile_prefix='./work_dirs/faster_rcnn/test'  # 输出文件的前缀
)

注意:outfile_prefix 参数定义了输出文件的路径和前缀。最终生成的JSON文件全名将是 {outfile_prefix}.bbox.json。例如,上述配置会生成 ./work_dirs/faster_rcnn/test.bbox.json。请确保你有对该目录的写入权限。

内容概要:本文详细记录了对一个Android ARM64静态ELF文件中字符串加密机制的逆向分析过程。该ELF文件的所有字符串均被加密,无法通过常规strings命令或IDA直接识别。作者通过分析发现,加密字符串存储在.rodata段,其解密所需信息(包括密文地址、长度和16位密钥)保存在.data.rel.ro段的40字节描述符中。核心解密函数sub_10F408采用自反的双pass流密码算法,结合固定密钥KEY_TERM(由.data段24字节数据计算得出),实现字节级非线性、位置与长度相关的加密。文章还复现了完整的Python解密脚本,并揭示了该保护机制的本质为代码混淆而非强加密,最终成功批量解密全部956条字符串,暴露程序真实行为,如shell命令模板、设备标识篡改、网络重置等操作。此外,文中还提及未启用的自定义壳框架及其反dump设计。; 适合人群:具备逆向工程基础的安全研究人员、二进制分析人员及对ELF保护技术感兴趣的开发者。; 使用场景及目标:①学习ELF二进制中字符串加密的典型实现方式与逆向突破口;②掌握从结构识别、函数追踪到算法还原的完整逆向流程;③理解“绑定二进制”的完整性校验设计及其局限性;④实践编写IDAPython脚本自动化提取与解密敏感数据。; 阅读建议:此资源以实战案例驱动,不仅展示技术细节,更强调逆向思维与验证方法,建议读者结合IDA调试环境,逐步跟随文中步骤进行动态分析与算法验证,深入理解每一步的推理依据。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值