Messages

16

General / Re: DEM accuracy vs ORTHOMOSAIC accuracy

« on: December 03, 2018, 09:15:25 PM »

Just to be sure, are you referring to accuracy or resolution? Looking at your text I reckon the latter.

The maximum allowable/highest resolution of your DEM depends on the Quality Parameter set during construction of the Dense Cloud. When the GSD of inputted images is 5cm the maximum allowable resolution for the DEM is as follows with respect to the quality parameter for the dense cloud step:

Ultra high  = 1 * 5.0 = DEM resolution of 5 cm
High          = 2 * 5.0 = DEM resolution of 10 cm
Medium    = 4 * 5.0 = DEM resolution of 20 cm
Low          = 8 * 5.0 = DEM resolution of 40 cm
Lowest     = 16 * 5.0 = DEM resolution of 80 cm

So in other words you will only be able to achieve the same DEM resolution as your image/orthomosaic GSD if you set this to Ultra High. Considering you only get 20cm I assume you generated your Dense Cloud at medium quality, correct?

17

General / Re: Serious problem with DEM and GIS software

« on: December 03, 2018, 01:32:01 PM »

Yes,
I chose "palette"
See the attached screenshot ....
....
If I don't chose "palette" what parameter I have to set in the field marked in the screenshot?

Just set it to None for Raster Transform and leave the default value (-32767) for No-Data value untouched.

18

General / Re: Serious problem with DEM and GIS software

« on: December 03, 2018, 12:27:17 PM »

I just downloaded your DEM and found the same issue as you described when loading this into QGIS. Looking at the attributes it appears as if the DEM was exported like a 4-band orthomosaic rather than an elevation model.

Could you perhaps post a screenshot of your export-DEM settings? I'm thinking you may have set the parameter 'Raster transform' to Palette, as this will produce a 4-band DEM. This should be set to None instead.

19

General / Re: Agisoft Metashape 1.5.0 pre-release

« on: November 30, 2018, 09:58:44 AM »

Hello Alexey,

in this case, please see my post as a feature request!

Maybe you want to remove parking cars, trees and bushes or some containers, before calculating the volume. If i do this with a mesh, i have to create one first, then delete all the unwanted objects and in the last step, i have to close the holes again, before being able to calculate the volume.

Using vector shapes, this would be much easier and faster!

Best regards
Thomas

Have you considered classifying the dense cloud prior to generation of a DEM/Mesh? You can either classify the densecloud manually by means of extracting desired points using polygon drawing and subsequently reclassifying the said selection to a desired non-ground class. Alternatively you can play around with the Automatic Classification parameters found under Tools and let the software come up with a reclassified pointcloud with respect to ground and non-ground points.

Once you're happy with the resultant classification you can follow-up with generating of the DEM or Mesh. In the settings screen for both you can define Dense Cloud as a source surface, besides allowing you to define the pointcloud classes on which you would like to products to be generated. When only activating the Ground class you should end up with a DEM/Mesh that closely approximates the actual ground surface of the terrain, provided your classification was done correctly.

20

General / Re: DJI Phantom 4 RTK

« on: November 29, 2018, 08:04:33 PM »

Is there anyone who has made some actual tests of the newest Phantom RTK? I agree that always we need to check the accuracy on some checkpoints, but without GCPs, what accuracy can be expected? I don't believe in 1-2cm stated by DJI, but is it closer to 15cm or 50cm? Can anyone share some processing reports?
Cheers

We're currently at 3-5cm XY and 5-10cm vertically, without using a single GCP. Accuracy was validated using 19 independent Checkpoints surveyed by RTK-GPS.

That being said the workflow is still not optimal, we've also not yet tried working with the camera calibration parameters provided by DJI. Hence we're expecting results to improve even more. So far it's quiet impressive what we're seeing.

Ps. The flight was conducted at 70m AGL and 75/75 overlap. Missiontype in the GS RTK app was set to 3D Photogrammetry, resulting in a crossgrid pattern with the camera at 60 degrees. We also did a simple 2D (single grid) mission which, although indicating similar horizontal accuracies, showed significantly reduced vertical accuracy.

21

General / Re: Workflow to process the Photography of "PHANTOM 4 RTK"

« on: November 28, 2018, 11:17:41 PM »

Hi,

yes I think you are right, the last 5 correspond to k1,k2,k3 and p1, p2 distorsion parameters... the 3rd and 4 th parameters seem to correspond to Principal point position in pixels. In screen capture, I show calibration done on P4RTK set corresponding to first example. In this case no dewarp parameters were applied and camera exhibits high radial distorsion… In this calibration, I have also a r4 radial parameter estimated....The first 2 parameters are more difficult to explain, they seem to correspond to something like focal length in pixels ( 2 values for affinity^?) but are far from 3663 value estimated in PS.... DJI should give more information on this especially since it puts in EXIF calibrated focal and PP at:
Calibrated Focal Length         : 3666.666504
Calibrated Optical Center X     : 2736.000000
Calibrated Optical Center Y     : 1824.000000

High Paulo,

Not exactly sure what you mean but do you mean that you processed your data letting Photoscan estimate/optimize all camera parameters, OR did you import the values provided by DJI as fixed parameters?

In the meantime I've received official word from DJI on the meaning of the nine consecutive values in the DeWarpData field:

Code: [Select]

calibrate_date;fx,fy,cx,cy,k1,k2,p1,p2,k3
Where fx;fy is the focal length in the pixe and where cx;cy is the optical center expressed in pixel coordinate (Origin point as the center of the imager).

Now that leaves me wondering what settings we should use in Photoscan's camera calibration dialog as there's only one field for focal length, whereas the XMP metadata provides us with two (horizontally and vertically). I also reckon we should go via the Convert Calibration setting (within the Camera Calibration pane) and change the value in the Type-field, which is set to Photomodeller by default, to Pix4D Perspective. This would be due to Photomodeller expressing both focal length and principal points in millimeters (mm), whereas the P4RTK's XMP metadata expresses these values in pixel (pix) units and this is allowed when changing the Type-field within Convert Calibration to Pix4D Perspective.

Again I'm not sure and still guessing on some details, it'd be great of some of the developers could tune in to this!

22

General / Re: Workflow to process the Photography of "PHANTOM 4 RTK"

« on: November 28, 2018, 10:19:32 AM »

Is anyone, perhaps, capable of clarifying the values encircled in green in the attachment? It depicts three seperate metadata/XMP files extracted from three different Phantom 4 RTK's.

The values in blue most certainly relate to the various interior parameters that were distilled during the a priory camera calibration procedure seemingly conducted by DJI. The latter five likely embody radial (k1-k3) and tangential (p1-p2) coefficients, but I'm not entirely sure. The same goes for the first series of values; they may be related to the focal length or principal point coordinates (cy, cy), but they seem to be expressed in a different unit compared to how they ought to be inputted in Photoscan's camera calibration dialog. As I'm eager to import these parameters as fixed I really need to know what the values exactly represent, any help is much appreciated!

Ps. The middle example doesn't contain any camera calibration parameters. This was likely due to the option 'Distortion Correction' being activated in the DJI app which causes the calibration parameters to be omitted.

23

General / Re: Workflow to process the Photography of "PHANTOM 4 RTK"

« on: November 20, 2018, 12:05:14 AM »

In the latest pre-release of the version 1.5.0 (build 7205) we have added the support for the GPS accuracy tags load from XMP meta data to the Reference pane (corresponding flag should be enabled in the Advanced preferences tab).

That's absolutely great to hear, superb and quick handling by the dev team! Will it also be able to handle/import the camera calibration data?

More importantly however, at least for us, when will users of Agisoft Photogrammetric Kit be able to utilize this functionality? We have already been waiting for the first build of Metashape for over six weeks, let alone how much longer build 7205 will take..

24

General / Re: Workflow to process the Photography of "PHANTOM 4 RTK"

« on: November 15, 2018, 11:51:27 AM »

Following this as we may be getting a demo model soon and we are eager to learn more about the exact processing methodology in Photoscan!

25

General / Re: Agisoft Metashape 1.5.0 pre-release

« on: October 08, 2018, 03:28:59 PM »

Any additional information on the Cloud Processing functionality?

Will this be a 'free' feature available to those possessing a Professional License or will it be paid add-on? Besides what are the anticipated advantages for user's to process in the cloud? Is it expected to shorten processing time or only for those user's that are running a low-end system locally themselves? How will it compare to processing locally using a medium to high-end workstation, will it still be faster then?

Also, what about user control over the processing workflow? Does one remain fully in control of all processing steps and subsequent parameters or is all of the processing done autonomously by the system itself based on default pre-defined settings?

26

General / Re: Export DEM (.TIF) for importing in Civil 3D

« on: August 10, 2018, 04:26:59 PM »

Hello BobvdMeij,

Maybe you can export DEM in lower resolution and re-save it in QGIS? Then send both files to us to support@agisoft.com.

You've got mail!

27

General / Re: Export DEM (.TIF) for importing in Civil 3D

« on: August 10, 2018, 03:42:37 PM »

Hello BobvdMeij,

Is there any difference in raster header between PhotoScan-exported and QGIS re-saved DEM?

Any suggestions to extract the raster header?

I tried to import the QGIS-DEM into 'GeoTiffExamine' but the file is too big as the program runs out of memory.

Its also worth mentioning that the Photoscan-DEM (exported without the WorldFile) is 'not understood' by the program. The Photoscan-DEM (exported with the WorldFile) is imported succesfully into the GeoTiffExamine software.

28

General / Filtering Ground Points on sloped surfaces

« on: August 10, 2018, 12:06:25 PM »

How does one go about filtering non-ground points on sloped surfaces, such as small lumps of vegetation on water barriers (dikes)? The Classify Ground Points-tool works quiet okay on horizontal surfaces, but its methodology seems to fail when surfaces are increasingly angled.

Which makes sense as the tool supposedly splits the pointcloud into cells of a user-defined size, followed by detecting the lowest point in each of these cells to arrive at an approximated DTM. Consequently all other points within each cell are validated with respect to meeting or exceeding the user-specified values for distance and angle (relative to the approximated DTM).

The first of the above two steps, however, becomes flawed when the surface represents a slope. The lowest detected point will always lie downwards of the slope within each cell. This point can be far from representing ground level. In fact it may even represent vegetation if the upward section of the surface within the cell is situated higher, athough being bare soil.

I have literally ran countless iterations, each time varying one or more of the three user-defined criteria. I have tried cell sizes between 0.1m and 20m, angles between 2 deg. and 40 deg. and distance-values as low as 0.01m or as high as 1m. Strangely enough, the output is hardly any different no matter what I try. Furthermore, lumps of vegetation that are easily discernible as non-ground by the naked eye are still classified as ground point regardless of the parameters set.

Attached is a screendump of the pointcloud displaying a subsection of the water barrier, please note how some sections of the vegetated cover clearly stand out from the surrounding area. This contrast is particularly well discernible when the pointcloud is visualized by lasses as this enhances shaded relief. As you can see, however, the far majority of the clearly outstanding vegetation is still classified as ground (brown color), and NOT as non-ground points (white).

29

General / Re: Export DEM (.TIF) for importing in Civil 3D

« on: August 10, 2018, 09:32:34 AM »

Hi friend,
I think that MAPIINSERT works only for georeferenced raster images. DEM files are also tiffs but have elevation information in them. I think you can import DEM files in Civil 3D but with different command. Check Civil 3D's manual or autodesk forums.
EDIT: Check https://knowledge.autodesk.com/support/civil-3d/learn-explore/caas/CloudHelp/cloudhelp/2016/ENU/Civil3D-UserGuide/files/GUID-5E670EBA-4898-4CEB-A619-EE0F89E416E6-htm.html

I have your suggestion a try but, unfortunately, the DEM file is still considered invalid and cannot be imported.

In the meantime we have succesfully imported a DEM file by importing it into QGIS and then exporting the same DEM to a new .TIF file. Unfortunately, however, because this re-exporting through QGIS turns a reasonably sized 300mb file into a mega 2GB+ file, the DEM is barely usable in C3D.

30

General / Your opinion on USGS Agisoft Processing Workflow

« on: August 06, 2018, 01:40:18 PM »

Dear all,

While randomly scouting across the internet in search of clarifications on certain terminology used in Agisoft I came across this (also see the attachment below) seemingly well structured Agisoft Photoscan Workflow formulated by USGS (United States Geological Survey) in March 2017. USGS being a globally renowed organization I like to believe considerable thought and extensive testing and validation led to this document.

I personally very much like the column named ‘Function’, which supposedly describes what each step does and how it affects the output. Especially because such information is often lacking in the rather technical and somewhat limited explanation provided in Agisoft’s official user manual. This is particularly valid for the various and seemingly important Gradual Selection stages. I believe this ranks among the most frequently discussed themes on this forum, although a comprehensive/ understandable explanation of what it exactly does and how it should be applied is still missing.

I'm eager to learn what you all think of this USGS workflow, how it relates to your own and if you could perhaps comment on why certain steps are executed in this order using particular settings. I’m particularly intrigued by the presented order of the Marking of GCPs, Camera Optimization and the subsequent Optimization Parameters.

I personally always use the following methodology:

1.   Align Photos
2.   Mark Ground Control and Checkpoints
3.   Optimize Camera’s (checking all parameters except p3 and p4)
4.   Gradual Selection Reprojection Error at 0.5 > delete points > Optimize Camera’s (check allexcept p3/p4)
5.   Gradual Selection Reconstruction Uncertainty at 10 > delete points > Optimize Camera’s (check all except p3/p4)
6.   Gradual Selection Projection Accuracy at 2-3 > delete points > Optimize Camera’s (check all except p3/p4)
7.   Dense Cloud > DEM > Orthomosaic

The USGS workflow, however, employs a much more complex procedure. Rather than running ALL Gradual Selection stages AFTER marking the GCPs (as done by me), the USGS workflow applies Reconstruction Uncertainty and Projection Accuracy BEFORE any GCPs are marked. Only the Reprojection Error step is executed AFTER GCPs are included. Also note that the USGS workflow suggests to change the Tie Point Accuracy setting within the Reference Settings from 1.0 to 0.1 along the way. The workflow furthermore suggests to check/uncheck different Camera Parameters for distinct Gradual Selection stages, rather than keeping this the same across the board as is done by me (and I believe by many others). 

Again, the workflow seems to be thought out well but I still cannot wrap my head around certain details. I’m hoping some of you, and Agisoft’s developers in particular, are able to reflect on the matter!

Thanks in advance.

Bob