关于数据增强

[puyiwen]

大佬您好，我看到你的数据增强部分好像只有Totensor?其余的数据增强部分是没有加吗

[eugenelyj]

是的，在训练部分的代码里头，我现在还没release，过两天我弄下

[puyiwen]

是的，在训练部分的代码里头，我现在还没release，过两天我弄下

谢谢您的回复，我还想明确一个问题，关于TOF的。论文中说8x8的TOF是没办法得到对应像素的深度值，能得到深度分布。这个深度分布是个什么概念呢？我这边也有一个8X8的TOF，但是能得到64个像素点的绝对深度值。。。所以我不太理解为什么说没办法得到某一像素的深度值？

[eugenelyj]

@puyiwen 可以看下补充材料的Section B。像我们文章里提的这种ToF，他的每个“像素”都对应一个小的FoV的， 然后这个FoV内接收很多光子，每个对应的飞行时间转化成深度/路程信息之后就自然是一个深度的直方图了，也就是一个深度的分布信息。至于其他的ToF，有可能是返回了直方图的平均深度给我们（但仍然测量的是深度分布信息），也有可能是对应的FoV非常小以至于可以理解成是一根很细很细的ray，那这样对应的就可以认为测量的是一个三维点的深度了。

[puyiwen]

@puyiwen 可以看下补充材料的Section B。像我们文章里提的这种ToF，他的每个“像素”都对应一个小的FoV的， 然后这个FoV内接收很多光子，每个对应的飞行时间转化成深度/路程信息之后就自然是一个深度的直方图了，也就是一个深度的分布信息。至于其他的ToF，有可能是返回了直方图的平均深度给我们（但仍然测量的是深度分布信息），也有可能是对应的FoV非常小以至于可以理解成是一根很细很细的ray，那这样对应的就可以认为测量的是一个三维点的深度了。

感谢您的讲解。我在您的代码里找到了一个get_hist_parallel函数，这个函数有一个地方是hist = torch.stack([torch.histc(x, bins=int(max_distance/0.04), min=0, max=max_distance) for x in dep_patches], 0)，这个部分就是得到深度直方图的数据处理部分吗？这个深度直方图是不是已经和RGB对齐过了的呢？期待您的回复

[eugenelyj]

@puyiwen 有两个dataloader，一个是NYU的，一个ZJU-L5的，你说的get_hist_parallel函数只是在NYU里头调用了，这个函数作用是在仿真L5的信号。至于ZJU-L5的dataloader，你可以看这里，深度数据是处理好，和RGB对齐了的，这里直接加载进来就行了。另外，这里我们没有load深度直方图数据，L5为了减少带宽，传出来的数据是直方图拟合的均值和方差，这个在补充材料section B里也有写。

[eugenelyj]

@puyiwen 另外，在NYU上仿真后的数据增强代码是有的，只是fine-tune L5的代码没有，目前L5只上传了对应在testing集合上inference的代码。

[puyiwen]

@puyiwen 另外，在NYU上仿真后的数据增强代码是有的，只是fine-tune L5的代码没有，目前L5只上传了对应在testing集合上inference的代码。

感谢您的快速回复。另外，我想要一份您的L5和RGB对齐代码，想在我自己场景下做一些测试集进行测试，您这边方便发给我一份吗？我的邮箱是 291931809@qq.com

[puyiwen]

@puyiwen 另外，在NYU上仿真后的数据增强代码是有的，只是fine-tune L5的代码没有，目前L5只上传了对应在testing集合上inference的代码。

不好意思又打扰您了，我复现了train代码，就像您论文说的，以NYU_depth_v2深度图模拟L5信号。但是有些参数在config.py中没有标注，我想向您明确一下。train_zone_num、train_zone_random_offset、simu_max_distance，这三个参数您在训练的时候的值设置为多少？

[eugenelyj]

@puyiwen train_zone_num 是6， train_zone_random_offset 是0， simu_max_distance 是4.0米

[puyiwen]

@puyiwen train_zone_num 是6， train_zone_random_offset 是0， simu_max_distance 是4.0米

谢谢您的回复，我最近阅读了您的代码和论文还有补充材料，然后我有几个问题想向您请教一下。 模型结构方面：

1. 我看您论文中写的是用EfficientnetB5作为Encoder部分，但是代码里用的是Efficientnetv2_b3，这个修改是为什么？我没有复现过EfficientnetB5作为Encoder的代码，不知道这两个encoder对于整体模型精度有什么影响。
2. 您论文中写的是用MiniViT作为最后细化模块，我查阅了Adabins有关MiniViT部分的实现，发现您的代码其实是没有加入PatchTransformerEncoder和PixelWiseDotProduct这两个部分，这样做的目的是什么？ 模型推理方面： 1.我发现训练的时候train_zone_num设为6的话，那么送入PointNet的hist_data是36 zones，而在线推理时使用的ZJUL5数据的zones是64，训练和推理输入的hist_data数据维度不同也能顺利推理出来。。我不知道这个是为什么？ 其他问题： 我尝试将您代码RGB输入改为320240，模型可以训练，但是训练结果不正确。我具体修改过程如下： 1.将NYU和ZJUL5的Image和Depth统一resize为320240，train_zone_num 设置为3 2.然后将数据处理和模型结构代码中带有640和480的部分都改为320和240，把fusion.py中的resolution也相应的改动。 改动后的代码是可以运行的，我把RGB和depth都可视化出来，也是正确的。但是模型Loss下降缓慢，Delta1上升缓慢，而RMSE却一直在上升。这个训练结果很明显是不对的，我也没找到是哪里不对。。您能给我提一些建议吗？

不好意思提了这么多问题，这些问题对于我来说很重要，如果您有空能帮我解答一下，我将不胜感激。

[eugenelyj]

@puyiwen 感谢关注～

1. 关于网络模型的修改。原来的deltar推理速度有些慢（74ms），我们对其网络结构进行了优化对速度提升了一倍，提升到接近30fps。这部分改进的内容包括调整了encoder，去掉了minivit里的vit部分，只保留了adabins预测多个bins的那个formulation。对应的文字描述在我们paper的扩展版本里有，等录用后我会添加到readme里。
2. 关于训练的问题。我刚push了训练的代码，你可以试一下。如果有新的问题，欢迎再提问～

[puyiwen]

@puyiwen 感谢关注～

1. 关于网络模型的修改。原来的deltar推理速度有些慢（74ms），我们对其网络结构进行了优化对速度提升了一倍，提升到接近30fps。这部分改进的内容包括调整了encoder，去掉了minivit里的vit部分，只保留了adabins预测多个bins的那个formulation。对应的文字描述在我们paper的扩展版本里有，等录用后我会添加到readme里。
2. 关于训练的问题。我刚push了训练的代码，你可以试一下。如果有新的问题，欢迎再提问～

非常感谢大佬的回复和相关代码的补充。我看到nyu数据模拟L5信号的代码中，train_zone_num设置为6，那么就是6x6个区域，这样和8x8区域的TOF不同，这样会对模型产生影响吗？patch_height和patch_width您有修改为，当不同mode时这组数值也不同，64和56这两个数值是有什么依据吗？如果我缩小了RGB的分辨率，想训练时继续使用train_zone_num为6的话，patch_height和patch_width是否可以改为别的数值？期待大佬的回复~~

[eugenelyj]

@puyiwen 因为图像做了数据增强，有random crop，所以就塞不下8x8个区域了。区域个数应该会有些影响的，就像训练的分辨率比inference小也会带来一些影响。不过相比random crop带来的好处我觉得应该是可以接受的。测试的时候分辨率变回到640x480了，为了能塞下8x8个zone我就暴力的把patch大小变小了一点。需要注意的是，这个NYU的testing data只是用来简单判断下网络训练的情况的，不实际作为测试和对比的基准。

[puyiwen]

@puyiwen因为因为做数据数据，有有图像增强数据数据数据了，8x8个个个个了。区域个数个数应该应该会会有些有些有些有些，就影响影响影响影响的影响影响就就就像训练训练的带来的好地方我觉得应该是可以接受的。测试的时候分率变回640x480了，为了能塞下8x8个zone我就把补丁大小变小了的一点NY。需要注意的是，测试数据只是用简单判断下网络训练的情况的，并不实际用作测试和对比的基础。

大佬，你的zjuL5数据集中的fr代表是什么？后面处理后的input_data中的，pad_size、patch_size和index_wo_pad的意思是什么？我没有看懂这部分，期待大佬的回复~~

[eugenelyj]

@puyiwen 抱歉，忘记回复了。fr记录了每个zone的start_x, start_y, height, width这个四元组。然后根据标定的外参将ToF的zone投回（warp）RGB视野内的时候，有些patch会一部分在视野外，一部分在视野内。patch size是原始的patch大小，然后pad size就是超出视野的这部分大小。为了将这些塞到一个batch进行处理（transformer），我们是先对RGB这个分辨率做了pad，这样超出视野的部分就进来了，然后做完了transformer fusion再根据pad size把之前这部分裁掉。