Simple workflow question - build geometry?

[airmap3d]

Hello all,

This is probably a simple question to many of you, but I am new(ish) to Photoscan and just need some clarification...

I process aerial photography from over mine sites, quarries etc and after the align photos stage (plus adding GCP's and optimization) I have my 3D point cloud.  I can export this point cloud (sparse) and then tidy it up in other software packages and the results seem to be very good.  I am only really needing a 3D model and orthophoto and both of these I can export after the align photo stage.

Q. What extra benefit do I get from the build geometry step?  Does this step tighten up the accuracy's or is it actually for another purpose?  I am having trouble getting my head around this part of the software.  Due to it being a time consuming process, if I don't really need it I'd rather not do it!

Your replies will be appreciated.

Thanks.
Matt

[RalfH]

The "build geometry" step will create a dense point cloud at user-specified settings and will then create a meshed model from the dense point cloud. The sparse point cloud really is just an intermediate step on the way to a dense point cloud.

[airmap3d]

Thanks for the reply.

The sparse points clouds I am getting are in the millions of points and I don't really need any more than this, as I normally decimate that figure down to the hundreds of thousands anyway.  Otherwise the output file sizes are too large for most of my clients to handle.

Does "build geometry" improve the accuracy of the original point cloud points or does it just add more points/facets?  Bearing in mind that I am processing up to 1 square km per project and don't need every stone and bump modeled.  The point spacing of my final outputs, once I've post processed it, is around 1/2m so is it worth me doing this extra step?

Thanks.

[RalfH]

As far as I know, the sparse point cloud consists only of the matching points that were used for bundle adjustment to align the cameras. For the dense point cloud, additional points are computed by first creating depth (distance) maps for all cameras and then finding corresponding points (based on distance and camera orientation). No changes are made to the original bundle adjustment. If the sparse point cloud is dense enough for your purposes, it may be feasible to use it as the final product. Depending on the surface you're covering, working with dense point clouds and then filtering it to reduce the number of vertices may give better results (I have had quite good results performing vegetation filtering of very sparse plant cover). 

[airmap3d]

Thanks for that.  I suppose I could just perform some tests of my own to be certain.  But I guess if I can check my results against independent data and the results are satisfactory then what more do I need?

 

[JMR]

Does "build geometry" improve the accuracy of the original point cloud points or does it just add more points/facets?
Thanks.

Yes. As far as the sparse cloud is built on matched "feature points", it does not have nothing to do with the actual terrain topography but just with some points identified as features because of their appearance in the photos (vicinity contrast or whatever that made them distinctly identifiable for some detection algorithm). You should understand this is just a 2D step
This nature makes them well-suited to provide optimal correlation values and thus are great for inner and outer camera orientation parameters estimation.
If you build geometry you should get a better terrain description even after a strong decimation (now the third dimension matters) to a number of points below the population of the initial sparse cloud.

I wouldn't expect to infer good breaklines from the sparse point cloud but on the contrary you would see them neatly rendered after dense model decimation.

Regards!

[RalfH]

JMR,

this is not correct. The actual bundle adjustment (which computes camera calibration and orientation parameters and creates the sparse point cloud) happens during camera alignment. The sparse point cloud contains true 3D points. Nothing 2D here.

You have a good point about terrain break lines though - they can be much better resolved in a decimated dense point cloud than in a sparse point cloud.

[JMR]

this is not correct. The actual bundle adjustment (which computes camera calibration and orientation parameters and creates the sparse point cloud) happens during camera alignment. The sparse point cloud contains true 3D points. Nothing 2D here.

Let me respectfully insist in that it is correct from my point of view.
Feature points are detected in every single image (2D) before orientation, and are paired by comparison of clusters of pixels (2D to 2D).
lots of statistically-approved couples (x,y) & (x',y') enter in equations that yield solutions to unknowns:  lens parameters and also center and attitude of cameras and at the same time x,y,z for the feature points are calculated (so, no role is played by the third dimension until now). So the result is 3D but features are two dimensional as they are just singularities in the appearance of a certain groups of pixels not necessarily linked to actual shape-features but to photo-features.

[RalfH]

JMR,

yes, oft course the image feature points which are used for image alignment are subsets of the 2D images, but the sparse point cloud contains the modelled 3D positions of these points.

[airmap3d]

Hi guys,

I wont be commenting on your conversation as it is well beyond my level of expertise but I do have more information based around my original question...

For a particular data set I am testing with at the moment when I export the sparse point cloud in xyz, straight after aligning photos, the output file size is around 200mb and contains about 4.5 million points, large but within reason.  After running build geometry and exporting the dense point cloud (also xyz) the file size was around 40gb, no idea how many points this must contain!  40gb is no use to anybody as I don't know of any programs that would handle a file of that size.  I built the geometry with a limit of 2 million faces as I thought this would produce a smaller (more realistic) output file size.  Hopefully you can understand where I am coming from.  If build geometry doesn't improve the accuracy of the individual sparse point cloud points then I don't see the need to complete the build geometry stage??  As the sparse point cloud, one post-processed through other software packages, seems to be delivering satisfactory results.

I am using a UAV (MAVinci) to perform aerial mapping over areas up to 70ha with a GSD of ~2.3cm, approximately 1000+ images, 75% overlap and 10 GCP's with accuracy's known to around the 30mm mark (RTK GPS).  I am requiring the finished product to be good for around the +-150mm and that is what I seem to be getting with the sparse point cloud.  I am mapping mining areas in Australia so don't need every bump and lump to be modeled, I just need a reasonably accurate model of a large area for volume calculation purposes etc.

Am I missing something here completely or is what I have determined correct?

Thanks!!

[RalfH]

Hello airmap3d,

build geometry doesn't change the sparse point cloud. For what you describe, using the sparse point cloud sounds like a reasonable solution. If you have that many photos, you usually end up with a quite large sparse point cloud and may not need to make it denser. 4.5 million points per 70 ha equals 6.4 points per square metre - if that's enough for you, the remaining issue that you should consider is that these points are very likely not distributed evenly over your area but are concentrated in parts with good texture while parts with poor texture may not have any points for many square metres. This is where creating a dense point cloud would improve your results.

As for very large files, I sometimes work with point cloud files of 30 GB or more, but I am using my own code to process these files. It's simple number crunching - read point after point, assign grid cell, use max./min. elevation (for DSM/DEM) or mean (in case fo no vegetation) of points in that grid cell, do that for all points in the point cloud and finally save the grid file. Some patience is necessary (several hours for 30 GB).

[airmap3d]

RalfH,

Thank you for the response.  I believe you have answered my question.  I will continue to do various testing but for now, if I am running independent checks on the results and they are falling within my tolerances then I guess I should be satisfied with the results.

Cheers!

[Shadee]

Im highjacking this thread for my own question, hope its ok  .

Is there any way to see how many points the dense point cloud contains? Without the use of "export point cloud" and importing it to another GIS-program.  Is it possible to calculate backwards from the proccessing report using points per sq m for the DEM and the coverage area?

In my case that would be 0,87 sq km and 11,4 points per sq m = aprox 9.9 million points in the dense point cloud. Does that sound right? In my other project it is 52 points per sq m and 0.246 sq km = aprox 12 million points in the dense point cloud.