Question on dense point cloud density

[dllu]

Regarding the dense point cloud produced by DensifyPointCloud, it seems that the density is highly varying. In particular, it is dependent on the camera views that observe the point --- if a point is only seen by cameras far away, the neighbourhood around that point will be sparse. Therefore each point should have a "size" or "density" parameter associated with it.

Is there a way to get this for each point in the dense point cloud?

[cdcseacave]

There is now :)
I've added support for exporting the point cloud with scale information in 4efd9b4

[dllu]

Thanks @cdcseacave for the incredibly fast implementation!!!

However I spot some issues...

32 bit overflow?

There seems to be some int32 limitations.

$ ls -alt asdf_dense_dense_scale.ply
-rw-rw-r-- 1 dllu dllu 2147610624 Jun 16 17:14 asdf_dense_dense_scale.ply
$ ls -alt asdf_dense.ply
-rw-rw-r-- 1 dllu dllu 2551807427 Jun 15 21:47 asdf_dense.ply

As you can see, compared to the original asdf_dense.ply, the asdf_dense_dense_scale.ply is truncated to just slightly more than 2^31 bytes.

For your information, here are the logs from a run that produced a file with 2147610624 bytes:

18:25:20 [App     ] Build date: Jun 16 2023, 13:15:33
18:25:20 [App     ] CPU: Intel(R) Xeon(R) Platinum 8268 CPU @ 2.90GHz (96 cores)
18:25:20 [App     ] RAM: 754.57GB Physical Memory 0B Virtual Memory
18:25:20 [App     ] OS: Linux 5.4.0-42-generic (x86_64)
18:25:20 [App     ] Disk: 268.29TB (1091.39TB) space
18:25:20 [App     ] SSE & AVX compatible CPU & OS detected
18:25:20 [App     ] Command line: DensifyPointCloud -i asdf_dense.mvs --cuda-device -1 --max-threads 12 --estimate-scale 1 --ignore-mask-label 0 --sub-resolution-levels 3 --iters 6
18:25:20 [App     ] CUDA device 0 initialized: Tesla V100-SXM2-32GB (compute capability 7.0; memory 31.75GB)
18:26:28 [App     ] Scene loaded (1m8s235ms):
	23940 images (23940 calibrated) with a total of 7752.39 MPixels (0.32 MPixels/image)
	92398249 points, 0 vertices, 0 faces
18:26:28 [App     ] Found a camera not pointing towards the scene center; the scene will be considered unbounded (no ROI)
18:26:55 [App     ] Point-cloud saved: 92398249 points with scale (27s251ms)
18:26:57 [App     ] MEMORYINFO: {
18:26:57 [App     ] 	VmPeak:	22891488 kB
18:26:57 [App     ] 	VmSize:	16831200 kB
18:26:57 [App     ] } ENDINFO

negative scales

In my example, about 52 out of 118k points have negative scale.

ipdb> np.min(scale)
-12.061018
ipdb> np.max(scale)
35043.88
ipdb> scale
array([0.0155141 , 0.029369  , 0.01407094, ..., 0.03304439, 0.02280951,
       0.02370404], dtype=float32)
ipdb> sum(scale < 0)
52
ipdb> sum(scale > 0.1)
4327
ipdb> sum((scale >= 0) & (scale <= 0.1))
113569

I see that there is an assertion for scale > 0 but I guess it didn't trigger in release mode. (On the other hand, this shouldn't happen to begin with and the code would have crashed if it were to trigger).

asdf_dense_dense_scale.ply

It seems that running DensifyPointCloud with --estimate-scale 1 simply estimates scale without densifying the point cloud. So if I run it on asdf.mvs, it will output asdf_dense_scale.mvs but it is actually the sparse point cloud. I need to run it on asdf_dense.mvs (generated by running DensifyPointCloud without --estimate-scale, but then the output will be asdf_dense_dense_scale.ply. This seems slightly unintuitive.

[cdcseacave]

if there is a int32 limit to number of points that is probably due to PLY format; however I suggest to not even work with such big scenes, but instead break it down in multiple smaller sub-scenes

is the scale is negative, that is only because the 3D point projects behind the camera; helps is welcome in finding why that is happening

the interface will never make everybody happy; the idea here is to run this step as a postprocess if needed on the dense point cloud; you can control the name of the output file using -o name

[dllu]

No, I don't think it is due to the PLY format. It's the number of bytes that's overflowing, not the number of points. Previously, OpenMVS was able to output PLY files with more than 2^31 bytes easily. In fact, if you look at the log I posted above, the asdf_dense.ply produced without --estimate-scale is more than 2^31 bytes. But with estimate scale, it stops when it goes over 2^31 bytes (but is in fact still slightly over).

This affects four of the files shown below (8YYEH6, 9HWDP5, 8VZ96Q, 8YYQP3)...

data $ ls -alt */asdf_dense.ply
-rw-rw-r-- 1 dllu dllu 4379289198 Jun 15 22:55 8YYEH6/asdf_dense.ply
-rw-rw-r-- 1 dllu dllu 2551807427 Jun 15 21:47 9HWDP5/asdf_dense.ply
-rw-rw-r-- 1 dllu dllu 2494752971 Jun 15 21:34 8VZ96Q/asdf_dense.ply
-rw-rw-r-- 1 dllu dllu 2043427991 Jun 15 21:25 8YYQP3/asdf_dense.ply
-rw-rw-r-- 1 dllu dllu 1163838623 Jun 15 21:05 8YYZBZ/asdf_dense.ply
-rw-rw-r-- 1 dllu dllu 1127055038 Jun 15 20:48 9K6KV4/asdf_dense.ply
-rw-rw-r-- 1 dllu dllu  444842555 Jun 15 20:47 8YV8SM/asdf_dense.ply
-rw-rw-r-- 1 dllu dllu  545544914 Jun 15 20:38 8YYZB1/asdf_dense.ply
data $ ls -alt */asdf_dense_dense_scale.ply
-rw-r--r-- 1 dllu dllu 2147610624 Jun 16 18:26 8VZ96Q/asdf_dense_dense_scale.ply
-rw-r--r-- 1 dllu dllu 1508679674 Jun 16 17:20 8YYZBZ/asdf_dense_dense_scale.ply
-rw-r--r-- 1 dllu dllu  707187829 Jun 16 17:20 8YYZB1/asdf_dense_dense_scale.ply
-rw-r--r-- 1 dllu dllu 2147610624 Jun 16 17:19 8YYQP3/asdf_dense_dense_scale.ply
-rw-r--r-- 1 dllu dllu 2147610624 Jun 16 17:17 8YYEH6/asdf_dense_dense_scale.ply
-rw-r--r-- 1 dllu dllu 2147610624 Jun 16 17:14 9HWDP5/asdf_dense_dense_scale.ply
-rw-r--r-- 1 dllu dllu  576647734 Jun 16 17:13 8YV8SM/asdf_dense_dense_scale.ply
-rw-r--r-- 1 dllu dllu 1460997249 Jun 16 17:12 9K6KV4/asdf_dense_dense_scale.ply

This is definitely a recent regression. There is likely some code with an int32 counter for the number of bytes that overflows somewhere.

[dllu]

Actually, I found the bug. It's an old bug from 2015. With the fix, it works properly now.

The reason why the prevous asdf_dense.ply was unaffected is because PointCloud::Save does not use buffered writing whereas PointCloud::SaveNViews and PointCloud::SaveWithScale do use buffered writing, and the bug only affects BufferedOutputStream.

#1010