Forum

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 - wgreenePIMS

Pages: [1]
1
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

2
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!

3
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.

4
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!

5
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!

6
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!

7
General / Re: Depth scaling introduces huge error to scale bars
« on: October 14, 2022, 04:04:30 AM »
Hi there,

I also use Metashape for this purpose frequently! Like Alexey said, the best way to get around this is to set very low accuracy for the X and Y values and high accuracies for the Z coordinates. Your scale bar accuracies should be pretty high based on your measurements (probably an accuracy of .5mm is reasonable), and for the depth GCPs, your Z accuracy should probably be around 0.1 meters or thereabouts if you're using a dive watch to collect depths. The XY coordinates will be arbitrary (unless you're setting up some kind of specific local coordinate system) so you should set the accuracies of those to a very high value like 100m so that Metashape won't try to take those into account with the same "weight" as the scale and depth. To do this you'll want to type in something like 100/0.1 in the accuracy column for the depth GCPs. The / tells the program that you're setting the XY and Z accuracies separately. Then if you update the transform, you should get good depth and proper scaling at the same time!

8
Bug Reports / Historic Aerial Alignment
« on: November 17, 2021, 07:57:42 PM »
I'm having an interesting issue with the alignment of historic aerial imagery in Metashape 1.7.3. I have a set of 69 scanned photos for which I have the focal length and film size/scan resolution. Most of the scans include all the fiducial marks, but some of them have one of the marks (on the top) cropped just out of frame. They are all sized the same in terms of pixel dimensions, so Metashape automatically recognizes them as a single calibration group. If I do not check the box for film camera with fiducials, Metashape is able to align all the photos without any issue, as there is plenty of overlap to work with. This method introduces some significant errors, however, because while the scans are the same dimensions, they're not all aligned perfectly to the fiducials, and thus the camera calibration is not super accurate. When I try checking the box for film camera with fiducials, and then calibrating fiducials, it does a good job of predicting the location of the fiducials that aren't set manually, even if the 4th one appears out of frame. At that point in the process, it seems like Metashape is doing it's job well. When I try to run a camera alignment after doing all the fiducial work, it cannot successfully align the set. Sometimes I get up to 34 cameras aligned, and the program seems to do a good job with the calibration, but I am unable to get the rest of the set to align. I'm not sure how to proceed because the project requires a high degree of accuracy (~1m or so), so any help would be much welcome. I guess a part of the question is whether Metashape is able to deal with historic imagery where in some cases, one of the fiducials is out of frame. Thanks!

Will

9
Feature Requests / Re: Export report to machine-readable format
« on: August 18, 2021, 04:28:22 PM »
+1

10
Feature Requests / Median Orthomosaic Blending Mode
« on: August 16, 2021, 04:49:16 PM »
In most cases, the currently existing average and mosaic blending modes for orthomosaic generation work well. There are, however, circumstances where using a median blending mode instead of average would be incredibly useful. The example I've come across is creating drone-based orthomosaic maps where the water surface is present - if there's surface reflection / glare, then the mosaic blending mode produces very noisy results, because some images have extreme glare while others do not. The average blending mode solves the reflection problem, but introduces other issues, such as ghosting of objects that have poorly defined geometry, especially defoliated trees / shrubs, and the influence of especially bright spots or lighting changes on some image areas. A third blending mode, which simply uses the median pixel value for a given location, should help to solve some of those issues.  Median blending should be very easy to implement - it's already possible to accomplish in a GIS program by mosaicking exported orthophotos. It would save lots of time and effort to simply include it as an alternative blending mode within Metashape, though! If people have ideas about using Python scripting to accomplish this, that would work too  :).

11
Feature Requests / Underwater Photogrammetry: Mask by Depth
« on: July 20, 2020, 06:13:04 PM »
When using Metashape with underwater datasets, dense cloud noise is sometimes generated from source imagery from more distant photos. Water clarity can be a real issue with underwater photogrammetry, and a simple solution to the problem would be enabling a way to generate masks from depth maps. If after setting scale, you could set a distance threshold (say 4 meters), and areas where depth maps indicate that the camera is more than 4m from the surface to be reconstructed would be masked out. It seems like this wouldn't be too hard to implement and would enable significant improvements in underwater model clarity.

Pages: [1]