-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
odm_georef fails with large point clouds (exit code 139, seg fault) #909
Comments
Considering the possible link to Issue #730 , the GPS info in EXIF looks fine:
|
Looks like this issue: http://community.opendronemap.org/t/exception-child-returned-139-when-running-georeferencing-with-opensfm-transformation-matrix/1319/3 Are you using the docker images? |
@pierotofy yes, I'm using Docker. |
If you re-process the dataset using |
@pierotofy , your current guess looks right:
|
👍 do you know how many points the 7.8GB PLY had? I'm just trying to narrow down the problem and possibly study a fix for it. |
The |
Possibly related: PointCloudLibrary/pcl#2145 |
@thsant would you be able to share (even privately) these files:
and every file in You can use Dropbox or Google Drive. |
Sure, @pierotofy The files are available at Dropbox This is PLY file header :
|
Possibly another dataset to test this problem: http://community.opendronemap.org/t/failure-on-georeferencing-with-larger-dataset/1464 |
Well, today I just re-confirmed this with a 1066 images dataset.
|
It'll still need a fix regardless, as it will break at some higher number, but I wonder if using mve instead of smvs would help (can be tested here or at the pull request @thsant)? |
Is a Docker image there for the mve branch or should I do a local build? |
@smathermather yeah MVE will produce less points, but it's an error that could still happen. I'm thinking that we should have a |
Yes @pierotofy -- just hoping it fixes @thsant's problem in the meantime. I'd prefer we fix the problem, either by upstream patch or elimination of the library from odm_georef rather than adding a flag. An alternative would be to multi-thread the georeferencing, which would require breaking the point cloud into parts. |
@thsant -- that's either a local build or you can build your own docker image from the branch: https://github.com/smathermather/OpenDroneMap/blob/mvs_and_smvs/README.md#build-and-run-using-docker |
@pierotofy -- we could of course just subsample our point cloud as you say with the |
I was thinking of a more naive approach such as https://pdal.io/stages/filters.decimation.html, but as you say, it would be best to allow odm_georef to handle larger inputs. |
The challenge with decimation is feature retention: https://pdal.io/tutorial/sampling/index.html, which could have a real effect on retaining ground points. With lidar, it tends to emphasize ground points as there are more of them. With photogrammetrically derived point clouds, the effect will be the opposite, reducing the quality of the DTM. |
Mm, yes that could be a problem. My concern is that after odm_georef is fixed, we might still encounter other issues in other parts of the pipeline (DSM calculation for example). Placing a ceiling could give users the option to sacrifice some quality for getting at least some output. I'll still go ahead and attempt to fix odm_georef first, keeping this option as a plan-B. |
This is still a problem. The comment from |
And the actual fix: OpenDroneMap/pcl#1 |
That was quick. 😺 |
This is now fixed for good. |
Nice. Fixed upstream and merged I see. 👍 |
How can I reflect these changes from OpenDroneMap/pcl to OpenDroneMap/ODM ? |
You don't need to upgrade PCL, the final fix ended up using PDAL to write the point cloud properly. Just make sure you update ODM to the latest version. |
I have gotten a Segmentation fault during
odm_georef
execution:[DEBUG] running /code/build/bin/odm_georef -bundleFile /datasets/code/opensfm/bundle_r000.out -inputTransformFile /datasets/code/opensfm/geocoords_transformation.txt -inputCoordFile /datasets/code/odm_georeferencing/coords.txt -inputFile /datasets/code/odm_texturing/odm_textured_model.obj -outputFile /datasets/code/odm_texturing/odm_textured_model_geo.obj -inputPointCloudFile /datasets/code/smvs/smvs_dense_point_cloud.ply -outputPointCloudFile /datasets/code/odm_georeferencing/odm_georeferenced_model.ply -logFile /datasets/code/odm_georeferencing/odm_georeferencing_log.txt -outputTransformFile /datasets/code/odm_georeferencing/odm_georeferencing_transform.txt -georefFileOutputPath /datasets/code/odm_georeferencing/odm_georeferencing_model_geo.txt
According to the output, the child process returned a 139 code (128 + 11 = 139, 11 is the code for a segmentation fault,
SIGSEV
):I have checked the input files:
All of them look fine, but the
smvs_dense_point_cloud.ply
is an amazing PLY presenting 7.8 Gb. The machine running the Docker application is exclusively used for ODM and it has 252 Gb RAM. The header of this PLY looks fine:The dataset is composed by 703 images (6000 x 4000 pixels) captured by a Sony ILCE-6000. The georeferenced textured mesh
odm_textured_model_geo.obj
was successfully built and I'm able to inspect it in Meshlab. ODM was started using:docker run -ti --rm -v /home/odm/laurimar:/datasets/code opendronemap/opendronemap --project-path /datasets --dsm --dtm --build-overviews
Any tip of advice?
UPDATE: Using ODM 0.4.0 here
The text was updated successfully, but these errors were encountered: