TLS + Photogrammetric data compilation bug?

[skretz]

Hello all.

I have been successfully combining TLS+ PG data in Metashape for a couple years now with mostly fantastic results. We also use Context Capture (typically exporting camera positions from Metashape), but I find myself lately just doing our workflow start to finish in metashape because it is simpler and the results are acceptable.

However, I have a project from 2017 I decided to re-process combining the scans and photos and am getting a very bizarre/inexplicable result.

I have my main chunk with the photogrammetry aligned and registered to the same survey as the TLS.  Due to holes in the PG (DSLR photos taken from a manlift) I wanted to add in the scans to create a nearly watertight point cloud. I have done this many times before, adding the scans in after the fact, applying the script to set the locations of the scans, etc.  It has always worked, regardless of whether or not I "align" the TLS pano images or use the script.  I sometimes get slightly better results aligning and then using the script, but not always.

Anyhow, for this project, I have done everything, and I keep ending up at the same result.  A bizarre movement and scalar reduction of the entire model. It affects the references, scans and images.

When I bring in the scans, they show up in the correct location relative to the survey and the photo locations. But as soon as you build something from it, or click refresh on the references the scans, photos and any reference markers activated on scans or photos will move with an overall error of over 9m.

I have attached screen captures of the error, and will attach 3 more in another post showing the dense cloud result as well, you can see the scale on the scans is unchanged and remains correct, but because the locations of the scans have been scaled the productions using this data has the scans split all over the place.

This happens exactly the same way with 1.7 or 1.8.

The survey is in a local coordinate system. I haven't tried creating a dummy WCS to see if that is the issue.  I also haven't tried starting a new project with all the raw ingredients from scratch (I may just for troubleshooting purposes).

I have left the accuracy of the scans at the  10m default, and tried moving it down in increments to 0.001m. The error changes slightly, but still does not correct the issue.

However, my scans and my photogrammetry on their own, in Recap line up perfectly, as do they in metashape until you click refresh (or if you don't it still gives you the same dense cloud result).

[skretz]

Here's the additional screen caps.

In number 5 I have turned all the layers on.  The red line and red circle are the correct locations of the model and the scans.  The green is the result after the references are refreshed.

In cap #6 you can see just the locations of the references that aren't activated on images (in their correct locations) as well as the ones activated on images and the image/scan locations that have inexplicably contracted in scale.

# 7 shows the resulting dense cloud...  The scans are split apart relative to each other and their original registration, both horizontally and vertically in the case of the roof scans..  The scan parallel to the photogrammetric data is in the correct orientation, and appears to have a realistic scale, but the PG model has shrunken in size due to this issue. You will see the roof data is also appearing below the roof, relative to the scans. I guess a scalar factor is being applied to the registration of the scan location, but leaving the scans themselves unscaled.

[skretz]

I can confirm that exporting the existing metashape photo alignment to an XML bundle, opened in Context Capture and then brought in the same scan data E57's and it looks great..  The tiling and combining of the tiles is a step I wanted to avoid.

I also tried running the photos and scans from scratch with an align.. again, as soon as you place the scans with the script... same scaling issue.

Hopefully Alexei or someone can help address this issue/bug.

[Dieter]

The subsequent addition of scans no longer works since some version. I've brought this up here many times, but apparently no one cares. As soon as the update button is pressed, the entire project orientation is destroyed. It's really a pity, because we often need it...unfortunately.

Dieter

[skretz]

Hi Dieter, 

This happened in both 1.7 and 1.8, but only for this project.  I had another 2 weeks ago that I added scans to afterwards (to help cleanup the mesh under eaves/overhangs), and that one worked fine, as it usually does.

The only differences I can discern is that the other project that worked is in a UTM, and this one is in a local system.  The other project has some UAV photos in it along with terrestrial DSLR, but this project is all DSLR.

[Dieter]

Well, what's the difference?

If the scan files and the images are in the same coordinate system, shouldn't it work?
At least that was the theory.
Then external scripts were programmed, which were partly wrong, a fixed integration into the software Metashape is probably not planned, that's all just tinkering. I've already had a number of discussions on this exact topic, but unfortunately without a result in the end.

Dieter