About batch and frame

Hi @j96w ! Thank you for your work. line 131~154 in train.py

            for i, data in enumerate(dataloader, 0):
                #…………
                train_count += 1

                if train_count % opt.batch_size == 0:
                    logger.info('Train time {0} Epoch {1} Batch {2} Frame {3} Avg_dis:{4}'.format(time.strftime("%Hh %Mm %Ss", time.gmtime(time.time() - st_time)), epoch, int(train_count / opt.batch_size), train_count, train_dis_avg / opt.batch_size))

I think one iteration is one batch, so batch number should be equivalent to train_count. In logger.info, why batch number equals int(train_count / opt.batch_size), and frame number equals train_count?

[j96w]

To realize the pixel-wise dense fusion idea we introduced in this work, we need to keep the correspondence relationship between each RGB pixel and its corresponding depth (see the correspondence index choose return by the dataloader in each iteration). The main problem here about batch training is the size of the input RGB-D crops are different (with a large variance from 40x40 to 400x400 because of the different size of the objects). If we resize or use padding to make them the same size like most other works did, the correspondence relationship will be hard to maintain, since the resize of the depth image is different from the RGB resize and will lead to the deformation of the pointcloud generated from the resized depth. Thanks for mention this point, we have already got a buffering idea to improve the training efficiency of this code WRT this issue and will update soon.

[emigmo]

@gaobaoding hi, I can explain your confuse. in pytorch, first “batch_size” times “loss.backward()” and then follow “optimizer.step()”, all the loss will be summed automatically and do one bp to update the parameters (SGD). but “optimizer.step()” after each “loss.backward()” would update the parameters at each time (GD). SGD will be better than GD, I think you know that.