Messages

1

General / Re: Error: Vertical datum missing

« on: February 24, 2021, 01:20:54 PM »

Hey Paulo,


Thanks yet again! 


Yes, I'm aware of the structure of the EXIF tags within the TIFF file the issue is that I need to know (exactly) what to write in to the tags and I'm not really sure where to get that information furthermore I'm not particularly comfortable using  EXIFTOOL from Phil Harvey so by now I have been using "my" geoids without issues, only when I changed from computer problems arised due to the different paths.


In fact my geoids are very small, they only cover Catalunya so maybe if I post them here in the forums someone can help me and add the tags. 

2

General / Re: Error: Vertical datum missing

« on: February 24, 2021, 12:54:07 AM »

Hi Paulo,


First of all I would like to take the time to thank you for your effort in responding to my post.


While I do agree with you on that geoids should be generally stored in the geoids folder within Metashape's folder I did not did so because I created those geoid undulation files and they are not fully compliant with Agisoft standard (I suspect the EXIF tag that describes the EPSG code / description is missing) which meant that every time I started Metashape I got an error, which was annoying.


In any case my original question stands, is there a way to to solve my current situation? I do need to specify a new geoid path within the existing Metashape project, would that be possible?


Many thanks in advance!


Isaac

3

General / Error: Vertical datum missing

« on: February 23, 2021, 12:14:07 PM »

Hello Everyone,

I'm stuck with a project that I did on a computer that had a vertical datum defined, this datum was based on a non public geoid file that was stored on a given path that I don't remember.

Now I'm on a different computer and I don't have that same vertical datum installed on the same path as in the original computer and when I open the MetaShape project I get lot's of:
Error: Vertical datum missing


And among other issues I'm unable to see coordinates (lower right corner), I'm unable to see camera positions on the Ortho pane, ...
I do have the geoid file but I would like to specify a different path, would that be possible? If so, how?

I'm working in MetaShape professional 1.7.0

Thanks

Isaac

4

General / 3Dconnexion SpaceMouse Wireless in Metashape professional 1.5.5 build 9087 64bit

« on: November 19, 2019, 04:59:38 PM »

Hello Alexey,


Good evening, I'm in the process of setting up and getting used to a 3Dconnexion SpaceMouse Wireless (running latest released drivers) to be used in Metashape professional 1.5.5 build 9087 64bit.

As can be seen in the attached screenshot I have configured the SpaceMouse within Metashape to my taste, however when I tilt (not move) the controller forward or backward I'm getting a mixed camera movement consisting of the expected displacement of the camera upward or downward but it also a zoom in/out. Note that I'm being careful not to mix different axis inputs simultaneously when operating the SpaceMouse.

I believe this mixed displacement + zoom is happening because when the SpaceMouse is used in other applications like a web browser or a text editor, tilting the controller up or down causes the same effect that a mouse wheel would have on the scroll bar (moving up or down the body of the text/page) and this is not disabled within Metashape.

Would it be possible to provide a fix for this unwanted behavior?

Further to my previous input I would like to point out that the current implementation of the SpaceMouse within Metashape is very limiting when compared to the options offered by the manufacturer drivers. For instance, I would like to see an option to switch from model movement (which I believe that is how Metashape is currently working) to camera movement (the controller input is similar to how an helicopter controls would work).
Is there any chance to implement SpaceMouse devices so that the configurations in the manufacturer setup/control panel are not ignored within Metashape (in that case Metashape controller setting would have to be eliminated to avoid conflicting redundancy), like they are currently are?

Best regards

Isaac

5

General / Re: Extrange behaviour when exporting a Dense Cloud to LAS

« on: October 16, 2019, 03:14:52 PM »

Hello Alexey,


Many thanks for your help! I seem to have found what was causing this behavior.


The reduction of points in the exported point cloud was caused because I had an "outer boundary" drawn in the DEM / Orthomosaic view which caused the exported cloud to be trimed to the extent of my area of interest.


Many thanks once more and sorry for the inconvenience.


Isaac

6

General / Re: Extrange behaviour when exporting a Dense Cloud to LAS

« on: October 15, 2019, 08:12:20 PM »

Hello Alexey,

Yes, you are correct, the Metashape point count that I'm referring to is the number that appears in the bottom left corner of the Model window or the number right besides the Dense Cloud in the Workspace pane.

No, using Update Dense Cloud option from Workspace pane context menu does not help, after running it the point count in the Workspace pane does not change, still is 327 821 323

Yes, the dense point cloud that I'm working with was generated with Metashape 1.5.5.9097

Please don't ask me to share the dataset, due confidentiality reasons I can't do that.

Best regards

Isaac

7

General / Extrange behaviour when exporting a Dense Cloud to LAS

« on: October 14, 2019, 03:19:16 PM »

Hi All,

I'm wandering if someone else has seen this behavior when exporting a dense cloud to LAS file format...

I have a dense cloud within a Metashape Pro v. 1.5.5.9097 containing 327 821 323 points that has been created from a normal photogrammetric workflow, in other words it's not imported in to the project from external sources...

When I export the after mentioned point cloud I end up with a LAS containing 184 445 978 points even though I have not decimatied the cloud. Because the results where estrange to me I decided to doublecheck the point count with two different softwares, CloudCompare and Quick Terrain Reader and they both agreed.

Then I have tried to export other Metashape point clouds and the result seems to be consistent, my exported LAS files contain less points than my original Metashape cloud, is this the intended behavior?

Best regards

Isaac

8

General / Re: Volumes on tilted grounds where it is not possible to position ground vertices.

« on: October 11, 2019, 07:34:59 PM »

Hi SAV,

As usual, very useful responses!

To achieve what I wanted to do I believe I would have to purchase a subscription plan to "Virtual Surveyor" web based software which is far from my preferences in regards on how I like to pay for software so I prefer to wait until Metashape provides a method to compute that kind of volumes (to me it looks like most of the required elements are already there because I can draw the reference plane where I wanted to be and tilted like I needed it to be...)

Many thanks 

Isaac

Many thanks for the effort SAV

9

General / Volumes on tilted grounds where it is not possible to position ground vertices.

« on: October 09, 2019, 06:28:13 PM »

Hello,

Let's say I want to measure the volume of a stockpile sitting on a sloped terrain and half surrounded by a vertical wall like the one shown in the following image:



To do so I have drawn a rectangular polygon covering the road "faltish" surface, then I set the drawing plane to the rectangular polygon and last I created a new polygon that surrounds the stockpile in an Ortographic view (like the one shown on the screenshot).

If I click on "Measure" option in the "Model" view for the polygon surrounding the stockpile I get a list of 3D coordinates where the height of each vertex is within the 3D reference plane which is what I want however If I go to the DEM or Orthomosaic views the height of each vertex of the polygon are projected in to the stockpile surface which means that if I use a "best fit" plane as means to compute the volume I will get a wrong result.

In summary, would it be possible to implement a way to measure volumes sitting on tilted grounds and (partially) surrounded by walls?

If I missed the way to do it please excuse me.

Best regards

Isaac

10

General / Re: Using a LIDAR dataset from an ofitial source to georeference a Metashape project

« on: October 07, 2019, 03:13:01 PM »

Hi SAV,

Outstanding, I have to admit that your responses are tempting but unfortunately right now I don't have the time to dive in to Python programming.

Your help is very much appreciated!

Isaac

11

General / Re: Using a LIDAR dataset from an ofitial source to georeference a Metashape project

« on: September 30, 2019, 05:20:13 PM »

Hi SAV,

Many thanks for your elaboration, the steeps of the two methods you proposed are very clearly outlined!

Being said that, Method B (Cloud Compare) is not really suitable for me because my intention is to georeference the whole Metashape project and I believe, please correct me if I'm wrong, that If I reimport in to Metashape the point cloud from Cloud compare the project (sparse cloud and other products) would still be missgeoreferenced.

Method A seems to be more suitable to my interests unfortunately I can't really see much detail in the official LAS because it's 1 point for every 2 meters which is very little compared to the Metashape project which is  218 points per square meter.

This is why I was hopping for a least squares method that would be able to use the whole surface area of the project taking in to consideration that the Metashape project just suffers from GNSS positioning errors.

In any case many thanks for your help!

Best regards

Isaac

PS: SAV, shall I understand that you are working with Agisoft?

PS: Shall I understand d

12

General / Using a LIDAR dataset from an ofitial source to georeference a Metashape project

« on: September 27, 2019, 03:49:13 PM »

Hello,


Dos any one know if I can use a LAS dataset sampled at 0.5 points per meter from an official source to georeference a successful Metashape project that does not have GCPs nor acurate external orientation parameters.


If that is possible, would you mind to outline the process?


Many thanks


Isaac

13

Bug Reports / File / Export / Export Panorama... image aspect ratio is slightly wrong

« on: August 13, 2019, 10:45:51 AM »

Hello Alexey,

During the creation of a panorama I used 26 pictures of 5472 x 3648 pixels automatically taken by a Mavic 2 Pro drone. The end result was a mosaic with dimensions 27131 x 13566.

The aftermentioned mosaic aspect ratio was 1.99993 instead of 2.0

To obtain the expected aspect ratio of 2.0 the width of the mosaic should have been

27132 instead of 27131

[/size][/font]

[/size][/font]

Thanks

[/size][/font]

[/size][/font]

Isaac

[/t][/t][/t]

[/td][/tr][/table]

14

General / Re: 16 bit Orthomosaic to GoogleEarth KMZ

« on: August 08, 2019, 05:59:17 PM »

Hello Alexey,


You proved me wrong and I thank you for that! 

15

General / Re: 16 bit Orthomosaic to GoogleEarth KMZ

« on: August 08, 2019, 05:23:28 PM »

Hello Alexey,

Please correcte if I'm wrong but the approach you are proposing in your previous post would output a false colour single band image, any chance to output a RGB color image?

Many thanks

Isaac