Forum

Author Topic: Estimating camera locations slow (1.2 pair/s) and using one core (1.6.5, Win10)  (Read 1271 times)

andyroo

  • Sr. Member
  • ****
  • Posts: 438
    • View Profile
Is the estimating camera locations step supposed to be limited to a single core?

During this prolonged period of single core usage, my log is recording "pair XXXXX and YYYYY: 0 robust from ZZZZZ" and only processing an average of about 1.2 pairs/second.

Screenshot of processing and Task Manager attached.

I'm running a project with ~16,000 cameras, 2500 with precise positions and the rest with no positions, gradual and reference preselection enabled, six separate camera models (all default). RAM is only about half-used, workstation is an AMD Threadripper 3960x with 256GB RAM and 2 RTX 2080 Super GPUs. 

Most recent bits of log for this step and the end of the previous step is below:

Code: [Select]
...
2020-11-22 10:08:47 Found 2 GPUs in 0 sec (CUDA: 0 sec, OpenCL: 0 sec)
2020-11-22 10:08:47 Using device: GeForce RTX 2080 SUPER, 48 compute units, free memory: 7081/8192 MB, compute capability 7.5
2020-11-22 10:08:47   driver/runtime CUDA: 11010/8000
2020-11-22 10:08:47   max work group size 1024
2020-11-22 10:08:47   max work item sizes [1024, 1024, 64]
2020-11-22 10:08:47 Using device: GeForce RTX 2080 SUPER, 48 compute units, free memory: 7129/8192 MB, compute capability 7.5
2020-11-22 10:08:47   driver/runtime CUDA: 11010/8000
2020-11-22 10:08:47   max work group size 1024
2020-11-22 10:08:47   max work item sizes [1024, 1024, 64]
2020-11-22 10:11:20 9888655 matches found in 152.423 sec
2020-11-22 10:11:20 matches combined in 0.879 sec
2020-11-22 10:11:22 filtered 130916 out of 5044254 matches (2.59535%) in 1.428 sec
2020-11-22 10:11:22 saved matches in 0.06 sec
2020-11-22 10:11:23 loaded matching data in 0.001 sec
2020-11-22 10:11:23 loaded matching partition in 0.004 sec
2020-11-22 10:11:23 loaded keypoint partition in 0.001 sec
2020-11-22 10:11:24 loaded matches in 1.318 sec
2020-11-22 10:11:24 setting point indices... 46118303 done in 10.224 sec
2020-11-22 10:14:40 generated 46118303 tie points, 3.50232 average projections
2020-11-22 10:14:52 removed 482049 multiple indices
2020-11-22 10:14:52 removed 21268 tracks
2020-11-22 10:15:29 loaded keypoint partition in 0 sec
2020-11-22 10:15:29 loaded matching partition in 0.005 sec
2020-11-22 10:15:29 loaded matching partition in 0.719 sec
2020-11-22 10:15:30 Estimating camera locations...
2020-11-22 10:15:30 processing matches... done in 132.972 sec
2020-11-22 10:17:43 selecting camera groups... done in 3.817 sec
2020-11-22 10:17:47 scheduled 588 alignment groups
2020-11-22 10:17:47 saved camera partition in 0.013 sec
2020-11-22 10:17:47 loaded camera partition in 0.001 sec
2020-11-22 10:17:49 processing block: 250 photos
2020-11-22 10:17:53 pair 13255 and 13259: 0 robust from 38522
2020-11-22 10:17:54 pair 13242 and 13245: 0 robust from 38499
2020-11-22 10:17:55 pair 13320 and 13334: 0 robust from 38247
...
2020-11-22 12:44:39 pair 13354 and 13385: 0 robust from 30544
2020-11-22 12:44:40 pair 13315 and 13453: 0 robust from 30544
2020-11-22 12:44:40 pair 13312 and 13384: 0 robust from 30544
2020-11-22 12:44:40 pair 13297 and 13427: 0 robust from 30544
2020-11-22 12:44:41 pair 13374 and 13455: 0 robust from 30543
...


Alexey Pasumansky

  • Agisoft Technical Support
  • Hero Member
  • *****
  • Posts: 14813
    • View Profile
Hello andyroo,

Can you please describe the type of the survey used in this project? Was it a regular nadir aerial survey or a close range shooting, and if there are a lot of positions where from multiple images have been taken?
Best regards,
Alexey Pasumansky,
Agisoft LLC

andyroo

  • Sr. Member
  • ****
  • Posts: 438
    • View Profile
It was nadir and oblique aerial imagery with multiple passes and multiple cameras from an altitude of about 600 to 900 meters.  The oblique imagery has precise positions and the nadir imagery has no positions.

Interestingly, the oblique imagery failed to align on the initial alignment, and the nadir imagery aligned. I have succeeded aligning both orientations in past surveys after inserting ground control to establish estimated positions for the nadir imagery before aligning the oblique imagery, but I hadn't tried to simultaneously align all of the images before.

[edit - additional detail and update] The imagery is a long coastal section with inlets - so areas of good reconstruction broken by no reconstruction. Normally this doesn't create a problem with oblique/precise-positioned imagery, but it may complicate reconstruction when being done simultaneously with unreferenced imagery. Normally with the unreferenced imagery I break it into discrete segments bounded by inlets.

I am proceeding by reconstructing separate chunks with the referenced imagery and each discrete segment of the unreferenced imagery. At this point I am not seeing the single-core slow behavior and the (4) different chunks are reconstructing in 1-2h.
« Last Edit: November 24, 2020, 10:23:10 PM by andyroo »