Vertical structure orientation, external reference

[Lia]

Hi,

I am working with a set of images extracted from a video transect along a underwater vertical wall from recorded from the bottom to the top.
The georeferenced positions  of each image were extracted from an external device (USBL). It is relatively accurate and my point and dense cloud are fine.

But the xyz orientation is incorrect. How can adjust the settings to  account for the forward facing setup of the camera (as opposed to the assumed downward facing camera used in aerial photography).

A published papers mentioned that they add a pitch of 90 degrees (However, they used Agisoft PhotoScan  no A Metashape). The only way I found to add pitch was on the imported reference option. So I add a column in the reference table called pitch  with values of 90 per each row. For instance the reference table added had longitude latitude attitude( in my case depth) and the extra column called pitch.

Agisoft Metashape imported all the values for my coordinates but not pitch and the model of the wall shows a horizontal orientation instead of the actual vertical one. What should I do to get XYZ orientation corrected?

Thank you for your time and help.

[JMR]

Not sure if this will solve what you want, but you can select all photos after loading them, and right click on the list, then choose modify, select pitch and enter 90 as you desire.
I dont think your model will come out in the right position after alignment, because I think camera center will rule the final global orientation. So I do not really understand what is causing your model to have incorrect xyz
Can you post a screenshot showing input camera coordinates and resulting 3D view?

Regards,
Geobit&Accupixel

[Lia]

Hi JMR,

 I send attached the default view. Logically I can manually rotate it  (also attached). But, is there a way to modify the initial view. I will use this dense point cloud in another software to derivate terrain variables (rugosity, slope, orientation)  and the rotated exes xyz may not produce the optimal results.

The pictures used came from an ROV, and the coordinates from a USBL (Ultra-short baseline acoustic positioning system)

I applied the 90 pitch in the way that you suggested but the results were the same as the attached scream shots.

Kind regards,

[Paulo]

Hi Lia,

i would look at the extracted positions from your USBL system. In screen capture, the source XY position practically does not change (1 mm) from 1st image to last image.

Certainly something is wrong here....

[Lia]

Hi Paulo

It is impossible to tell that from the screenshot. The number of Frames is 592; It is impossible to see the reference complete in the screenshot. The reconstruction is of a large structure (tens of meters)
 You are observing UTM coordinates and depth (XYZ). Of 14 consecutive images, it is 14 seconds (one image extracted per second from a 30 fps video)


I can confirm that the longitude latitude and depth (xyz) are different. However, I send a screenshot of the ArcMap so you can observe it.

 I will write an additional post after this answer with extra information.

[Paulo]

Hi Lia,

yes I understand that the coordinates from screenshot refer to only first 14 images. But my point is that it is impossible that during first 14 images or seconds that the ROV remained static (less than 1 mm movement) and even if the ROV stood completely still (highly improbable),  the positioning system would not replicate same position during this time lapse as accuracy of USBL must be in the meter range, no?

And if they are UTM coordinates then they must be truncated, no?

Anyway something is fishy here (no pun intended)....

[James]

UTM coordinates should be in degrees shouldn't they? Rather than eastings/northings in meters.

Just a guess but if you translate the Easting 3127.###m and Northing 5220.###m to 31.27°W and 52.20°N it puts you somewhere near the intersection of Charlie Gibbs fracture zone and mid-atlantic ridge.

If that's where you are surveying then it would probably help to use the appropriate coordinate system in metashape.

[Paulo]

James,

That couod be it as 31.27°W and 52.20°N corresponds to 618123 Easting   5784691 Northing in UTM zone 25 N      

However the depth in Gibbs fracture is much geater (-3000 plus   )

[Lia]

Hi everyone,

Thank you to all of you for your comments. I appreciate it.

The change is very subtle because the ROV is moving slow and mostly vertically. So it can be possible to have a few seconds of video where there is no change in latitude and longitude but altitude (vertical movement). I have attached a pdf with the images, and as you can see, the movement mainly was in altitude (depth), and the images are overlapped. 
However, the coordinates labelled as UTM are indeed incorrect. There is very little lateral movement, but there is movement. I will find why those numbers were labelled as UTM_long and UTM_lat.

To solve the problem, I verified that the latitude and longitude in Geographic Coordinate System GCS are correct (see attachment). Then, I uploaded the long and lat  (GCS_WGS84_N25) per each image in Metashape. After that, I used the convert tool in Metashape to obtain the correct UTM coordinates. So far, it worked.

If anyone has any valid objection regarding converting from geographic to projected directly in Metashape, I will appreciate it if you let me know.

Best Regards,

Lia 

[Paulo]

Hi Lia,

that is correct. The point coordinates shown in your screen capture are latitude, longitude with Field3 being latitud in ddmm.mmmm N format, Field4 latitud in decimal degrees, Field5 longitud in ddmm.mmmmm W format and Field6 longitud in decimal degrees.

So importing Fields4 and 6 as lat, long in Metashape and then transform to UTM 25N will get your coordinates in UTM.

In example shown, I imported to Metashape points 819 and 844 in geographic coordinates, then transformed to WGS84 / UTM zone 25N. Between these 2 points, drone travelled about 40 m in XY and 28.6 m in Z(height)...

[2tall3ne]

Paulo is correct, your co-ordinates are in Lat/Long in metashape and not converted to E/N
UTM co-ordinates will not look like that for the zone you are in.