Dear all,
Last week we mapped two water barrier structures at two seperate locations as a pilot project for one of our clients, this week was all about processing of the images we captured. Normally, given the small area of each site (only 2.5 and 5 hectares respectively) this shouldn't take longer than half a day of work. Unfortunately, however, we are facing serious troubles throughout the process starting with image alignment, let alone with respect to distilling of the desired products. In the past days we have been running an endless number of processing runs, each time minorly tweaking some parameters, for well over 90 hours continously ánd simultaneously.
Without any success, however. We have seen everything so far ranging from Alignment failing miserably or all together up to GCP and CP accuraties indicating errors of several meters in all three (XYZ) directions. For what it's worth, these are the specs for the smallest of the two areas (see also attached screenshot, WSZZ_StudyArea).
Site specs
Area = approx 2.5Ha (450m in length, 70m at its widest).
Surface = 50% low standing grass / 50% bare soil
Elevation difference = less than 3m
Ground Control: 11 markers as GCP, 7 as independent checkpoints. The markers were positioned and measured using RTK-GPS before the flights and measured again prior to removal after the flights. XYZ coordinates were then averaged before being imported to PS.
The data was captured using the following:
Device specs
UAV: DJI Inspire Pro
Camera: Zenmuse X5
Altitude: 40m AGL (GSD = approx. 1cm)
Flight speed: 4.3m/s
Number of flights: 2 (total of 321 images)
Overlap (F/S): 75% - 75%. The overlap between the two flights was approximately 200%, just to be sure.
GCPs: Leica GS08 Plus
Initially the following processing workflow was used, in accordance with settings that we have used across most of our other projects: Alignment accuracy was set to High, Generic+Reference preselection were turned ON and Key- and Tie Point limits were set to 40.000 and 4.000 respectively. After Alignment we would manually mark the GCPs on all images they are visible on (> 9) as well as the Checkpoints but keep the latter checked OFF in the reference pane. Then camera's are Optimized (checking all boxes, except P3 and P4) and the resulting errors for both Control- and Checkpoints studied in the Reference Pane.
Immediately after Initial Alignment, however, a large black area can be distuingished in the scene where the two flights met. No Tie Points were found here whatsoever, regardless of overlap being well over 200% here and the underlying scene being no different than elsewhere (see WSZZ_AlignmentBlack). Inclusion of GCPs and Re-Optimization of Camera's did not result in improvements. Neither did re-running of Alignment using 40k/10k, 120k/40k, 160k/40k or 160k/120k for Key- and Tiepoint limits or turning Generic and Reference Pair Preselection OFF or ON. Although allowing a higher number of Tiepoints did result in the bare spot becoming smaller, the Sparse Cloud remained notably different from other locations in the scene.
To make matters even more interesting I decided to process each of the two flights in two seperate chunks, mark the GCPs in each, and merge both chunks using the GCP markers thereafter. This time, the area that remained fully black in the previous attempts was actually provided with a decent level of tie points. It remained somewhat more sparsely populated than other parts of the scene, but it at least demonstrated that the images of the scene were find and DO allow for Tie points to be found. Merging of both chunks, however, failed miserably and left a large vertical gap between both flights, regardless of each being georeferenced using RTK-GPS GCPs and basing the merging on Markers (see WSZZ_ChunksMisaligned).
Also please have a look at the screendump attached (WSZZ_ImageShift) displaying the water barrier (sparse point cloud) underneath with the 'Aligned' images on top. The appears to be a massive horizontal shift between the scene on the one hand and the grid flown overhead on the other. This remains even when GCPs are added and MARKED in the scene! We are absolutely sure that all images were captured at nadir (gimbal angle varies between minus) 88-90 degrees) and the blue plane of each image after alignment confirms this as well, but the shift remains.
More importantly still, however, is the fact that the total error (of both GCPs and CPs) throughout each of the above attempts was appalling. The total error averaged at around 2 meters although individual GCP errors reached even larger values. This notion remained largely unchanged throughout the different attempts, regardless of the number of Key- and Tiepoints, processing the flights seperately and/ or changing any other Alignment parameters. Even when I decided to incorporate ALL markers (including Checkpoints) as Ground Control Points for Camera Optimization, resulting in 18 GCPs in a scene as small as 2.5 hectares (!), the error remained in the order of meters. I have never ever witnessed anything like this produces as we have easily produced and (externally) validated both horizontal and vertical accuracies during prior projects below 5 cm.
Without going into too much detail it should be mentioned that we run into similar issues processing the images from the other pilot location. This location measures slightly bigger (4-5 Ha) and contains more (571) images and approximately 30 GCPs/CPs. The output, however, is almost identical. Alignment either fails miserably or produces weird artificats that cannot be explained for. Just as important, however, model accuracy is appalling with several meters (XYZ) even after the inclusion of an ever growing number of GCPs. Likewise, processing each of the flights seperately and then merging them together results in two vertically transposed models. After many hours I have managed to bring the two closers together, but GCP accuracy is still well over 30cm and absolutely not matching either expectations or the specifications.
In short, what is going on? We are absolutely clueless, regardless of processing a multitude of somewhat similar projects (and even larger) projects in the past without any problems and decent accuracies. What may explain this strange model behavior? More important, are there any more things we might consider in an attempt to succesfully produce the desired outputs after all?