Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - jedfrechette

Pages: [1] 2 3 ... 8
General / Re: Import Laserscan data -registration lost
« on: January 06, 2022, 08:02:49 PM »
I use Cyclone for TLS and take a lot of time looking at the data in 3D to choose my reference points as accurately as possible. I'm almost always working with buildings, so I'm looking at windows and cornices etc, to get my points correct to within a couple of mm, which is not possible currently in Metashape just by putting a marker on a depth map in '2D'.

I think this is the key observation that the Agisoft developers need to make if they want to make laser scan support actually useful in their product. Those of us coming from the TLS world have very good tools to make sure that our laser scans are very well aligned relative to each other as well as independent reference points.  In most cases those registrations are also much better constrained, and therefore more reliable, than pure photogrammetry solutions. As a result, just treating laser scans as low resolution panoramas and throwing them in to your bundle adjustment largely ignores their benefits and is never going to be a satisfactory solution.

Currently, the only practical method I've found for combining laser scans and photogrammetry with Metashape is the traditional approach of manually picking ground control points. However, that method is also time consuming, error prone, and requires jumping back and forth between multiple pieces of software. We've worked on a few Python tools to make it slightly less painful but the process is by no means as efficient as it should be.

Bug Reports / Re: 1.8 beta Cannot Read existing Batch Files
« on: September 22, 2021, 07:37:59 PM »
I can't speak to 1.8 specifically, but in general, I've found that new versions usually can't process batch files from the previous version. The instability of the batch file API is unfortunate and makes it much less useful than it could be.

Bug Reports / Re: All previous models open with no texture in V1.74
« on: September 16, 2021, 11:52:07 PM »
Is there an ETA for 1.7.5?

I had hoped we would be able to upgrade to 1.7.4, but the broken UVs is a pretty major bug that currently prevents that.

General / Re: Import Laserscan data -registration lost
« on: March 23, 2021, 05:35:11 PM »
It would be nice if the developers offered a simpler solution here in the future.

I can only second this. After experimenting with the proposed workflow and following threads like this the entire process seems a little half baked, and definitely not something I would consider production ready. I hope the developers reconsider their approach to this problem and can consult with users who regularly combine photogrammetry with laser scan data so that they can better understand our use cases.

In my case it also depended on what I was meshing, can you show your camera alignment?

I imagine VRAM usage also depends on how much overlap there is between images? Most of my datasets have a very high degree of overlap and judging by the logs are almost always hitting the maximum of 40 neighbors.

Attached is a screenshot of a test data set I shot using a 24 megapixel camera. With this data set I'm able to trigger the error on an older machine with a 6 GB GPU by attempting a reconstruction at Ultra High Resolution.

Adding the tweak didn't help. Meshing still fails with the following error message on my machine:

Code: [Select]
Warning: Device Geforce RTX 2080 TI ignored because it has 8929/11264 MB available, but 10249 MB required.
The amount of required memory was not decreased by adding the pm_convert_16u_to_8u tweak. Is that because the images I'm using are 16-bit float not 16-bit uint images?

They are 40-60 megapixel half-float linear exrs so converting to 8 bit internally makes sense. I'll try the tweak and report back.

One question about the 8 bit conversion. Do I need to worry about the range of values in the exrs? Our images use a pretty conventional scale, normalized so that an 18% gray card would have a value of 0.18. The majority of values will be in the range 0-1.0 but it's not uncommon for some values to be greater than 1 depending on the scene and exposure level. In other places inside Metashape where the exrs get converted to 8-bit, e.g. thumbnails, point cloud colors, and view port texture maps, the images appear badly overexposed. We generally need to use Tools -> Set Brightness to compensate for this.  Will pm_convert_16u_to_8u do the color transform correctly to deal with the dynamic range and scene-linear input data?


Yes, as of this writing the latest WHQL Nvidia drivers are 461.40, which is what we are using.

The current version of Metashape 1.7.1 build 11797 fails to use GPUs for depth map generation with the same settings that succeed with 1.6.5 build 11249. This was reported in the pre-release thread in the following post:

I can't seem to use GPU for depth map generation.  I get the following error:

Warning: Device GeForce GTX 1070 Ti ignored because it has 5958/8192 MB available, but 6870 MB required

We're using different GPUs (2080 Ti, driver version 461.40), but get the same error message, albeit with different VRAM values. Presumably, we're also using different size images than the original reporter. Nonetheless, opening the project files that produce this error in version 1.6.5 on the same machine allows us to utilize the GPU for depth map generation. Choosing a lower quality reconstruction in 1.7.1 also uses the GPUs for depth map generation.

The suggested workaround in the pre-release thread:

of setting main/depth_pm_max_neighbors = 40 does not seem to be possible any longer, however, from inspecting the logs it appears that processing is automatically limited to 40 neighbors in this version automatically.

General / Re: Import Laserscan data -registration lost
« on: January 23, 2021, 07:07:00 PM »
Thanks for putting together the example data set Dieter and I agree with the other posts that the laser scan support as currently implemented is not very useful.

I think the current approach of attempting to find and match key points in a panorama representation of a laser scan is also fundamentally limited. Compared to a photo, even high resolution scans are fairly low resolution making the task difficult. Furthermore, many scans are done without color so key points that are identified in IR reflectance may not correspond to ones in color images. If scans are captured with color, that means an additional calibration between the scanner's internal camera and it's measured 3D points, which may introduce an additional source of error.

I think it would be much better to follow an approach similar to what is described in the paper:

A Fast and Robust Framework for Semiautomatic and Automatic Registration of Photographs to 3D Geometry

which describes an algorithm for using known 3D geometry to refine the estimated external and internal camera parameters. This would be a much more general solution and would eliminate many of the limitations of the current implementation.

General / Re: 1.7.0. Results of reworked depth maps generation algorithm
« on: January 09, 2021, 09:28:45 PM »
Let's just say there aren't many other programs out there that are quite a bit faster than Metashape... I don't think we should elaborate on other software here.

Why shouldn't we be able to mention other software? This whole poisonous idea that you shouldn't talk about other software originated on the RealityCapture forums where the mods put in place draconian rules to that effect. Nothing exists in a vacuum and pretending that it does is foolish. All of the photogrammetry tools have improved significantly in the last few years and I think that is in no small part due to the competition between them and the ability to see what does and doesn't work well in the various packages.

One thing I really appreciate about Agisoft is the way they interact with their users, particularly on this forum. They are very receptive to feedback and constructive criticism, which ultimately makes their product better. That is distinctly different than the RealityCapture forums where users get banned for voicing criticism, which I think is incredibly shortsighted on their part. In the long run the best software is always developed based on user feedback and if the developers aren't capable of collecting and listening to that feedback their software will not improve as efficiently as the software of their competitors who do.

General / Re: Plans for detailed manual?
« on: November 26, 2020, 07:55:20 PM »
Agreed. The documentation could use a lot of work. I really like the software, but whenever somebody asks me about it the poor documentation is a caveat I always need to bring up.

Python and Java API / Re: How to get file path?
« on: November 17, 2020, 12:57:57 AM »
Is this what you're after?
Code: [Select]
from os import path

current_doc =
current_dir = path.dirname(current_doc)

Bug Reports / Re: Freenas local network processing
« on: November 02, 2020, 07:59:18 PM »
Nobody used / uses freenas to store and work on projects ?
We use it as our main storage mounted as SMB from Windows machines and haven't run in to any issues. I'm afraid I can't be more help than that.

Maybe you're running in to issues with the special characters in your paths? We try to limit them to the set: a-z, A-Z, 0-9, _, -.

General / Re: Agisoft Metashape 1.7.0 pre-release
« on: October 28, 2020, 08:24:27 PM »
It seems a lot of manual work to input the coordinates of each laser setup (and presumably orientation?) to ensure they stay fixed. I take great care over my registration and wouldn't trust any algorithm to do a better job! We treat our laser data as sacred and once it is registered everything else (so many things...) is derived from it, but can not be allowed to affect it!

Agreed 100%. Treating laser scans as fixed should be the default behavior. Perhaps other users have a use-case where they should be freely adjusted but I strongly suspect that is a minority position, in which case, it should require additional settings to achieve.

If setting scan locations and rotations is the way to prevent scans from moving that should happen automatically during import and their accuracy weights set high enough that they do not move at all during future alignments.

Pages: [1] 2 3 ... 8