Messages

1

General / Red boundary box in Metashape v2.0 and sequential align question

« on: January 20, 2023, 07:32:41 AM »

Dear Alexey,

I have just tried Metashape v2.0 which is great, but I noticed that in the dense point cloud step, there are two bounding boxes, one in grey line and another in red, what's that red bounding box for?

I also met another special case that the images with "source" alignment will see mismatches in sparse point cloud, which leads lots of holes, though in dense point cloud it fills them, but sequential alignment does not show this impact. I checked that the side overlap is not that sufficient. However, would this be something the "source" alignment should also be able to detected for the feature points?

Thank you!

2

General / Re: Undistort images using the pre-calibration file

« on: September 07, 2022, 04:39:54 PM »

I had a search there's an earlier post about https://www.agisoft.com/forum/index.php?topic=1247.0, though using opencv can also achieve this, it would be great to know if Metashape have this function built already?

3

General / Undistort images using the pre-calibration file

« on: September 07, 2022, 04:15:31 PM »

Hi mates,

As Metashape can load the dewarp parameters from P4R EXIF, is there a way to undistort the images using the pre-calibration loaded in before align?

Thanks!

4

Bug Reports / Re: Wrong output in export point cloud in WGS84 from GDA2020

« on: May 30, 2022, 03:47:37 AM »

Hi Alexey and Paulo,

I figured out what happens and Metashape seems export the GDA2020 correctly. The reason why I see the point cloud shifted in Global mapper is in Global mapper it is default treating GDA2020 needs a NTv2 transform, so when it is loading WGS84/UTM output, in Metashape's metadata, it is toWGS84(0,0,0,0,0,0,0) but in Global mapper, it applied the datum transform!

So this can be ignored now, it's not a bug, thanks, mates.

Cheers,

5

Bug Reports / Re: Wrong output in export point cloud in WGS84 from GDA2020

« on: May 30, 2022, 03:22:22 AM »

Thank you Paulo, yeah I think Metashape adjusted the datum toWGS84 parameters in the chunk correctly as GDA2020 is the new "WGS84" version so should be all 0 transformation, but the point cloud export step is using the old logic that treating the WGS84 is GDA94 so it is adding the 7 parameter datum transform there. I'm not sure from which version it has this bug but at I had a try v1.74 to v1.82 all having this error. Hope this can be fixed as soon as possible.

6

Bug Reports / Wrong output in export point cloud in WGS84 from GDA2020

« on: May 27, 2022, 09:16:47 AM »

Hi Alexey,

I'm using Metashape v1.8 and I found this is a bug in exporting dense point cloud (laz for example) in GDA2020 / MGA to WGS84.

As in Metashape WKT:
'GEOGCS["GDA2020",DATUM["Geocentric Datum of Australia 2020",SPHEROID["GRS 1980",6378137,298.257222101,AUTHORITY["EPSG","7019"]],TOWGS84[0,0,0,0,0,0,0],AUTHORITY["EPSG","1168"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.01745329251994328,AUTHORITY["EPSG","9102"]],AUTHORITY["EPSG","7844"]]'

GDA2020 should be same as WGS84 which makes sense for the moden applications, and it does so when converting in Metashape, but when exporting, the WGS84 or WGS84/UTM zone 55 file will have a shift compared to GDA2020, and it is not the same as GDA94 as well.

Please have a look, thank you!!!

Best,

7

Python and Java API / Re: Question about sensor and camera coordinates from api

« on: June 29, 2021, 05:35:14 PM »

Hi Paul,

Thank you, that makes sense, should this mean the projection matrix then right? From there it could be used to draw the view-matches as it related to the essential matrix. I am looking at some weird case that the GCP marking RMSE is small enough but the DEM is lower than the GCP, probably this is another different question.

Much appreciate for your kind help Paul, legend!

Best,
Phogi

8

Python and Java API / Re: Question about sensor and camera coordinates from api

« on: June 28, 2021, 04:12:24 PM »

Hi Paul,

Thank you for the explains, I have another question regarding the camera transformation matrix, so if I know the photo's precise geolocation, which should be the translation of camera matrix relative to the world coordinate system. How will that represent in Metashape's coordinate system? It seems the CTinv * Tinv should refer to the world to internal coordinates but it does not link with the photo's geolocation though. Should I consider camera.center as the internal coordinates related to the geocentric of image GPS?

Thank you!

Best,
Phogi

9

Python and Java API / Re: Question about sensor and camera coordinates from api

« on: June 16, 2021, 08:13:33 AM »

Hi Paul,

Wow that's fantastic examples!! Thank you, it is the most detailed example I ever seen! Huge thanks!

 

Best,
Phogi

10

Python and Java API / Re: Question about sensor and camera coordinates from api

« on: June 15, 2021, 09:07:12 AM »

Hi Paul,

Thank you so much, I actually found that the marker position I used was wrong! In GUI GCP002 is the first marker but then in the chunk.markers it is the third, so I was using another marker position that's why it was off a lot!

May I ask if you know how can we get the projection matrix? As camera.project() can project world coordinates into image coordinates, from my understanding the marker.position it should be meaning the u,v,w coordinates, but it can't directly change from homogenious coordinates by divide the w, so I'm confusing about which internal coordinate system does this marker.position actually refer to?

Thanks a lot!

Phogi

11

Python and Java API / Re: Question about sensor and camera coordinates from api

« on: June 11, 2021, 10:40:22 AM »

Hi Paul,

Thank you! That explains very clear about the difference. But for the image pixels it does not look like from top-left (as attached image) but more like from bottum left?

Could you explain a bit more, camera.transform.inv().mulp(marker.position) which coordinate system does marker.position and the transformed result are in? As chunk.transform.matrix.inv().mulp(chunk.crs.unproject(marker.reference.location)) from my understanding is to transform marker's world coordinates to camera coordiante system, but I tried to use x/z to calculate the pixels it does differently, so I'm not sure what's the procedure of camera.project is doing...

Thank you!
Phogi

12

Python and Java API / Question about sensor and camera coordinates from api

« on: June 10, 2021, 03:17:52 PM »

Hi everyone,

I searched on the forum and found there are two ways to reproject 3D points into 2D image pixels, one is from sensor.calibration, the other is from camera.project. What is the difference between them? Furthermore how does the pixels count, from topleft corner or they've been shifted from center + cx/cy?

Could anyone help with how does camera.project works? The reason is I want to check why some markers are having higher pixel errors when they do align fine, if there's anything abnormal in the camera matrix or projection matrix, but how can I retrieve this info?

Thanks in advance!

13

Python and Java API / Re: Key point limit from chunk.point_cloud.meta is different to GUI

« on: April 30, 2021, 02:35:43 AM »

Hello Alexey,

Yeah that might be the issue, I found it was duplicating the chunk and saw this on the second chunk's meta! Was this info accumulating the chunks info?

Thanks!

14

Python and Java API / Key point limit from chunk.point_cloud.meta is different to GUI

« on: April 29, 2021, 10:38:40 AM »

Hi Alexey,

I am looking at the chunk.point_cloud.meta and saw the key point limit is 80,000 while in GUI I was specifying as 40,000, and the MatchPhotos/tiepoint_limit is also doubled from API, is that an expected result?

My other question is could you share for camera's projection matrix and this point_cloud.cov, do they have relationship with each other?

I'm on v1.60 build 9617 by the way.

Much appreciate for your help, thank you!

Best,

15

General / Re: Is there a way to put mask from sparse point cloud to image?

« on: October 22, 2020, 01:40:22 AM »

Hi Jose,

Thanks for your kind suggestions, though I was trying to speed up with higher density point cloud reconstruction time, but your suggestions offered a good new path on how to merge the data.

I did try the mask from mesh and it is interestingly taking longer in processing. Directly running high density I'd get 63mins in all dense reconstruction time, while with the mask for AOI, the time is 72 mins, I think this is due to the cropping procedure and the whole surface was still created.

So to speed up the solution currently is still to have more powerful machine then I guess.

Thanks a lot!
Best