YOLOV3
YOLOV3 copied to clipboard
Peterisfar
multi_scale在单个epoch里面并不起作用？
因为我自己的需求问题，需要在训练集中额外加一些其他东西，然后想看一下每个batch的tensor大小，结果发现，在单个epoch里的图片大小全都是448，图片大小并没有随着multi_scale的代码而改变。
我自己打印tensor.size的代码在imgs = imgs.to(self.device)之后，multi_scale代码在https://github.com/Peterisfar/YOLOV3/blob/03a834f88d57f6cf4c5016a1365d631e8bbbacea/train.py#L131-L134。
Epoch:[ 0 | 49 ] Batch:[ 0 | 2068 ] loss_giou: 2.3399 loss_conf: 1.8814 loss_cls: 1.1482 loss: 5.3695 lr: 0
torch.Size([8, 3, 448, 448])
torch.Size([8, 3, 448, 448])
torch.Size([8, 3, 448, 448])
torch.Size([8, 3, 448, 448])
torch.Size([8, 3, 448, 448])
torch.Size([8, 3, 448, 448])
torch.Size([8, 3, 448, 448])
torch.Size([8, 3, 448, 448])
torch.Size([8, 3, 448, 448])
multi_scale_img_size : 512
torch.Size([8, 3, 448, 448])
Epoch:[ 0 | 49 ] Batch:[ 10 | 2068 ] loss_giou: 2.0293 loss_conf: 3.2374 loss_cls: 2.2489 loss: 7.5156 lr: 2.41663e-07
torch.Size([8, 3, 448, 448])
torch.Size([8, 3, 448, 448])
torch.Size([8, 3, 448, 448])
torch.Size([8, 3, 448, 448])
torch.Size([8, 3, 448, 448])
torch.Size([8, 3, 448, 448])
torch.Size([8, 3, 448, 448])
torch.Size([8, 3, 448, 448])
torch.Size([8, 3, 448, 448])
multi_scale_img_size : 512
torch.Size([8, 3, 448, 448])
Epoch:[ 0 | 49 ] Batch:[ 20 | 2068 ] loss_giou: 2.1348 loss_conf: 2.8944 loss_cls: 2.2905 loss: 7.3198 lr: 4.83325e-07
torch.Size([8, 3, 448, 448])
torch.Size([8, 3, 448, 448])
torch.Size([8, 3, 448, 448])
torch.Size([8, 3, 448, 448])
torch.Size([8, 3, 448, 448])
torch.Size([8, 3, 448, 448])
torch.Size([8, 3, 448, 448])
torch.Size([8, 3, 448, 448])
torch.Size([8, 3, 448, 448])
但在第一个epoch的最后，图片的大小成功改变了，不知道这是不是一个bug。
Epoch:[ 0 | 49 ] Batch:[ 2050 | 2068 ] loss_giou: 2.0007 loss_conf: 2.3295 loss_cls: 2.1310 loss: 6.4612 lr: 4.95408e-05
torch.Size([8, 3, 448, 448])
torch.Size([8, 3, 448, 448])
torch.Size([8, 3, 448, 448])
torch.Size([8, 3, 448, 448])
torch.Size([8, 3, 448, 448])
torch.Size([8, 3, 448, 448])
torch.Size([8, 3, 448, 448])
torch.Size([8, 3, 448, 448])
torch.Size([8, 3, 448, 448])
multi_scale_img_size : 544
torch.Size([8, 3, 448, 448])
Epoch:[ 0 | 49 ] Batch:[ 2060 | 2068 ] loss_giou: 1.9995 loss_conf: 2.3252 loss_cls: 2.1278 loss: 6.4524 lr: 4.97825e-05
torch.Size([8, 3, 448, 448])
torch.Size([8, 3, 448, 448])
torch.Size([8, 3, 448, 448])
torch.Size([8, 3, 448, 448])
torch.Size([8, 3, 448, 448])
torch.Size([8, 3, 448, 448])
torch.Size([8, 3, 448, 448])
torch.Size([7, 3, 448, 448])
torch.Size([8, 3, 544, 544])
后续又进行了测试，发现确实是bug。在第二个epoch中，图片大小固定为544，不会随着multi_scale的代码改变。
Epoch:[ 1 | 49 ] Batch:[ 0 | 2068 ] loss_giou: 4.5290 loss_conf: 5.0386 loss_cls: 3.1196 loss: 12.6872 lr: 5e-05
torch.Size([8, 3, 544, 544])
torch.Size([8, 3, 544, 544])
torch.Size([8, 3, 544, 544])
torch.Size([8, 3, 544, 544])
torch.Size([8, 3, 544, 544])
torch.Size([8, 3, 544, 544])
torch.Size([8, 3, 544, 544])
torch.Size([8, 3, 544, 544])
torch.Size([8, 3, 544, 544])
multi_scale_img_size : 352
torch.Size([8, 3, 544, 544])
Epoch:[ 1 | 49 ] Batch:[ 10 | 2068 ] loss_giou: 2.8269 loss_conf: 2.6757 loss_cls: 2.4601 loss: 7.9626 lr: 5.02417e-05
torch.Size([8, 3, 544, 544])
torch.Size([8, 3, 544, 544])
torch.Size([8, 3, 544, 544])
torch.Size([8, 3, 544, 544])
torch.Size([8, 3, 544, 544])
torch.Size([8, 3, 544, 544])
torch.Size([8, 3, 544, 544])
torch.Size([8, 3, 544, 544])
torch.Size([8, 3, 544, 544])
multi_scale_img_size : 480
torch.Size([8, 3, 544, 544])
Epoch:[ 1 | 49 ] Batch:[ 20 | 2068 ] loss_giou: 2.5572 loss_conf: 2.7106 loss_cls: 2.5338 loss: 7.8016 lr: 5.04833e-05
torch.Size([8, 3, 544, 544])
torch.Size([8, 3, 544, 544])
torch.Size([8, 3, 544, 544])
torch.Size([8, 3, 544, 544])
torch.Size([8, 3, 544, 544])
torch.Size([8, 3, 544, 544])
torch.Size([8, 3, 544, 544])
torch.Size([8, 3, 544, 544])
torch.Size([8, 3, 544, 544])
但今天在自己电脑上测试的时候，发现又没有问题了。经过后续测试，发现是train_dataloader的num_workers数量问题，如果置为0，作者的multi_scale代码正常运行，但是如果num_workers置为cpu总核数，代码就会出现我上面描述的问题。
但今天在自己电脑上测试的时候，发现又没有问题了。经过后续测试，发现是train_dataloader的num_workers数量问题，如果置为0，作者的multi_scale代码正常运行，但是如果num_workers置为cpu总核数，代码就会出现我上面描述的问题。
你的pytorch版本是啥
但今天在自己电脑上测试的时候，发现又没有问题了。经过后续测试，发现是train_dataloader的num_workers数量问题，如果置为0，作者的multi_scale代码正常运行，但是如果num_workers置为cpu总核数，代码就会出现我上面描述的问题。
你的pytorch版本是啥
我的torch版本是1.7.1
但今天在自己电脑上测试的时候，发现又没有问题了。经过后续测试，发现是train_dataloader的num_workers数量问题，如果置为0，作者的multi_scale代码正常运行，但是如果num_workers置为cpu总核数，代码就会出现我上面描述的问题。
你的pytorch版本是啥
我的torch版本是1.7.1
我的是1.0.0的，使用前请看一下开源代码软件硬件环境，这是最基本的。你可以换成1.0.0再试一下这个多尺度训练是否有效果
但今天在自己电脑上测试的时候，发现又没有问题了。经过后续测试，发现是train_dataloader的num_workers数量问题，如果置为0，作者的multi_scale代码正常运行，但是如果num_workers置为cpu总核数，代码就会出现我上面描述的问题。
你的pytorch版本是啥
我的torch版本是1.7.1
我的是1.0.0的，使用前请看一下开源代码软件硬件环境，这是最基本的。你可以换成1.0.0再试一下这个多尺度训练是否有效果
好的，谢谢
但今天在自己电脑上测试的时候，发现又没有问题了。经过后续测试，发现是train_dataloader的num_workers数量问题，如果置为0，作者的multi_scale代码正常运行，但是如果num_workers置为cpu总核数，代码就会出现我上面描述的问题。
你的pytorch版本是啥
我的torch版本是1.7.1
我的是1.0.0的，使用前请看一下开源代码软件硬件环境，这是最基本的。你可以换成1.0.0再试一下这个多尺度训练是否有效果
我刚刚进行了测试，python的库版本跟requirements.txt完全符合，但打印出来的img.size，表明multi_scale仍然是不起作用的。 我个人觉得是num_worker设置非0时，多线程加载数据所导致的问题。
在ultralytics的repo中也出现了这个问题，他刚开始通过硬编码，通过让num_workers=0来解决。后来，直接改成每个batch都会做一次multi_scale，同时表明这样做不会对训练造成很大影响。
链接： https://github.com/ultralytics/yolov3/issues/174 https://github.com/ultralytics/yolov3/issues/1119
除此以外，我想过用dataset的collate_fn函数去解决，但num_worker设置非0仍然会导致这样的问题。
但今天在自己电脑上测试的时候，发现又没有问题了。经过后续测试，发现是train_dataloader的num_workers数量问题，如果置为0，作者的multi_scale代码正常运行，但是如果num_workers置为cpu总核数，代码就会出现我上面描述的问题。
你的pytorch版本是啥
我的torch版本是1.7.1
我的是1.0.0的，使用前请看一下开源代码软件硬件环境，这是最基本的。你可以换成1.0.0再试一下这个多尺度训练是否有效果
我刚刚进行了测试，python的库版本跟requirements.txt完全符合，但打印出来的img.size，表明multi_scale仍然是不起作用的。 我个人觉得是num_worker设置非0时，多线程加载数据所导致的问题。
在ultralytics的repo中也出现了这个问题，他刚开始通过硬编码，通过让num_workers=0来解决。后来，直接改成每个batch都会做一次multi_scale，同时表明这样做不会对训练造成很大影响。
链接： ultralytics/yolov3#174 ultralytics/yolov3#1119
除此以外，我想过用dataset的collate_fn函数去解决，但num_worker设置非0仍然会导致这样的问题。
ok，那你反应的问题是存在的，dataloader 在num=0时，每次会加载dataset一遍，多线程这个逻辑会有问题。你可以在你那边进行优化比如把resize写一个tensor版本的放到train中等等，你可以提交request，我会把你的工作加进来。谢谢
但今天在自己电脑上测试的时候，发现又没有问题了。经过后续测试，发现是train_dataloader的num_workers数量问题，如果置为0，作者的multi_scale代码正常运行，但是如果num_workers置为cpu总核数，代码就会出现我上面描述的问题。
你的pytorch版本是啥
我的torch版本是1.7.1
我的是1.0.0的，使用前请看一下开源代码软件硬件环境，这是最基本的。你可以换成1.0.0再试一下这个多尺度训练是否有效果
我刚刚进行了测试，python的库版本跟requirements.txt完全符合，但打印出来的img.size，表明multi_scale仍然是不起作用的。 我个人觉得是num_worker设置非0时，多线程加载数据所导致的问题。 在ultralytics的repo中也出现了这个问题，他刚开始通过硬编码，通过让num_workers=0来解决。后来，直接改成每个batch都会做一次multi_scale，同时表明这样做不会对训练造成很大影响。 链接： ultralytics/yolov3#174 ultralytics/yolov3#1119 除此以外，我想过用dataset的collate_fn函数去解决，但num_worker设置非0仍然会导致这样的问题。
ok，那你反应的问题是存在的，dataloader 在num=0时，每次会加载dataset一遍，多线程这个逻辑会有问题。你可以在你那边进行优化比如把resize写一个tensor版本的放到train中等等，你可以提交request，我会把你的工作加进来。谢谢
我之前就想过修复来着，但您这个repo的话，在train里面去resize比较麻烦，在resize imgs的同时，还要调整label_sbbox， label_mbbox，label_lbbox，这三个东西，但是这三个东西是在imgs从dataloader加载时，就已经确定的，很难在这之后进行修改。
因为水平所限，我只想到把__creat_label那部分挪到train里面，但那样话，对代码改动就很大，然后代码可能就不是您那个风格了，我觉得还是您自己想一下如何修改比较好，看有没有很好的解决方案。