Messages

46

General / Re: Altitude used in Processing UAV (DJI Phantom 4 Pro)

« on: April 27, 2018, 09:28:05 AM »

Hi jazzyj,

The rule of thumb that you mention (vertical accuracy is around 3 times GSD) is only valid if accurately surveyed GCPs have been used (!!). If not, then the error is much higher (even larger than your estimate of 5 times GSD), due to shortcomings in the self-calibration of your camera.

Interesting fact: James et al (2014) pointed out that the additional collection of oblique imagery instead of nadir only (convergent imaging geometries) is able to reduce the error in self-calibrating image networks where the interior orientation parameters are acquired during processing (bundle adjustment). This means that accuracy is also influenced by camera orientation.

I don't doubt what you assert is true.  Maybe the information so widely spread then is assuming oblique imagery is also used but of course most of the information lacks specific details.  It may be the case of many information sources regurgitating flawed assertations.

https://blog.dronedeploy.com/accuracy-in-drone-mapping-what-you-need-to-know-10322d8512bb

"Relative accuracy: Is typically a multiple of your data’s average Ground Sampling Distance (GSD). The horizontal relative accuracy is 2x GSD (for example, if your GSD is 2 cm/pixel, the horizontal accuracy will be approximately 4 cm) and the vertical relative accuracy is typically 3x GSD."

https://support.skycatch.com/hc/en-us/articles/219500068-What-s-the-Z-Accuracy-of-Data-Captured-with-Skycatch-Flight-App-

"The expected accuracy for the Z coordinate is 3x GSD vertically.

The rule of thumb for transferring from GSD to Z accuracy is multiplying the GSD value by 1.5 - 3."

https://support.pix4d.com/hc/en-us/articles/202558889-Accuracy-of-Pix4Dmapper-Outputs

"Generally, one can expect an error of 1-3 times the Ground Sampling Distance (GSD) of the original images for the relative position of a point in a project that is correctly scaled and reconstructed."

https://github.com/gtoonstra/project-ion/wiki/How-to-guarantee-the-quality-of-survey-data

"You should nowadays be able to achieve about 1x GSD RMSE in your model. So if you have 2cm / pixel, your model error shouldn't be larger than 2cm horizontally. Vertically it's about 3x GSD."

http://www.mowastecoalition.org/resources/Documents/2016%20conference/Tukuh-Blackstone.pdf

"Relative 3D model accuracy – 1 to 3x GSD"

https://www.fsbpa.com/17AnnualConfPresentations/Sasso-Witkowski.pdf

"Horizontal Accuracies based on 2x the GSD while your Vertical Accuracy near 3x GSD."


And on and on...

47

General / Re: Altitude used in Processing UAV (DJI Phantom 4 Pro)

« on: April 26, 2018, 07:56:22 PM »

Hi jazzyj,

We did a survey using a P4P and a DJI Mavic Pro about 4 weeks ago (both running the most recent firmware back then), taking off at sea level (on a beach) and flying a standard mission at 60m (P4P) and 30m (DJI Mavic Pro).

This is the XMP info for both:

P4P
- Absolute Altitude: +82.49
- Relative Altitude: +60.00
- GPS Altitude Ref: Above Sea Level
- GPS Altitude: 82.486 m

Mavic Pro
- Absolute Altitude: +53.19
- Relative Altitude: +31.00
- GPS Altitude Ref: Above Sea Level
- GPS Altitude: 53.186 m

By default, the GPS Altitude value gets imported into PhotoScan, which is quite inaccurate (as you can see). However, if you know the elevation above mean sea level (AMSL) of your point of take-off and add the relative altitude that is stored in the XMP to it, then you should be quite close to the truth (approximately +- 5m). In the case of our P4P, that would be....

0m (elevation AMSL of point of take off) + 60m (relative altitude) = 60m (flight altitude AMSL)

...

Yes, you have basically confirmed my own observation although the discrepancy appears to be consistently 22m high in your case.  Unfortunately it isn't consistent across locations as we were seeing it report 50m+ higher in an inland area where known ground elevation was about 1,150ft.  The barometer is quite accurate though.

I should note that if all you need is a topographic map of the land showing relative elevation differences for say for pre-design purposes, I think knowing the absolute ground elevation is really unnecessary.  It's the relative changes between points that is important.  In that case the use of GPSs is much less beneficial in my opinion.  Most have stated that vertical accuracy has been around 3 times GSD.  I personally think that's very optimistic so I always assume 5 times with no GCPs.  So if you fly to capture images at 1-inch GSD, the RELATIVE vertical measurements will be within 5 inch accuracy.  For most projects this is more than adequate when measuring land areas with features (gullies, hills, ridges) that are representing +/- 100 feet or more in differences.

It all really depends on the application.

48

General / Re: Altitude used in Processing UAV (DJI Phantom 4 Pro)

« on: April 25, 2018, 01:57:08 AM »

There was reports last year that the P4A/P went from storing GPS altitude to storing barometric relative altitude above ground relative to takeoff point.  It appears to me that the altitude being used by Photoscan from photos taken by a Phantom 4 Adv/Pro is currently indeed the GPS altitude above sea level.  So did it change back?  Anyone with a P4A/P can also verify this if they use Photoscan.  You can go into the reference pane and view the altitude values for each camera position.  For a recent job, the ground elevation above sea level according to Google Earth Pro was 350m and Photoscan was showing 526m for camera position at that point.  This was for a mission to fly 400 feet above ground level.  Either Google or the Drone's GPS is way off though.

350m = 1150 feet.  This is in the ballpark for the known elevation of the surrounding area (it's farmland.)

526m = 1725 feet

1725-1150 = 575 feet.  That' 175 feet higher than the the mission altitude. The GPS altitude is actually supposed to be fairly accurate, I believe within 15 feet.  Maybe this drone is faulty?

You can use this handy online EXIF viewer to see what's inside (http://exif.regex.info/exif.cgi ).  In the XMP there is an Absolute altitude and a relative altitude.  And in the EXIF there is GPS altitufde.  The EXIF GPS altitude matches the Absolute altitude in the XMP and the relative altitude in the XMP is correct. The rumor before (may have been reality until a firmware update) was the relative altitude above ground from the barometer was stored in both fields.  It is no longer.  Check for yourself if you don't believe me.  (One problem with the Internet, especially discussion forums, is how easily false information can spread because no one takes the time to verify for themsevles that what they are reading is true.  Think "fake news" !)
Whether this was just a temporary change/glitch in the firmware some months back or if it was "fake news" I don't know.

My question is, does it matter which elevation type is used in photogrammetry processing as long as the drone's elevation above ground is maintained relatively consistent across all photos?  Meaning if the drone goes over a valley and the altitude above ground because 100 feet higher, it seems with barometer above ground measurement, the drone would think the ground is 100 feet closer than it really is whereas GPS altitude above sea level would be consistent.  It would seem to me you want a consistent altitude reading for all the photos for the entire job site despite your launch point.  Seems this would be true using either measurement.

The big question to me is, if you are using absolute altitude in processing (above sea level), how can the drone know the absolute elevation of any point on the ground (without using GCPs)?  Seems to me it can't.  It can only identify relative elevation changes without GCPs.  Now if the processing used altitude above ground, theoretically if you knew the base elevation of any point in the photo, you could therefore calculate the absolute ground altitude above sea level of any point in the photo by adding that to the elevation data output.

Admittedly, I'm on the fringe of my knowledge of photogrammetry in the context of generating ground elevation data so these are all semi-educated guesses on my part.

49

General / Contour Line DXF Export Not Very Useful?

« on: April 24, 2018, 10:45:01 PM »

When I generate contour lines within Photoscan, they look like they should (ever 1m).  When I export it to DXF and load it into a CAD program, it's a jumbled mess of lines and lots of tiny shapes - looks nothing like the display in Photoscan.  Is this normal.  Is essentially the DXF contour line output not work very well and it's best to revert to importing DEM into a GIS program and generating contours there?

50

General / Did my elevations get inverted? (DJI Drone Photogrammetry)

« on: April 24, 2018, 10:03:40 PM »

I'm still examining things and it's hard as I'm using remote desktop on a cloud server.  But it looks to me like the elevation data is inverted.  Can someone confirm on the DEM export, is the dark area the lower elevations and the light/white area represents the higher elevation,  If so, then my model is definitely inverted. 

I had a few GCPs but only a few to verify I was in the ballpark.  On processing, after photo alignment, I loaded and marked the 4 GCPs and then unchecked all the cameras and did the camera optimization step, rechecked the cameras and proceeded with processing,  The elevation data for the cameras, despite the rumor it is AGL on the DJI drone, is indeed meters above sea level, as the elevation is about 370m and we flew 400ft AGL and the EXIF is showing 526m elevation.

The only thing I can think of is that the photos were taken from about 4 different launch points on the property but the elevation difference between launch points was only 50ft max, that wouldn't invert the elevation data.  When there is a greater distance between the land and the drone, the AGL would be higher (but again, it would be showing 130m elevation in the exif  data in the reference panel of Photoscan if it were using AGL, not 526m.) 

If the dark part of the DEM is indeed the higher elevation then I am misreading everything so this is all moot though.  Waiting for the 3D rendering to complete as once the photographic imagery is projected on the 3D model I'll quickly see if it is indeed inverted.

Would it be prudent even if you had only 3 or 4 GCPs towards the edge of a huge land area (400 acres) to just use those and uncheck all the cameras if absolute horizontal and vertical position accuracy is not of concern?  That would rule out issues with the EXIF data I suppose.

51

General / Re: Altitude used in Processing UAV (DJI Phantom 4 Pro)

« on: March 27, 2018, 09:53:53 PM »

It has been widely reported that the elevation data recorded by the DJI Phantom 4 in the EXIF data is the altitude above ground level (above the point of takeoff) and is determined by barometric pressure.  The drone does use GPS for navigation.  There are also two elevation fields in the EXIF data and I believe one is labeled GPS elevation.  It has been confirmed multiple times that the DJI Phantom 4 model is writing the above ground value not the GPS altitude above sea level value.

It is also noted that the barometric altitude measurement "drifts" over time of the mission by around 10-15 feet so the drone will think it is 10-15 feet higher above the take off ground level near the end of the battery than it recorded near the beginning.

It is unfortunate DJI is no longer writing GPS altitude to EXIF as this does not have the drift problem.  Also on jobs where there may be multiple take off points at different elevations, they will all be consider 0 feet AGL therefore the exif altitude reading would not even be relatively conisistent from the other take off points.  Example you take off at A then go run mission take point B which is 50 feet higher elevation above seal level than A.  The Exif elevation for point B mission of 150 feet would be equivalent to 100 ft elevation data in EXIF for mission flown from point A.  Not good. 

...somebody in an earlier thread wrote: "PROBLEM
The usual metadata tag that is used by these applications is the ‘GPSaltitude’ tag. Currently DJI populate this from the aircraft's GPS unit. The altitude recorded here is grossly inaccurate. We need to fix this as far as we can."

This can not be an issue or correct, since the Drone is flying the mission by the GPS, so the altitude data in the exif file should be the same as the actual GPS height which also is tranponded to the control software on pad/mobile.

Why is not the exif altitude and the drone altitude the same? and if not - why do Dronedeploy get it right?

MIG-29 (Fulcrum)

52

General / Help With 3D Model - Landscape / Buildings

« on: March 12, 2018, 06:40:45 PM »

I've got a project that consists of about 500 nadir photos (20MP) and 300 obliques taken in a criss cross pattern at 45-degree angle all done from a DJI Phantom 4 Pro drone at about 225 feet and then an orbit around the buildings at a 45-degree angle at 150 feet.  Flown with 70% sidelap and 80% frontlap. There's quote a few trees in the shots (buildings surrounded by forest).  Pix4D, DroneDeploy, and SkyCatch all processed the the photos and generated a 3D Mesh Model that had no issues.  Photoscan, I'm getting pieces that are floating way up in the air.

Support suggested after photo alignment, go into reference pane, uncheck all the photos, then run camera optimization and make sure K4, P3, and P4 weren't checked.  Then recheck after optimization. I pretty much kept all the other settings as defaults - medium point cloud, etc.  Didn't help.

There are so many gosh darn setting in all the workflow steps in Photoscan it can be quite a task to find the 'winning combination'  Other users doing models of buildings and landscape must have run into this before.  Any other suggestions as to what to try to change in settings?

The parts of the model that are fine look better than all three of the other photogrammetry solutions I compared it to (Pix4D at highest setting comes close but PS looks better).

53

General / Height Field and Abitrary Settings and RAM Requirement

« on: March 11, 2018, 09:23:54 PM »

I've been generating 3D models following the workflow with all the defaults.  Medium cloud density, etc.  Align Photos > Build Cloud > Build Mesh > Build Tiles > DEM > Orthomosaic

These models are of buildings and landscapes with 20MP images 80/80 overlap.  A typical job might be about 700 photos (part nadir part oblique).  The models have been looking fantastic. 

However when I was reading the document about RAM requirements and for a model in abitrary mode, for 500 High Quality photos the requirement is like up to 180GB of RAM and I'm processing 700 20MP photos on a 90GB machine and I took a peek at the memory being used at various points at it never got close to being maxed out.  Granted if only one step in the multi-step workflow needs all that RAM I may have forgot to look at RAM usage during that step.

So I'm wondering, because I'm going through the workflow with all the defaults am I really processing all these jobs in height field mode.  Where in the work flow is the setting to change between height field and arbitrary in the processing.

54

General / Processing Time Compared to Pix4D Mapper Desktop?

« on: March 05, 2018, 11:22:29 PM »

Has anyone compared Photoscan to Pix4D Mapper Desktop?  I just started comparing and I'm using a server with 244GB RAM, 2 Nvidia M60 Graphics Cards, and 64 CPUs.  I have finished my testing yet but it sure looks to me like Pix4D takes considerably longer to do all the processing steps following the photo alignment.  This is sort of an informal test for me and things are still processing but just curious if anyone else can confirm this is true or are they relatively about the same in processing time all other factors being equal?
 

55

General / Re: Altitude used in Processing UAV (DJI Phantom 4 Pro)

« on: March 04, 2018, 06:37:15 PM »

Retrieving the .DAT file from the AC should help fix your issue, some what.
http://www.datfile.net/DatCon/retrieveV3Dat.html

This URL generates a malware warning and my malware detector (Bitdefender) is pretty darn reliable.

56

General / Define Polygon instead of Rectangle for Processing Bounding Box, or, Export Area

« on: March 04, 2018, 06:35:12 PM »

If I'm processing a land area that is not rectangular, is the only way to "crop" the horizontal and vertical planes by using another program post process?  It appears only a rectangular area can be defined for the processing bounding box?

Can I define a horizontal polygon or 3D polygon area on the export side of things?  Looks like this type of stuff has to be done after export?

57

General / Running Photoscan on Ubuntu?

« on: March 04, 2018, 01:55:17 AM »

Trying to run Photoscan on Ubuntu via Windows RDP connection to AWS EC2 instance.  The licence key popup comes up but the keyboard isn't mapped right.  When I execute photoscan from a terminal window:

sh photoscan.sh

I get "XKEYBOARD extension is not present on the X Server"

What I'm guessing is Amazon's instructions for setting up Windows RDP for Ubuntu isn't compatible with using it to remotely run Photoscan.  Anyone know what I need to do to get this working?

These were the instructions I followed:  https://aws.amazon.com/premiumsupport/knowledge-center/connect-to-ubuntu-1604-windows/

58

General / Re: Can I improve this model somehow? Worse output than MapsMadeEasy?

« on: February 03, 2018, 12:26:13 AM »

Hi jazzyj,

Please share the processing report for this project (FILE > EXPORT > GENERATE REPORT...) in order to assess your processing issues.

Regards,
SAV

Processing report: https://we.tl/d1FILYFiqQ

59

General / Hardware Provisioning and CPU/GPU Settings?

« on: February 02, 2018, 11:54:57 PM »

I'm trying to determine the most efficient hardware provisioning for a cloud computing workstation for Photoscan.  I typically do mapping jobs generating Orthomosaics, DEMS, and sometimes models, with typically 1000-3000 cameras (each a 20MP photo  - yes these are large 100acre-300acre areas of land). 

This doc seems to give decent guidelines as far as memory: http://www.agisoft.com/pdf/tips_and_tricks/PhotoScan_Memory_Requirements.pdf

If I read it right it seems to indicate for my typical use I want minimum 32GB RAM, but 64MB would be more optimal.  However I noticed the RAM for generating a model is way higher.  I may need to so something like a model of several buildings on a 75 acre property.  I'm guesstimating, I'd end up with maybe 750 nadir photos and another 500 obliques, so 1,200 photos total.  The chart doesn't even go beyond 500 photos on the model so is processing something with 1,200 photos essentially impossible if say I had dual GPU, 244GB RAM, 32 processors, and Dual GPUs?

I guess you could always batch process the 20MP JPEGs with a higher compression rate to lower memory requirements as necessary.

This great article indicates the old "Law of Diminishing Returns" as far as CPU cores, so when given a choice, obviously you want to choose a "RAM optimized" workstation setup as it appears the RAM is the limiting factor in the size of the job that can realistically be processed and the GPU is more important than the CPU once you get above 6 CPUs.


Also I saw something about reserving one CPU for every GPU but I didn't see that setting in Photoscan so maybe that was a setting in an older version and now the software automatically does that for you?

And finally, are there steps in the workflow that don't benefit from gobs of RAM and GPUs.  I'm thinking I could cut processing costs by moving the project files to a lower cost platform for those steps that doesn't have multi-GPU and tons of RAM.

Thanks

60

General / Can I improve this model somehow? Worse output than MapsMadeEasy?

« on: February 01, 2018, 01:57:45 AM »

I created a model using all the default settings except changed number of tiles from 0 to 10.  I uploaded  the .obj .mtl and jpeg tiles.  The output was noticeable worse than MapsMadeEasy - see the structure behind the white car.  Wondering what most likely I should change in Photoscan to get a better output like MapsMadeEasy?

Top is Photoscan. (you need to scroll to right to see the structure I'm referrring to.)  This is how it looks in Photoscan too.