multi_scale在单个epoch里面并不起作用？

[crownz-sec]

因为我自己的需求问题，需要在训练集中额外加一些其他东西，然后想看一下每个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])

[crownz-sec]

后续又进行了测试，发现确实是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])

[crownz-sec]

但今天在自己电脑上测试的时候，发现又没有问题了。经过后续测试，发现是train_dataloader的num_workers数量问题，如果置为0，作者的multi_scale代码正常运行，但是如果num_workers置为cpu总核数，代码就会出现我上面描述的问题。

[Peterisfar]

但今天在自己电脑上测试的时候，发现又没有问题了。经过后续测试，发现是train_dataloader的num_workers数量问题，如果置为0，作者的multi_scale代码正常运行，但是如果num_workers置为cpu总核数，代码就会出现我上面描述的问题。

你的pytorch版本是啥

[crownz-sec]

但今天在自己电脑上测试的时候，发现又没有问题了。经过后续测试，发现是train_dataloader的num_workers数量问题，如果置为0，作者的multi_scale代码正常运行，但是如果num_workers置为cpu总核数，代码就会出现我上面描述的问题。

你的pytorch版本是啥

我的torch版本是1.7.1

[Peterisfar]

但今天在自己电脑上测试的时候，发现又没有问题了。经过后续测试，发现是train_dataloader的num_workers数量问题，如果置为0，作者的multi_scale代码正常运行，但是如果num_workers置为cpu总核数，代码就会出现我上面描述的问题。

你的pytorch版本是啥

我的torch版本是1.7.1

我的是1.0.0的，使用前请看一下开源代码软件硬件环境，这是最基本的。你可以换成1.0.0再试一下这个多尺度训练是否有效果

[crownz-sec]

但今天在自己电脑上测试的时候，发现又没有问题了。经过后续测试，发现是train_dataloader的num_workers数量问题，如果置为0，作者的multi_scale代码正常运行，但是如果num_workers置为cpu总核数，代码就会出现我上面描述的问题。

你的pytorch版本是啥

我的torch版本是1.7.1

我的是1.0.0的，使用前请看一下开源代码软件硬件环境，这是最基本的。你可以换成1.0.0再试一下这个多尺度训练是否有效果

好的，谢谢

[crownz-sec]

但今天在自己电脑上测试的时候，发现又没有问题了。经过后续测试，发现是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仍然会导致这样的问题。

[Peterisfar]

但今天在自己电脑上测试的时候，发现又没有问题了。经过后续测试，发现是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，我会把你的工作加进来。谢谢

[crownz-sec]

但今天在自己电脑上测试的时候，发现又没有问题了。经过后续测试，发现是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里面，但那样话，对代码改动就很大，然后代码可能就不是您那个风格了，我觉得还是您自己想一下如何修改比较好，看有没有很好的解决方案。