Do you have differences between just GCP checkpoints - results just from the alignment and optimizations? Since the surfaces from depth maps is a different process, as I understand it, from 1.6.5 and 1.7.x I am wondering if the difference is because of the DEMs and how they are created.
Hi Tom,
I have only placed and enabled a single GCP (as a control point) because I am trying to (a) minimize all of my manual and subjective pointing and clicking, and (b) evaluate how well we can reconstruct surfaces with minimal ground control. All of the other GCPs/checkpoints are in the project, but they are disabled and unplaced on individual images. I should be able to make a GCP master file with each point placed on every photo and import that and enable it (with the other GCPs unchecked) to compare accuracy - I hope to do that soon, but summer field season is going to make it a fall/winter project I think.
To clarify re DEM production - I am still generating DEMs from the dense cloud - again, using the same process, exactly (scripted/batched) for both versions of metashape, but from what Alexey has said (and I think maybe what you were referring to), I understand that they made significant changes in both the alignment and the depth maps algorithms. I did notice with the dense clouds that there is much more complete reconstruction in areas that previously had larger gaps (particularly in areas of low texture) - maybe those areas are being more thoroughly, but more noisily reconstructed? Not sure.
So, in other words, yes. I wouldn't be surprised if some aspect of the error is attributable to changes in depth maps/dense cloud reconstruction, and is propagating to the DEM from the dense cloud. One thing I noticed that makes me think there's error attributable to the alignment though is that the sparse clouds have many more points initially (something like 20% in our case I think) - and if that represents including points in their implementation of the SIFT algorithm that would have been rejected (something like reducing the difference-of-gaussians threshold or changing the way that's calculated?) in previous versions, maybe that could be a factor? total guessing here.
I've tried to do a closer look at residual error in the camera model, but I'm having issues with calibration coefficients not reliably propagating through to the final aligned project, so that makes recovering those values hit-or-miss at the moment.
Are there deviations in the pure camera calibration / control points?
(Without a point cloud or an elevation map being calculated?).
Hi c-r-o-n-o-s,
If I understand correctly, you're wondering about differences in the GCP and camera error (lens model error too?) between 1.7.3 and 1.6.6? I haven't been able to fully evaluate the lens model errors because of problems propagating camera calibration coefficients through optimization, but I should be able to compare the camera and single-GCP errors and update on that - Although it probably would be good to do what I've been thinking about, and what Tom asked about, and manually place the other GCP points on all the images to use as checkpoints and compare the error in the alignment-only between the two versions.
The only things I can comment on at the moment re the "pure" alignment parameters are that after optimization:
1) RMS Reprojection Error was slightly lower in 1.6.6 vs 1.7.3 (0.289357 pix vs 0.297011 pix - test 2b and 0.30069 pix vs 0.306297 pix - test 2a), (max RE was higher in 1.6 in test 2b but higher in 1.7 in test 2a) (2b and 2a are different collections of flights - internal referencing system for my brain - processed identically).
2) 1.7 found about 20% more points than 1.6, removed about 3% less of the original points during optimization, and aligned about 0.05% more images in both test 2a and 2b
3) in test 2a, total camera error (m) is reported lower for 1.7 (0.14496) than 1.6 (0.14795), and computed average camera error (m) from individual camera error values is also lower in 1.7 (0.12472 than in 1.6 (0.12660).
BUT interestingly, average camera error (
pix) is higher in 1.7 (0.31083) than in 1.6 (0.30448), Haven't looked in 2b yet.