Messages

1

General / Re: Calculating vertex colors very slow

« on: October 31, 2025, 06:39:01 PM »

For now, I've just been running models without ever building vertex colors. For the workflow I use, they are not critical. Coral3D, it sounds like you're working on similar projects to what we typically do. Check out the workflow for this I've created over at https://github.com/Perry-Institute/ReefShape - it may be useful to you!

2

General / Re: Beta-testing of new texture blending algorithm

« on: October 31, 2025, 03:30:37 PM »

Thanks, I was aware of that option and it does work but it extends the processing time quite significantly. It would be amazing if we could use the natural option just with orthomosaicking so we can also specify the output resolution from the get-go! Especially in Caribbean settings where we have a lot of moving soft corals (and fish!), the natural texturing seems like a huge step up from the traditional mosaic blending.

3

General / Re: Beta-testing of new texture blending algorithm

« on: October 31, 2025, 12:33:42 AM »

Is there any plan to expand this new natural texturing algorithm to orthomosaic generation rather than just model texturing? Many coral reef researchers do most of their analysis on orthomosaics, not 3d models, and thus would greatly benefit from this...

4

Feature Requests / Re: Progress bar/Progress % in Console for Calculating Vertex Colors...

« on: June 11, 2025, 06:36:02 AM »

+1 on this - it does seem to be taking way longer to do vertex colors recently. Is there any potential to do this process on the GPU to speed things up? I've found that choosing not to calculate vertex colors when building the mesh, but later executing the command independently from the tools menu speeds things up quite a bit and yields full CPU usage.

5

Bug Reports / Re: Only 3 decimal shown in reference in update 2.2.1 build 20502

« on: June 10, 2025, 11:29:02 PM »

+1 to this as well, four decimals for geographic coordinates would be much better in many cases, and the best solution would definitely be a user-configurable setting

6

General / Decimal places in reference panel

« on: May 15, 2025, 06:01:06 PM »

In the latest version of Metashape the number of decimal places shown in the reference panel is now 8 digits for Lat/Lon and 3 digits for linear units, as is mentioned in the change log. There are many cases where 3 decimal places for linear units is insufficient - I know you can double click on the values to get the full number to show, but is there a way to increase the decimal places shown by default?

7

General / Re: Calculating vertex colors very slow

« on: May 14, 2025, 01:31:54 AM »

I'm having the same issue for underwater image sets. Models are typically very large (~60-180M vertices) but build fairly quickly on an RTX4090 / 14th gen i9 / 64GB RAM workstation. I do have fit additional corrections turned on during optimization - how would this affect vertex coloring?

8

Bug Reports / Re: Orthomosaic + JPG compression fails if Save Alpha Channel selected.

« on: June 10, 2024, 08:59:21 PM »

Excellent, thanks Alexey!

9

Bug Reports / JPEG-compressed TIFF exports with alpha channel fails

« on: June 05, 2024, 01:17:55 AM »

I've noticed that in the latest release, I get a libtiff error when attempting to export a GeoTiff using JPEG compression with alpha channel selected. This never used to happen! Here is the error message:

2024-06-04 15:01:43 ExportOrthomosaic: path = /Volumes/PIMS03/SimmsPt/outputs/SimmsPt_20220124.tif, image_format = TIFF, projection = WGS 84 + EGM96 height, resolution_x = 4.9532900000000004e-09, resolution_y = 4.5137299999999999e-09, clip_to_boundary = off, asset = 0
2024-06-04 15:01:43 Exporting orthomosaic...
2024-06-04 15:01:43 generating 52463 x 53822 raster in 1 x 1 tiles
2024-06-04 15:01:44 libtiff error: Bogus input colorspace
2024-06-04 15:01:44 Finished processing in 0.956797 sec (exit code 0)
2024-06-04 15:01:44 Error: TIFFWriteTile: unexpected error: /Volumes/PIMS03/SimmsPt/outputs/SimmsPt_20220124.tif

10

Bug Reports / Re: Metashape constantly crashes during Point Cloud creation (MacOS, eGPU (RX 6800)

« on: February 02, 2024, 08:06:27 PM »

Hi Michael,

Glad the tweak worked for you as well. That particular tweak has been around for a while (I guess since the new depth maps meshing technique came out around version 1.8 ) and I experienced issues with the new depth maps when they were first implemented, when they tended to cause strange folds and double-surfaces in some meshes, so I had to use that tweak to keep our production workflow functioning well. Those problems seem to have been fixed, and the new depth maps method is definitely an improvement in detail when it doesn't cause crashes, so I've switched the tweak off on most of our machines. The Mac/eGPU combination crash issue and your fix of going back to 1.8 made me wonder if the new depth map method was the culprit, which it clearly is based on our experiences. While this workaround is okay for now, I'd really like to see this issue addressed by Agisoft.

Will

11

Bug Reports / Re: Metashape constantly crashes during Point Cloud creation (MacOS, eGPU (RX 6800)

« on: February 01, 2024, 01:39:03 AM »

One update on my end - I was able to stabilize depth map generation on the eGPU by using the BuildDepthMaps/pm_enable tweak (set to false). This reverts to using the old depth map generation method (AFAIK) and seems to keep the program from crashing. For now, it's the solution I'm going with because allows me to continue using 2.1. Alexey - can you provide any more information on this? Thank you!

12

Bug Reports / Re: Metashape constantly crashes during Point Cloud creation (MacOS, eGPU (RX 6800)

« on: January 26, 2024, 06:30:37 PM »

Any further feedback on this would be great - I am working with a very similar setup (Mac Mini 2018, i7, 32GB RAM, 8GB AMD RX5700 eGPU in a Sonnet Breakaway Puck) and have been experiencing similar crashes that have dramatically intensified recently. I'm running the very latest Metashape version (2.1.0) and I've reinstalled a few times - this does not solve the issue. My crashes occur during depth map building - tie point building and alignment is stable and works great even for very large projects (3-7k images), but I've been unable to generate models even at medium depth map quality for much smaller projects of 1k photos or so. I've had zero other issues with the computer and it seems like the crash problem is tightly related to stability issues during depth map generation.

13

Bug Reports / Re: Crashing on Mac eGPU

« on: May 24, 2023, 07:06:45 PM »

Hi Alexey,

I have submitted the reports but next time it happens I will add the link. Thank you!

14

Bug Reports / Crashing on Mac eGPU

« on: May 24, 2023, 03:27:13 PM »

Hi there,

I'm running medium-size underwater coral reef datasets (~1500 24mp images) with the latest 2.0.1 Metashape Pro version on a Mac Mini (2018, 6-core Intel i7, 32GB RAM) with the latest operating system installed (Ventura 13.4) and a Sonnet Breakaway Puck eGPU with an AMD RX5700 8gb card. The setup works very well at accelerating most apps, but I've found that having the GPU checked in Metashape settings (so, actually making use of the eGPU) results in very frequent crashes, especially while executing GPU-intensive tasks like building depth maps and depth map-based meshing. My processing logs indicate nothing - there's no error noted in it, the program simply crashes. Does anybody have any suggestions for me? I know this is an unconventional setup to be working with, but I see no reason why it shouldn't work as it's supposed to. When it does work properly, it's remarkably fast and effective, but given the crashes (happening with almost every dataset larger than 1,000 photos), it's been very frustrating. Thanks in advance for the help!

15

General / Median orthomosaic blending option

« on: March 21, 2023, 07:38:15 PM »

Hi Alexey,

I have a question related to orthomosaic blending. In the vast majority of cases, using mosaic or average is suitable, but there are certain situations that I run into frequently doing multispectral drone surveys of coral reefs where there are very significant outlier images, where waves or sunglint completely blows out some pixel values. The average blending mode works well to iron out some of these issues, but in certain locations where there are more frequent issues (crashing waves on a shallow patch of reef, for example), average leads to unusable results, even though there clearly are plenty of images in the area that provide excellent source data for those pixels. Attached is an example of the problems introduced by average blending in crashing wave areas.

I think a median blending or a weighted average mode would work far better in some cases, so that outlier values do not affect the results. Is there any way to do this via python scripting or is there potential to include an additional blending mode in the orthomosaicking step? A median blending mode would seem to be just as computationally easy as average. I know it is currently possible to export orthophotos and blend them in other GIS software using more complex blending options, but this workaround is tedious and very time consuming.

I've also found that the traditional method of drawing a polygon and assigning images on the ortho itself does not work while using average blending - you are allowed to make multi-selections as usual, but when updating the orthomosaic, nothing changes. If this could be fixed, it would at least help solve the problem significantly by being able to manually exclude some images from the average blending in specific areas.

As always, thanks for the excellent help with all of our questions!