The shape mismatch for lidar_ground segmentation array and points

[mu-cai]

Hi Junbo,

Thanks for your great work! When I run the pertaining for waymo, I found the shape mismatch for lidar_ground segmentation array and points. The largest value in lidar_ground is even larger than the length of the points... I wonder how can this happen? Thanks, Mu

[yinjunbo]

Hi Mu,

This didn't happen in my previous experiments. Can you report the token of this frame, so I can check the problem.

Best

Mu Cai @.***> 于2022年10月10日周一 10:36写道：

Hi Junbo,

Thanks for your great work! When I run the pertaining for waymo, I found the shape mismatch for lidar_ground segmentation array and points. The largest value in lidar_ground is even larger than the length of the points... I wonder how can this happen? Thanks, Mu [image: image] https://user-images.githubusercontent.com/65588556/194792073-904c6ba4-3070-40af-9154-72c8ad062754.png

— Reply to this email directly, view it on GitHub https://github.com/yinjunbo/ProposalContrast/issues/6, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHCPIYN75RDVEGVPUFJU3JDWCN6KNANCNFSM6AAAAAARA6QVFE . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[mu-cai]

Thank you Junbo for your quick reply! Actually, meany examples, occur this error. For example, under seq_305_frame_0, When we print len(ground_mask) and max(ground_point_idx)), we get

What do you get in this case? Thanks!

[yinjunbo]

Hi, I've checked seq_305_frame_0, and it turns out that the points length is reasonable. You can load the original waymo points of seq_305_frame_0 and check if the points length is also 169486.

a=pickle.load(open('../lidar/seq_305_frame_0.pkl', 'rb')) a['lidars']['points_xyz'].shape (169486, 3) b=np.load('seq_305_frame_0.npy') b.max() 169485

Besides, our ground_mask is initialized by the length of points. So if the points length is right, the ground_mask should also be right.

Mu Cai @.***> 于2022年10月10日周一 13:21写道：

Thank you Junbo for your quick reply! Actually, meany examples, occur this error. For example, under seq_305_frame_0, When we print len(ground_mask) and max(ground_point_idx)), we get [image: image] https://user-images.githubusercontent.com/65588556/194803016-e330096a-28c6-4d99-b550-45f960ea88db.png What do you get in this case? Thanks!

— Reply to this email directly, view it on GitHub https://github.com/yinjunbo/ProposalContrast/issues/6#issuecomment-1272800211, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHCPIYNEYESMHEO4H4VSSJLWCORUBANCNFSM6AAAAAARA6QVFE . You are receiving this because you commented.Message ID: @.***>

[mu-cai]

Hi Junbo,

I think the problem is here: for fnames = list(glob.glob(args.tfrecord_path)), there is no strict ordering for the file. Thus, the correspondence between fnames and idx is not correctly matched for our two machine file systems. Therefore, can you give me your output of fnames (a list with the length 798)? Thus I can match the ground_point_idx with your indexing of scenes?

Best, Mu

[yinjunbo]

Hi Mu,

It seems that you have a multi-machine setting. Since I only got a single machine, I currently cannot address your problem due to the limited bandwidth. In my single-machine setting, the lidar_ground and lidar should follow a strict name correspondence. (As stated in README, 'Please unzip the file and place it at ~/data/Waymo/train/lidar_ground'.) Further, you can also generate your own lidar_ground by following the examples at https://pypi.org/project/pyransac3d/ https://pypi.org/project/pyransac3d/. I think this would be pretty easy for researchers in this field.

Best, Junbo

Mu Cai @.***> 于2022年10月10日周一 23:52写道：

Hi Junbo,

I think the problem is here: for fnames = list(glob.glob(args.tfrecord_path)), there is no strict ordering for the file. Thus, the correspondence between fnames and idx is not correctly matched for our two machine file systems. Therefore, can you give me your output of fnames (a list with the length 798)? Thus I can match the ground_point_idx with your indexing of scenes?

Best, Mu

— Reply to this email directly, view it on GitHub https://github.com/yinjunbo/ProposalContrast/issues/6#issuecomment-1273517027, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHCPIYI643KMYO4YPBD7WODWCQ3S5ANCNFSM6AAAAAARA6QVFE . You are receiving this because you commented.Message ID: @.***>

[mu-cai]

Hi Junbo:

Thanks for your reply!: (1) Can you tell me your hyper-parameters in ransac3d? Just the default one? (2) I am using single machine. The problem occurs because fnames = list(glob.glob(args.tfrecord_path)) will give you different results given different download order. For example, your fnames may be [a.tfrecord, b.tfrecord,c.tfrecord,], while mine could be [a.tfrecord, c.tfrecord,b.tfrecord,], which causes a mismatch for my lidar and your lidar_ground. Therefore, I need your fnames .

Best, Mu

[yinjunbo]

Hi Mu,

(1) We empirically set the hyper-parameter (i.e., distance above the plane) as 0.1. You can also try other values. (2) Our file names of lidar_ground strictly follow the corresponding lidar file names, as I introduced before. You can follow this to change your own lidar ground name.

Best, Junbo

Mu Cai @.***> 于2022年10月11日周二 22:35写道：

Hi Junbo:

Thanks for your reply!: (1) Can you tell me your hyper-parameters in ransac3d? Just the default one? (2) I am using single machine. The problem occurs because fnames = list(glob.glob(args.tfrecord_path)) will give you different results given different download order. For example, your fnames may be [a.tfrecord, b.tfrecord,c.tfrecord,], while mine could be [a.tfrecord, c.tfrecord,b.tfrecord,], which causes a mismatch for my lidar and your lidar_ground. Therefore, I need your fnames .

Best, Mu

— Reply to this email directly, view it on GitHub https://github.com/yinjunbo/ProposalContrast/issues/6#issuecomment-1274798412, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHCPIYL3S4HLIX6DUYVF27LWCV3MTANCNFSM6AAAAAARA6QVFE . You are receiving this because you commented.Message ID: @.***>

[Hiusam]

I encounter this error as well. According to https://stackoverflow.com/questions/6773584/how-are-glob-globs-return-values-ordered, the order of fnames = list(glob.glob(args.tfrecord_path)) is actually arbitrary, so it would be better to set the order by sorted(fnames). So we need to generate the lidar_ground by ourselves.