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

Pages: [1] 2 3 4
1
Just a quick update:

It turned out that both of the errors for me were caused by the fact that I was accidentally using Metashape 1.6.2 -- I had forgotten to pip install Metashape 1.7.2, even though my code was written for 1.7.2. Updating the Metashape version fixed everything.

So for future reference, folks: If you see either of the errors I saw, it could just be a Metashape versioning problem!

2
In fact, using my own code & data that I just posted, I was able to successfully detect markers on a different machine. So it is certainly a problem with the machine. I will look into the Memtest. Thanks for the very quick reply!

3
Hi again,

I will take your advice and try to run memory tests. However, in the meantime, I have created the means to perfectly reproduce the error, just in case it is not related to my hardware/firmware.

Here is a dropbox link to the images (one full capture of RedEdge MX Blue, i.e. 5 files): https://www.dropbox.com/s/nanql7exftqqno0/images.zip?dl=0

And here is the code to reproduce:

Code: [Select]

import Metashape
import glob

images_dir='/path/to/images_dir'
paths=glob.glob(images_dir + '/*')

doc = Metashape.Document()
chunk = doc.addChunk()
chunk.addPhotos(filenames=paths, layout=Metashape.MultiplaneLayout)
# AddPhotos: layout = MultiplaneLayout
# lm optimize: xxxx--------x-x-x--x-x-------- 1.24813 -> 4.88783e-14
# Calibration initialized, mean error = 6.91244e-14 pix, max error = 3.21555e-13 pix
# lm optimize: xx--- 0.0538587 -> 0.00957659
# Vignetting initialized, mean error = 0.0102956, max error = 0.0351406
# lm optimize: xxxx--------x----------------- 1.30994 -> 4.87049e-14
# Calibration initialized, mean error = 6.88791e-14 pix, max error = 3.21555e-13 pix
# lm optimize: xx--- 0.0702812 -> 0.00656294
# Vignetting initialized, mean error = 0.00708867, max error = 0.0220412
# lm optimize: xxxx------------------x------- 1.37761 -> 4.86505e-14
# Calibration initialized, mean error = 6.88023e-14 pix, max error = 4.54747e-13 pix
# lm optimize: xxx-- 0.0525239 -> 0.0067085
# Vignetting initialized, mean error = 0.00728809, max error = 0.0285493
# lm optimize: xxxx--------x----------x-x---- 1.393 -> 4.9437e-14
# Calibration initialized, mean error = 6.99145e-14 pix, max error = 4.68743e-13 pix
# lm optimize: xx--- 0.0924907 -> 0.00521566
# Vignetting initialized, mean error = 0.00592781, max error = 0.0213214
# lm optimize: xxx--------------------------- 1.37947 -> 5.04523e-14
# Calibration initialized, mean error = 7.13504e-14 pix, max error = 4.58286e-13 pix
# lm optimize: xx--- 0.11524 -> 0.00838645
# Vignetting initialized, mean error = 0.0101272, max error = 0.0395673

chunk.detectMarkers(target_type=Metashape.CircularTarget12bit, tolerance=100)
# DetectMarkers: marker type = Circular 12 bit, tolerance = 100 
# free(): invalid next size (normal)
# Aborted (core dumped)

4
I'm also seeing the same error consistently in chunk.detectMarkers():
Code: [Select]
free(): invalid next size (normal)
I'm not sure if it's connected, but when I run Metashape.app.enumGPUDevices(), these log messages show up:
Code: [Select]
clGetPlatformIDs failed: CL_UNKNOWN_ERROR_CODE_-1001
Found 0 GPUs in 0.039938 sec (CUDA: 0.024209 sec, OpenCL: 0.015694 sec)

I will try to find the exact code to reproduce this, and post again here shortly.

5
Python and Java API / Re: Photo extent in orthomosaic
« on: May 03, 2021, 10:42:52 PM »
Thanks paulo.

We re-evaluated our work, and it turns out that the combination of the output of our script PLUS the camera.orientation value is enough to give us the ortho_coords in the correct order.

6
Python and Java API / Photo extent in orthomosaic
« on: May 02, 2021, 12:49:52 AM »
Hello,


I need to locate the extent of an input photo, that is the four corners of a camera.photo, within the orthomosaic (in CRS coordinates). So if my photo has size 4000x3000, I need the following output:

photo_coords (px)   ortho_coords (UTM)
(0, 0)(500000, 3000000)
(4000, 0)(500125, 3000050)
(4000, 3000)(5000176, 3000072)
(0, 3000)(500034, 3000101)

The ortho_coords are just fake UTM coordinates. I have the photo_coords, obviously, but I need the ortho_coords, and I need to match them to the photo_coords.
 I am using a script written by Alexey Pasumansky created as an answer to this forum post: https://www.agisoft.com/forum/index.php?topic=6662.0.  The important part of the script follows:
Code: [Select]

if chunk.dense_cloud:
surface = chunk.dense_cloud
elif chunk.model:
surface = chunk.model
else:
surface = chunk.point_cloud

for camera in chunk.cameras:
if not camera.transform:
continue #skipping NA cameras

sensor = camera.sensor
corners = list()
for i in [[0, 0], [sensor.width - 1, 0], [sensor.width - 1, sensor.height - 1], [0, sensor.height - 1]]:
corners.append(surface.pickPoint(camera.center, camera.transform.mulp(sensor.calibration.unproject(PhotoScan.Vector(i)))))
if not corners[-1]:
corners[-1] = chunk.point_cloud.pickPoint(camera.center, camera.transform.mulp(sensor.calibration.unproject(PhotoScan.Vector(i))))
if not corners[-1]:
break
corners[-1] = chunk.crs.project(T.mulp(corners[-1]))

if not all(corners):
print("Skipping camera " + camera.label)
continue
return corners

The corners returned by this script are correct, but the ordering is not guaranteed! The ordering might match my photo_coords if the camera is pointed north, but not if it points south or west or east. Does someone know how I can use the orientation of the camera to put my output corners in the correct order to match the photo_coords?



7
Hi,

I am trying to ensure that the images used to build my orthomosaics are full resolution.

The user manual states that with alignment accuracy <= Medium and dense cloud quality <= High, the images are down-scaled by a factor of 2 in both dimensions (total resolution reduced by a factor of 4). But is that down-scaling only applied to the actual processes of image alignment & dense cloud generation? This will affect the number of tie points, size of the point cloud, etc., but I don't think it MUST affect the output resolution of the orthomosaic. Will the full-resolution images be used to actually build the orthomosaic, regardless of these settings?

Thanks!

8
Thanks Paulo, very helpful.

9
General / Best practice for dealing with inconsistent GPS datums?
« on: May 06, 2020, 01:04:08 AM »
In our UAV dataset, we have images with GPS tags using the WGS84 datum. Agisoft markers were used on the ground, and their locations were recorded in the NAD83 datum. We can expect that the GPS tags will therefore be shifted by up to 1m between the images and the markers. What is the best practice for the most accurate photogrammetry in Metashape?

1. Pretend all GPS tags are in NAD83, and set measurement precision of the camera reference entries to be lower (1m - 10m, compared with 0.02m for markers).

2. Remove the camera reference entries altogether, and generate the georeference only based on the markers in NAD83.

I would appreciate any input. Thanks!

10
 Ah, I see. I had accidentally set the chunk.crs to epsg:4326. Now, I set chunk.crs = None, and rebuilt the orthomosaic. This time, it exports properly with a "local coordinates" coordinate system. Thanks for the help!

11
General / Re: Creating coordinate system from a model
« on: November 19, 2018, 08:29:27 PM »
The Python API has a method chunk.exportMarkers(), and also a method chunk.importMarkers(). So those should probably work. But it seems like what you really need is a way to automatically detect the markers in the 2nd model, so that you can automatically align the 2nd model to the 1st one.

Assuming you're not using PhotoScan's auto-detectable markers, it seems like the best thing to do is manually locate the markers in both models, then chunk.exportMarkers() from both, and do whatever analysis you would like to compare the two sets of coordinates.


12
Hi,

I processed some images in PhotoScan without any GPS data: no markers, no GPS info within the images. I was still able to export a nice orthomosaic. I noticed the orthomosaic automatically picked epsg:4978 as the CRS. Does PhotoScan always pick epsg:4978 as the default?

Thanks!

13
General / Re: plane fit orthomosaic
« on: August 22, 2018, 07:20:40 PM »
Yes, that's the idea. Or based on the distribution of the points in the point cloud, for instance. Some external libraries offer plane-fitting for point clouds. The normal vector for that plane could then define the orthomosaic orientation.

14
General / Re: plane fit orthomosaic
« on: August 18, 2018, 01:46:43 AM »
Just to clarify, does the Planar option do an automatic plane fit, or does it require the user to select 3 plane points? I am looking for an automatic plane fit.

15
General / Re: plane fit orthomosaic
« on: July 12, 2018, 08:41:52 PM »
Thanks. I don't know why I didn't consider Planar XY before. That does seem to work!

Pages: [1] 2 3 4