Dear ODM-Team,
I’ve got a problem with WebODM which I’ve been using successfully for a while:
I captured a bunch of aerial (~390) photos using my drone (DJI P4P) and the Pix4D capturing app and since the capturing mission was aborted I also hit the trigger manually a couple of times to cover the remaining area.
Before uploading the photos I also cleaned, upgraded and rebuilt WebODM by running
./webodm.sh down
./webodm.sh update
./webodm rebuild
After that I uploaded my photos (just the photos, no GCP file), set ‘Options’ to ‘High Quality’ and started processing, which took roughly 8.5 hours. (I ran into troubles with my limited disk space a couple of times, thus I had to start over a couple of times after freeing up disk space, where I also deleted the project and set it up afresh). So nothing spectacular till here, everything just as usual.
When first inspecting the resulting 3D Model, I found that the whole model was turned up by 90°. The rotation constraints also prevented me from viewing it from the other side (north instead of south) after rotating it into the normal position. The orthophoto and the DEM seems to be rendered from the side instead of from the birds eye view. Attached are some screen shots of the problem. What could be the reason for the axes to be obviously mistaken for each other? Is it in my image data or could there be a bug in ODM?
I never had this kind of issue before.
Thanks a million and best regards!
Thomas
Were the photos georeferenced by the pix4d app? You can check the exif data for GPS Latitude and Longitude coordinates. You may want to throw them into QGIS using the Photo2Shape plugin (it’s a little annoying to set up if you have Windows, unfortunately) to check their valid positions.
Hey, thanks for your timely response.
Well, I used pix4d to generate a coverage path and to have my drone fly that path and take the photos (as in the past, where everything worked just fine). However I have little clue as to which degree that app actually influences the EXIF header of the image files (I would expect, it doesn’t at all).
I used jhead on the command line (I use Linux exclusively) to extract some headers:
-
Photo taken by Pix4D (from project with the problem)
File name : DJI_0005.JPG
File size : 8434466 bytes
File date : 2017:10:31 15:23:25
Camera make : DJI
Camera model : FC6310
Date/Time : 2017:10:31 15:23:23
Resolution : 5472 x 3648
Flash used : No
Focal length : 8.8mm (35mm equivalent: 24mm)
Exposure time: 0.017 s (1/60)
Aperture : f/3.5
ISO equiv. : 100
Whitebalance : Auto
Metering Mode: center weight
Exposure : program (auto)
GPS Latitude : N 49d 50m 16.5088s
GPS Longitude: E 11d 10m 23.6923s
GPS Altitude : 414.84m
JPEG Quality : 92
Comment :
-
Photo taken manually (also from project with the problem)
File name : DJI_0392.JPG
File size : 8633150 bytes
File date : 2017:10:31 15:52:34
Camera make : DJI
Camera model : FC6310
Date/Time : 2017:10:31 15:52:33
Resolution : 5472 x 3648
Flash used : No
Focal length : 8.8mm (35mm equivalent: 24mm)
Exposure time: 0.017 s (1/60)
Aperture : f/3.5
ISO equiv. : 100
Whitebalance : Auto
Metering Mode: center weight
Exposure : program (auto)
GPS Latitude : N 49d 50m 24.2060s
GPS Longitude: E 11d 10m 31.2282s
GPS Altitude : 416.41m
JPEG Quality : 90
Comment
-
Photo taken by Pix4D in an earlier mission (processing result was fine back then)
File name : DJI_0007.JPG
File size : 8205311 bytes
File date : 2017:10:31 17:00:36 (this one is from a backup copy)
Camera make : DJI
Camera model : FC6310
Date/Time : 2017:06:21 15:30:35
Resolution : 5472 x 3648
Flash used : No
Focal length : 8.8mm (35mm equivalent: 24mm)
Exposure time: 0.0042 s (1/240)
Aperture : f/5.0
ISO equiv. : 100
Whitebalance : Auto
Metering Mode: center weight
Exposure : program (auto)
GPS Latitude : N 49d 50m 18.0742s
GPS Longitude: E 11d 10m 26.0705s
GPS Altitude : 472.90m
JPEG Quality : 89
Comment :
The captured positions in the EXIF headers are perfectly valid in all cases. I can’t really see a difference except for the altitude. So what else could have caused the problem? May this be due to me setting the “High Quality” option?
Thank you very much!
Hey @freggala this might be a bug, is there any chance you could share your dataset (or a subset of it) with us via Dropbox or Google Drive?
Of course I can!
For anyone, who’s interested please send me a private message…
1 Like
Sorry, I haven’t had time to check the dataset yet. But I did just encounter another dataset that is having the same exact issue, so will definitely look into it in the next few days and report back my findings.
That would be great, as I’m having a lot of stuff to process through ODM.
Again, thank you very much!
I’m just sending a “ping” to keep my topic alive… 
I think this problem is caused by the georeferencing module (odm_georef) and the way it’s choosing the ideal camera triplet (the three points used to create the transformation matrix).
I’ll need to investigate further. I’ll post my results as I go, but this definitely looks like a bug. Could you open an issue on GitHub (under the OpenDroneMap repository) just so that we can track it there as well?
Perhaps this is due to the elevation values matching exactly between two of the points, messing up the algebra?
Dump of camera parameters:
CAM 275 :Focal, k1, k2 : 0, 0, 0
Transform :
0 0 0 -0
0 0 0 -0
0 0 0 -0
0 0 0 1
Position :
-0
-0
-0
east, north, alt : -83.3877, -11.5209, 414.841
CAM 300 :Focal, k1, k2 : 3639.93, -0.0272879, 0.00166352
Transform :
-0.463699 -0.880834 -0.0954705 52.2606
0.885155 -0.465248 -0.00669667 90.0013
-0.0385188 -0.0876114 0.99541 415.188
0 0 0 1
Position :
52.2606
90.0013
415.188
east, north, alt : 49.9686, 91.2729, 415.007
CAM 322 :Focal, k1, k2 : 3639.93, -0.0272879, 0.00166352
Transform :
-0.516251 -0.856429 -0.00366882 25.4178
0.856317 -0.516246 0.0145298 0.362614
-0.0143378 0.00435936 0.999888 411.715
0 0 0 1
Position :
25.4178
0.362614
411.715
east, north, alt : 25.3478, 2.63363, 414.941
Camera 275 is definitely out of whack. Will need to find the cause.
For certain datasets (like this one), multiple bundler files are outputted by opensfm, but odm_georef can only read one at a time. Certain cameras are not present in all bundler files, and that’s why they are initialized to 0.
0.858829421923 -0.512261433198 0.000498093946643
-0.0239881593247 -0.0392459180751 0.998941602961
77.5755197624 -7.48266386262 -408.272761146
0 0 0
0 0 0
0 0 0
0 0 0
0 0 0
3639.93456293 -0.0272879125329 0.00166352063633
0.429104064047 0.902487395567 0.0372317480191
-0.902949286432 0.427521789944 0.0436772853469
/datasets/brunn/opensfm/bundle_r000.out /datasets/brunn/opensfm/bundle_r012.out
/datasets/brunn/opensfm/bundle_r001.out /datasets/brunn/opensfm/bundle_r013.out
/datasets/brunn/opensfm/bundle_r002.out /datasets/brunn/opensfm/bundle_r014.out
/datasets/brunn/opensfm/bundle_r003.out /datasets/brunn/opensfm/bundle_r015.out
/datasets/brunn/opensfm/bundle_r004.out /datasets/brunn/opensfm/bundle_r016.out
/datasets/brunn/opensfm/bundle_r005.out /datasets/brunn/opensfm/bundle_r017.out
/datasets/brunn/opensfm/bundle_r006.out /datasets/brunn/opensfm/bundle_r018.out
/datasets/brunn/opensfm/bundle_r007.out /datasets/brunn/opensfm/bundle_r019.out
/datasets/brunn/opensfm/bundle_r008.out /datasets/brunn/opensfm/bundle_r020.out
/datasets/brunn/opensfm/bundle_r009.out /datasets/brunn/opensfm/bundle_r021.out
/datasets/brunn/opensfm/bundle_r010.out /datasets/brunn/opensfm/bundle_r022.out
/datasets/brunn/opensfm/bundle_r011.out
Thank you so much for investigating the issue! I was very busy the last couple of days, so I couldn’t follow the topic and respond to it.
