Messages

1

Bug Reports / Re: Is the Mosaic blending in texture generation broken with GPU acceleration?

« on: September 24, 2022, 12:33:54 AM »

Mosaic on CPU works, and for some reason it is not terribly slower than GPU. GPU took about 6 minutes, CPU took about 11 minutes without UV maps production cause that was done by the GPU already. Both for 4K texture.



Alexey I will prepare a data package on Monday and send the link to support. Thank you for the good work.

2

Bug Reports / Re: Is the Mosaic blending in texture generation broken with GPU acceleration?

« on: September 23, 2022, 01:43:33 PM »

I have checked with the 1.8.5 pre-release and the issue is still there. Mosaic blending on GPU creates soft-blurry textures, disabled on GPU creates non-coherent, choppy textures, Averaging on GPU seems to be working, but is not ideal. I'll have to wait couple more hours to check if mosaic on CPU still works.

3

Bug Reports / Is the Mosaic blending in texture generation broken with GPU acceleration?

« on: September 16, 2022, 01:15:51 PM »

I've recently updated to Metashape version 1.8.4 with latest recommended NVidia drivers for two Quadro RTX4000 (driver is 516.94).

I run my usual routine, but now textures aren't being rendered correctly with the Mosaic blending mode when GPU acceleration is enabled. I've done the same texture using the Mosaic, Average and Disabled options with all other settings the same (Diffuse map, Generic for UV, 4K resolution, Hole filling and Ghosting enabled if present, From Images). I attach three screenshots one with Mosaic and the other with Disabled (Average gives about the same results) and with Mosaic without GPU.

Is this a bug?

4

Feature Requests / Re: Close Holes - Within Selection

« on: September 02, 2021, 11:38:46 AM »

I second the proposal, close holes within selection or close holes working only on the filter by selection part of the mesh would be excellent. For complex meshes I currently resolve to exporting the model in 3rd party software to close holes.

5

Bug Reports / Re: 1.7.4 update flaws in texture and texture missing on file reopen

« on: September 02, 2021, 10:08:52 AM »

I'm having a similar or perhaps the same issue with pixelated/stretched texture patches. If I texture the mesh as it comes out of processing, everything works ok, but if I do any kind of post-processing on the mesh, the texture presents random patches of pixelated/stretched texture. I've seen this behaviour both for models that were exported, modified in third party software (sculpting, fixing non-manifold geometries, holes closing, etc.), imported back to Metashape and trying to rebuild the texture (Generic, Images, 16k, Mosaic); and for models with meshes that were refined, smoothed or otherwise post-processed within Metashape. The issue started in version 1.7.4 no matter what build, and I tested both on v.13028 and the previous one (don't recall number, but it came out in early August). I believe it has to do with some error during the parameterization of the texture atlas and I'm guessing it mistakenly reserves a very small space on the UV for a larger area on the mesh (I opened the UVs in Blender and verified that this is the case - very small areas that get stretched and pixelated because they apply to a large area). The software behaves entirely randomly and every time the patch/patches is/are different both in size, number and location. I've tried it on two objects, two to three times each for each version, and getting consistently pixelated/stretched patches in the texture. I rolled back to 1.7.1 and the issue seems to go away.

6

General / Model quality or how to interpret errors in Metashape?

« on: August 25, 2021, 09:25:37 AM »

Just a quick question on how one should interpret the errors reported in the Info windows and Reference pane. I am working on high detail-high quality objects for the GLAM sector and I need to make sure that what I am seeing visually matches what the software considers as good quality.

For the Info windows usually the RMS reprojection error ranges between 0.2-0.35 pixels. Is this good enough?

For the Reference pane the Total error for markers is very confusing, as it gives errors that range from 5 to 10m, but in the pixels column the error is between 1-3 pixels. I know my pixel size is about 5nm, hence the error should be very small.

Also in the Reference pane the Total error for scale bars is almost always less than 0.1mm (hovers between 0.02-0.08mm). The accuracy is verified by conducting measurements using the ruler tool in Metashape and comparing it with physical measurements on the objects themselves using a digital ruler, where measurements match up to two decadal points of a centimeter (0.01cm).

Why does the Total error in metres for markers is off? Is it because I'm not using a spatial measurement device (e.g. Total Station) to pinpoint them in physical space?

Thank you for any clarity on the issue.

PS: I have already read the Manual for Metashape, but it does not provide practical examples on how to interpret the numbers.

7

Python and Java API / Re: Python script no longer running in Metashape 1.7.4

« on: August 25, 2021, 09:02:21 AM »

Hi Alexey,

I tried to reproduce the issue today with the previous code and it functions as expected, so I guess some sort of random error. The error it was giving was: "Error: Run script failed"

I did update graphic cards drivers yesterday too, because it was giving a "Can't find tile size" error too, but I'm guessing this was unrelated. In any event, it all works now.

8

Python and Java API / Re: Python script no longer running in Metashape 1.7.4

« on: August 24, 2021, 01:07:13 PM »

Apparently [photo] has been replaced by [camera], and script running now requires for reasons I don't yet understand administrative rights.

The following worked:

Code: [Select]

import Metashape
chunk = Metashape.app.document.chunk
for marker in chunk.markers:
    for camera in list(marker.projections.keys()):
        if not marker.projections[camera].pinned:
            marker.projections[camera] = None
Also the print commands kept causing script failure, but once removed everything worked. All in all consider the issue resolved.

9

Python and Java API / Python script no longer running in Metashape 1.7.4

« on: August 24, 2021, 12:54:32 PM »

Has anything changed with how Python is handled in Metashape 1.7.4? The script below worked with 1.7.3, but it no longer does.

Code: [Select]

import Metashape

chunk = Metashape.app.document.chunk

for marker in chunk.markers:
for photo in list(marker.projections.keys()):
if not marker.projections[photo].pinned:
marker.projections[photo] = None
print("Projection for "+marker.label + " removed on " + photo.label)

print("Script finished")
Any suggestions?

10

General / Re: Automate marker pinning via Python

« on: July 09, 2021, 10:34:46 PM »

Thank you for the clarifications Alexey! They will really be very handy for future work and I hope people find this post helpful, as it can really cut down on the time necessary to review and place markers.

11

General / Re: Strategy for texture on edited mesh

« on: July 08, 2021, 10:43:26 PM »

Couple of questions:
a. What software did you use to create the meshes?
b. When you say edited the mesh, what type of edits did you perform? If you scaled, rotated or moved the mesh, you'll likely have issues once back in Metashape.

12

General / Re: Automate marker pinning via Python

« on: July 08, 2021, 10:33:51 PM »

Thank you very much Alexey! Will this pin both white and blue flag markers, or only the blue ones? If it is all markers, is it possible to get only the blue ones? If so, I'd suspect a slight change is needed in the Metashape.Marker.Type.Regular variable.

13

General / Automate marker pinning via Python

« on: July 08, 2021, 11:46:13 AM »

I have searched the forums for marker batch operations, but I'm coming up empty, save for removal of blue flag markers via a Python script.

The issue I have is that I'm running heavy photogrammetry projects (c. 600-800 photos), each one having more than 15 markers on it. Marker auto-detection worked, but has labelled everything with blue flag markers. Pinning each one is very time consuming, and there is very limited need to move markers, as the vast majority of them have been correctly placed by the algorithm. So the question is: Is there any way to programmatically batch convert all the blue flag markers on photos to green flag, namely actually pin them?

Thank you for any help on this. Also it would make for a great new feature for future versions of Agisoft.

14

Bug Reports / Re: Issue processing colour using the ProPhoto RGB colour space

« on: April 25, 2021, 11:55:08 AM »

Would it be ok to send big files? I'm uploading the folder with everything including initial photos to a OneDrive location.

15

Bug Reports / Issue processing colour using the ProPhoto RGB colour space

« on: April 24, 2021, 06:07:50 PM »

After testing for several hours and with several different sets of data, I'm concluding that Metashape 1.7.2 does not process or parse correctly 16-bit or 8-bit photos with the ProPhoto RGB colour space. Upon importing photos, the colour values change and for some reason the quality of the produced thin point cloud is lower than with using other colour spaces (checked with Adobe RGB, sRGB, and DNG/RAW without assigned colour space). Since the Metashape manual states that "Metashape uses the full color range for image matching operation and is not downsampling the color information to 8 bit", I'm considering this a potential software bug, unless there is confirmation that the ProPhoto RGB is not a supported colour space in Metashape.

An example of what happens in another post I made earlier today: https://www.agisoft.com/forum/index.php?topic=13301.0