Messages

31

General / Re: DEM Export Digits Of Accuracy

« on: February 09, 2016, 12:57:23 AM »

Turns out that loading the point cloud from an "EXPORT POINTS/ASCII PTS" format file with 7 digits of accuracy in the X and Y values does clear up any grid locations without altitude points on a 100mm grid.

Scanning through the 1.5gb text file doesn't take as long as I thought, so now I'll go back and try lower resolution Dense Cloud settings to see if I still get repeatable results with smaller files.

100 MM is going to be sufficient resolution for volume calculations, so I'm revising my initial question...

Next time y'all do an upgrade would it be possible to get that 7th digit of accuracy for the "EXPORT DEM/XYZ Format" files?

32

General / Re: DEM Export Digits Of Accuracy

« on: February 08, 2016, 08:09:45 PM »

Dave,

Thanks very much for your response. It's a great idea I hadn't thought of, but I'm skeptical it will change the export values for XYZ format

What Cartesian coordinate system do you suggest and I'll try it?

I'm currently using WGS 84.

The fact that the ASCII PTS format uses 7 digits coupled with the observation that when you zoom in to a silly high resolution point cloud you don't see visible gaps makes me think that the internal calculations within Photoscan are at least double floating point values which would be 15 digits of decimal accuracy.

I also clearly understand that the source values for the Lat/Lon are a limiting factor, as they coming from a GPS system that probably has a 3 meter horizontal error anyway - much more for the altitude values.

I also understand that I could increase the grid size such to the point where no gaps are left, but that decreases the overall accuracy of any subsequent volume calculations.

I would just like to get rid of the gaps when I convert to an orthogonal grid.

As for fixing the gaps, I don't have a problem with that. I can take an average of the surrounding grid squares that do have altitudes very easily as part of the volume calculation process.

The direction I'm going is a single program that loads a DEM in the form Photoscan exports it, does all the calculations required for volume, including estimating the shape of the lowest altitude starting surface, exporting the results in a DXF or STL format for viewing.

33

General / DEM Export Digits Of Accuracy

« on: February 08, 2016, 07:26:37 PM »

Alexey,

I'm trying the use DEM Export data to calculate volumes of enclosed structures.

My thinking was that if I break down the point cloud into discreet intervals where Lon was the X coordinate, Lat was the Y coordinate, and Altitude was the Z coordinate, I would be able to easily calculate volumes, differences between previous DEMs, etc.

When I work a dataflow using the highest possible settings I know of for each step and then export the DEM using the XYZ format, I still get some X/Y grids squares with no altitude values, even if I set the grid scale to 100mm.

The attached images show the location within the sample DEM of grid square that don't contain any dense cloud points. By averaging the nearby grid squares that do have altitude values, I can estimate the altitude of the missing info, which is what is shown in the images.

As you can see from the shapes, the grid square without cloud points is not random, but has a repeating consistency, which leads me to think it's coming from the data and/or underlying calculations in terms of the available digits of accuracy.

The export accuracy for XYZ DEMs seems to be 6 digits of accuracy, which could very well explain my problem because that would be a resolution of approximately 90mm for my latitude, so it's possible some grid squares could round/truncate out of existence completely.

I see in the "Export Points/ASCII PTS" format that the values have 7 digits of accuracy (example attached), which would bring me to about 9 mm of accuracy, but I don't see any way to export using that format in anything less than the entire point cloud in full resolution, which for the first workflow I tried turned out to be 1.5 gigabytes of text.

Here is my question :

Is there any way to get a DEM Export using the XYZ format with 7 digits of accuracy or conversely any way to control the export size of the ASCII PTS format without decreasing the resolution of the entire workflow process?

A work-around would be to write a program that sifts through the full ASCII PTS export calculating the average altitude for each grid square, bringing the volume down to a useable amount, which is what the DEM Export/XYZ process does, but before I start anything that requires working with 1.5 gigabyte text files I thought I'd ask.

Suggestions appreciated

Hank

34

General / Re: Gap in Alignment of Orthophoto.

« on: February 08, 2016, 05:05:13 PM »

Am Reading the log file correctly that the alignment process took 49 hours to complete?

"Finished processing in 177696 sec (exit code 1)"

2 days?

35

General / Re: Gap in Alignment of Orthophoto.

« on: February 08, 2016, 04:44:20 PM »

Yes- if you're using "REFERENCE" without lat/lon it would probably confuse Photoscan no end - I missed that

Good catch, Stihl

And upon further review, I take back my suggestion about manually setting the altitude to the known mission height.

If you had lat/lon values, as in from EXIF, that would help, but since you don't, you would have to create an import file that includes lat/lon and altitude.

If there is a way to only set ALT and leave Lat/lon unknown I don't know how to do it.

Which means you would have to set the lat lon values to zero or some estimated value.

Having the lat/lon for every image set at 0, or even an estimated value would probably confuse Photoscan more than the good that you would get from having a set altitude value

From the shape of your turns it look like you're using some sort of fixed wing platform?

No hope of a flight log with Lat/Lon/Alt?

I recently came up with a way to extract the gimbal directions for every image based upon it's time code as compared to the associated values in the flight log file of a Phantom Pro 3. In addition to pitch and yaw, I also can get more accurate lat/lon/Alt values by interpolating between flight log entry lines than seem to come in from the P3P EXIF values.

Once you include pitch and yaw, as well as increase the accuracy of the Lat/Lon/Alt values, you don't have to delete the cross-grid first and last leg images anymore, and everything stitches every time.

36

General / Re: Gap in Alignment of Orthophoto.

« on: February 08, 2016, 03:32:29 PM »

Without downloading the entire image set and giving it a spin, here are my initial thoughts.

1) bare ground agricultural missions are the worst to try and stitch together because since everything looks exactly the same. There is a place where almost every picture can be rotated and placed somewhere else with relatively good alignment. I have several missions where images of a field with crops would stitch, but the exact same mission in similar light on the same field a few months later when it was bare would not.

2) I am very surprised that Photoscan did as well as it did on a bare field without any geo-referencing information on the images. In my experience, even a rough lat/lon tremendously increases the likelihood that all pictures will be aligned, and if you add altitude and yaw, you will also get the images at the turns. If you add geo-referencing you can widen your mission legs significantly and still get complete orthos. Wider leg gaps means more acreage per battery.

3) I don't know this to be a fact but I have always assumed Photoscan gives higher alignment weights to images that occur in sequence by the file name, which I assume you're using - if not you might try getting the files named sequentially.

4) you might try manually making an import file that sets the altitude for each image to the altitude you know the mission was flown at. This will at least help Photoscan freeze the scale of each image.

2) it looks like you have included the diagonal images for either the first or last leg of the mission. In my experience these images also introduce the added mathematical variables of the unknown but changing altitude getting up to the first waypoint or descending from the last. The area of your gap seems to intersect that diagonal path. You might try deleting those images from the dataset.

3) As for settings, using the settings for each step as outlined in the Photoscan tutorial have always worked well for me.

4) I have successfully flown a bunch of agricultural imaging missions and never once used ground control points. I can think of no reason why GCPs would make the alignment process more difficult, but you might try not using them, or just in the corners if you're looking to generate a geo-referenced final ortho.

Let me know what I can do to help

HMArnold@msn.com

37

General / Re: Yaw Pitch Roll + Omega Pho Kappa

« on: February 06, 2016, 10:50:36 PM »

Photoscan is the same

38

General / Re: Orientation of spherical cameras

« on: February 06, 2016, 10:49:53 PM »

Although I have never worked with spherical camera arrays,  I would think each image would have a pitch value of the number of degrees from vertical the camera is mounted, a yaw value equal to the angle the camera is pointed from the front of the car, corrected for the direction the car is pointed when each image is taken, and a roll value of zero assuming the car is traveling flat.

If a camera is mounted pointed to the right side of the vehicle and down 30 degrees from the horizon, and an image was taken when the car was on a compass heading of 225 when an image was taken, the yaw value would be -45  (225+90 = 345 compass which is 45 degrees left of North), the pitch would be 60 (90-30), and the roll would be zero

39

General / Re: 3D Printing Bones

« on: February 04, 2016, 02:01:56 AM »

The STL format only defines the outer shell.

When you import it to a program like Maker Bottle or send it to a cloud based printing company,  then you define the wall thickness,  solid or air filled interior,  etc along with the type of material to be used for printing.

40

General / Re: 3D Printing Bones

« on: February 03, 2016, 11:11:49 AM »

Photoscan has the ability to export model results in STL format

STL format is the most common format for 3D printers

41

General / Re: UAV Volume Calculation

« on: February 02, 2016, 07:31:34 PM »

Bernado,

Yes, a P3P is a very useful platform for this kind of project. I have flown many autonomous missions to collect images that I use Photoscan to create orthomosaics with.

If you fly at 100 meters you get excellent resolution that will reliably align in Photoscan whether there are crops in the field or bare ground.

At 100 meters you can expect to fly 175 acres on one battery and get your platform back safe and sound.

In my experience you only need angled images if there is a fine detail of height you want to accurately model, such as the very peak of a storage pile of gravel. In this case, when viewed from directly above, the angle between where that peak occurs in two overlapping images is very small, so a small error from the triangulation could mean a matter of inches difference.

Normally a matter of inches might not be important, but for accurate volume measurements for inventory purposes, the peak of a large pile of gravel being up or down an inch or two could mean several tons of inventory.

For comparison of the erosion, I don't think you'll have the same problem with peaks or measurement accuracy.

To calculate volume I use a program we developed that work directly from a Photoscan DEM, but I know some survey companies use Autocad.

I don't use it for calclulations, but you can export a DEM in STL format and load it into Trimble Sketch up

I'll do what I can to assist

HMArnold@msn.com

Hank
Texas

42

General / UAV Volume Calculation

« on: February 02, 2016, 02:48:11 AM »

This is a long thank-you post to Agisoft Support.
I’ve been trying to create high resolution DEMs in order to calculate the internal volume of containment berms around oil storage tanks using images taken with a UAV.
The problem has been that although normal orthogonal (camera straight down) images will stitch in Photoscan and generate a DEM, they don’t detect and report variations in the top of the  structures well because of the triangulation problems associated with two overlapping images taken at almost the same angle, straight up.
On the other hand, if you fly the UAV lower and point the camera back towards the top of the structure being modeled, Photoscan will more accurately pick up altitude changes in the top of the structure, but flying a UAV mission that returns an image set where every picture will stitch is very difficult.
Usually, on a 4 sided rectangular containment berm, one or two of the sides will stitch, but on at least one side some or all of the images are left non-aligned.
The nice folks at Agisoft Support looked at a small subset of clear images with an overlap above 70 percent where one row was taken directly over the berm with the camera pointed straight down, then one row of images down each side with the camera pointed at 60 degrees down from horizontal.
They told me that the reason the images didn’t stitch was because the angle between the images was too great, and they suggested that 30 to 35 degrees was the most Photoscan could work with.
I went back and re-designed the autonomous UAV mission to take a vertical set, then a sideways set from 30 degrees from horizontal, and the images stitched properly every time.
Then I went back and added two more legs down each side at 60 degrees from horizontal and found that now they would align reliably.
Because they took the time to look at my images and make an informed response, they saved me days of work trying to adjust the overlap and distances, all of which would have been a waste of time.
The other thing I learned was that including the camera orientation values from the mission flight log helped Photoscan tremendously in terms of properly aligning all images.
For these missions I used a DJI Phantom 3 Pro, and by calculating the camera direction (YAW) and camera vertical angle (GIMBAL PITCH), I was able to set the accuracy values for all images to 1, and I have yet to have a non-aligned camera, even when I include the images taken during the turns at the end of each leg.
The DJI Phantom 3 Pro also includes worthless altitude information in the EXIF data associated with each image, that they call “GPS Altitude”. I have read that the GPS Altitude tends to be inaccurate, but with DJI, it’s more than that. I live near the coast and I have yet to export a single mission of images where the altitude values in the EXIF data were above sea level.
For my platforms sold in the US, DJI also writes the GPS altitude in feet, which using the WGS 84 coordinate system, Photoscan takes as meters. That means that all the alignment angles are off, and Photoscan starts properly disregarding the altitude values. This causes some cameras to be positioned below the ground, up in the sky, whatever.
By using the flight log data you can create a Reference/Import file that overwrites the incorrect DJI altitude value with a more rational “Mission Altitude” value, which is referenced from the take-off home point and seems to be very reliable.
The trick with Photoscan is that you can’t just import camera orientation values.
If you’re going to import anything, then as far as I can tell, you have to import everything.
That means you also have to calculate the lat/lon values for each image based upon it’s EXIF time, even though the flight log info doesn’t correspond to individual images, it writes a record every few milliseconds.
It is possible and I’ll help anyone interested if I can
Thanks Agisoft, for a great product and informed support

Hank
Texas

43

General / Re: Volumetric measurements from surface interpolation

« on: February 01, 2016, 05:11:37 PM »

Yes, Photoscan can do this task.

You might need to look into using GCP (Ground Control Points) to mark the interface between outcropping types of rock, because Photoscan will be able to model the 3D topography of your pit, but might have trouble defining the interface base upon color alone.

My experience with Photoscan tells me that the best DEMs (Digital Elevation Models) are formed from images from above, so you might have some trouble if you're planning to take the images by walking around on the ground.

I do imaging and calculations on vertical structures such as piles of gravel/aggregate/sand, stacks, containment berms or dikes, and in the past have practiced on negative structures (below ground).

Here is an example of a drainage ditch modeled with images taken from a drone:

https://sketchfab.com/models/04283d43898a43df9db0649db93484d0

This is an interactive Sketchfab model that Photoscan has direct upload capability to use.

If you zoom in the look at the brown dirt next to the ditch, you can see the extreme 3D resolution that allows you to tell the last type of equipment to drive by based upon the type of tire tracks.

If you have a DJI Phantom 3 UAV or can borrow one, I can help send you an autonomous mission that will take the required images and help with the Photoscan calculations.

Hank

44

General / Re: Realignment of selected (unaligned) cameras

« on: February 01, 2016, 04:56:18 PM »

The ability to re-align only a few cameras is a powerful feature, and I have struggles with it for some time.

Apparently a re-alignment builds upon all the surrounding images that DID align, so if you have a spot with poor coverage, poor light, or severe angle changes, a re-alignment can build on those images that Photoscan understood enough to align previously.

This feature makes the ability to re-align cameras even more powerful.

One thing I have noticed is when they say "Select" the cameras, they don't mean with the checkbox - they mean only the blue highlighting.

Sometimes when I do a subset, the selected cameras and everything previously aligned all collapse in to a single point, with all of the cameras in a sphere around it. When this happens, no amount of resetting the image gets it back, and there is no "undo", so I agree that you should always save your work before re-aligning a subset.

I think the collapse has something to do with which cameras have check marks, so I have been turning off all check marks before I attempt a re-alignment, and it seems to be working better.

45

General / Re: Ortho Photo has disjointed structures - 90% overlap

« on: December 15, 2015, 10:18:40 PM »

Alexy,

I went back and re-calculated the entire process, and this time there are a few lines that should be straight that show up as crooked, but not near as bad as it was before.

I must have left out a step the first time

I'm attaching the solid view you requested and a small detail of the resulting orhtomosaic

Thanks very much for getting me straightened out

Hank