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.


Topics - Phogi

Pages: [1] 2 3
1
General / "Unsupported depth images format" error when import depth map
« on: December 07, 2023, 09:20:23 AM »
Hi,

I'm trying the Metashape 2.0 with the import depth map function from mobile data, according to some threads and this article: https://agisoft.freshdesk.com/support/solutions/articles/31000162212-smart-cameras-with-depth-sensor-data-processing#:~:text=Starting%20from%20Metashape%20Professional%202.0,depth%20sensor%20or%20similar%20devices. it should be working, but it doesn't.

I did try one image and the log has some weird info showed:

2023-12-07 17:17:09 ImportDepthImages: filenames = C:/Users/Downloads/test/Image_000565.jpg, image_path = C:/Users/Downloads/test/{filename}_{filenum}.tif
2023-12-07 17:17:09 Importing depth images...
2023-12-07 17:17:09 Embedded depth data is not found for the photo C:/Users/Downloads/test/Image_000565.jpg
2023-12-07 17:17:09 Finished processing in 0.021 sec (exit code 1)
2023-12-07 17:17:11 Finished processing in 0.001 sec (exit code 1)
2023-12-07 17:17:11 lm optimize: xxx--------------------------- 8.69652e-05 -> 6.37154e-14
2023-12-07 17:17:11 Calibration initialized, mean error = 9.01071e-14 pix, max error = 5.08423e-13 pix

The RGB image was Image_000565.jpg, while the depth map image is Image_000565.tif.

The image dimensions is different but the aspect ratio is the same. Can you help if anything I'm wrong?

Thank you!

2
Hi Agisoft,

I'm trying to convert a project from EPSG: 4283 to EPSG: 3577, it is getting a wrong coordinates, which is inverting the latitude from -12 degrees to 12 degrees.

Can you check it?

Thank you very much!

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

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

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

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


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

8
General / Is there a way to put mask from sparse point cloud to image?
« on: October 06, 2020, 02:24:53 AM »
Hi Alexey,

Is there a way to draw mask for selected area from sparse point cloud / ortho to the photos, rather than draw mask each image with same mask? What I want to do is creating point cloud with very high desnity in some AOI, is that possible? Or is it possible to create point cloud with high density in some part and lower in not interested part to speed up?

Thank you!

9
Bug Reports / Possibly Wrong conversion in EPSG 5513
« on: August 25, 2020, 02:55:25 AM »
Hi Alexey,

I found some post before regarding EPSG 5513 / 5514 support, which is great, however when I am converting GCPs from WGS84 to EPSG:5513 and 5514 they show different sign (positive vs negative), but in EPSG.io they are the same: https://epsg.io/transform#s_srs=5513&t_srs=5514&x=-527358.6200000&y=-1140103.1800000

Which one is correct? By checking the proj4 string definition they are exactly the same in Metashape, so why there's a different sign for output? I know there's SW vs NE axis but not sure which source is correct.

Hope to hear from you soon.

Best,

10
General / Understanding confidence map of dense point cloud
« on: March 10, 2020, 06:41:52 AM »
Hi Friends,

Can anyone provide some info about the confidence map of Dense Point cloud? With the 0 to 255 level it works well with removing some noise, but I saw a weird image and interested to know how this confidence map related with image overlap, and how it is calculated for that pattern.

Best,

11
Bug Reports / proj4 definition not match with WKT EPSG 2056
« on: March 10, 2020, 06:07:22 AM »
Hello Alexey,

I found the EPSG: 2056 in Metashape returned different proj string to the WKT:
Proj4:

'+proj=omerc +lat_0=46.95240555555561 +lonc=7.439583333333329 +alpha=90 +gamma=90 +k_0=1 +x_0=2600000 +y_0=1200000 +ellps=bessel +units=m

WKT:
'PROJCS["CH1903+ / LV95",GEOGCS["CH1903+",DATUM["CH1903+",SPHEROID["Bessel 1841",6377397.155,299.1528128,AUTHORITY["EPSG","7004"]],TOWGS84[674.374,15.056,405.346,0,0,0,0],AUTHORITY["EPSG","6150"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.01745329251994328,AUTHORITY["EPSG","9102"]],AUTHORITY["EPSG","4150"]],PROJECTION["Oblique_Mercator",AUTHORITY["EPSG","9815"]],PARAMETER["latitude_of_center",46.95240555555561],PARAMETER["longitude_of_center",7.439583333333329],PARAMETER["azimuth",90],PARAMETER["recitified_grid_angle",90],PARAMETER["scale_factor",1],PARAMETER["false_easting",2600000],PARAMETER["false_northing",1200000],UNIT["metre",1,AUTHORITY["EPSG","9001"]],AUTHORITY["EPSG","2056"]]'

From http://epsg.io/2056 the projection in proj4 should be +proj=somerc rather than +proj=omerc. It's interesting that the conversion is correct, so I assume the conversion is not using proj4 string is it?

Thanks

12
Bug Reports / Different WKT definition to EPSG.io
« on: December 03, 2019, 05:28:32 AM »
Hello support,

I find that NAD83(CSRS) / BC Alberts EPSG:3153 in Agisoft has different WKT definition to http://epsg.io/3153.

In Metashape the toWGS84 defined as TOWGS84[-0.991,1.9072,0.5129,0.025789907519493,0.009650098960270401,0.011659943232342,0],

while in EPSG.io it is [0,0,0,0,0,0,0].

Is this a bug or different database for Agisoft referred to?

Thanks!

13
Hello everyone,

I have tried two different ways to project marker to the image plane, and I searched in the forum to find two ways:
(1)
marker = chunk.markers[0]
x0, y0 = marker.projections[camera].coord

(2)
camera.project(chunk.markers[0].position)

Method (1) returns Vector([2046.1069456339237, 1142.9500712869672]), while method 2 returns (2046.3900146484375, 1143.6800537109375).

Since both starts from estimated values, I am expecting they are the same, but they are different. Could someone explain why there's difference? Or if I should compare the integer but the Y has about 1 pixel difference...

Thanks a lot!

14
General / shift point clouds and all outputs
« on: December 02, 2019, 07:16:51 AM »
Dear support,

Is there any method to apply extra shift to the dense point cloud, and the following outputs continuing to work based on this shifted point cloud?

I found some thread mentioned to try project ortho photos to reloaded dense point cloud from external resource, is this possible to do so now?

Thanks!

15
Python and Java API / Help in localframe explain
« on: November 22, 2019, 06:48:04 AM »
Hi everyone,

Could anyone give some hints about the chunk.crs.localframe() matrix?
Hello claranine,

Code: [Select]
sourceGeogr = camera.reference.location #source values in geographic coordinate system
estGeogr = chunk.crs.project(chunk.transform.matrix.mulp(camera.center)) #estimated position in geographic coordinate system

sourceGeoc = chunk.crs.unproject(camera.reference.location) #measured values in geocentric coordinates
estimGeoc = chunk.transform.matrix.mulp(camera.center) #estimated coordinates in geocentric coordinates
local = chunk.crs.localframe(chunk.transform.matrix.mulp(camera.center)) #local LSE coordinates
error = local.mulv(estim - source)

As in this post why the error needs to use local.mulv to transform rather than directly use (estim - source)? Is this due to unit difference?

Thanks in advance!

Pages: [1] 2 3