Messages

1

General / Re: Agisoft PhotoScan 1.2.0 pre-release

« on: September 29, 2015, 12:55:18 PM »

Another network processing problem. I'm distributing processing onto two servers, one of which has a GPU, the other does not. I have only a single user profile on our system.
Starting the node, the one with the GPU gets the --opencl_gpu_mask 1 and the node without gets --opencl_gpu_mask 0.

With processing running (fine distribution to both machines), we get:
[CPU] estimating 238x257x96 disparity using 238x257x8u tiles, offset -52
opencl not found
processing job: BuildDenseCloud
timings: rectify: 0.015485 disparity: 0.08769 borders: 0.01633 filter: 0.02417 fill: 1e-06
[CPU] estimating 242x251x96 disparity using 242x251x8u tiles, offset -53
timings: rectify: 0.01503 disparity: 0.078616 borders: 0.009516 filter: 0.009682 fill: 0

ie. "opencl not found" errors, only on the machine without a graphics card. These errors flood back to the server, but they don't seem to affect the processing.
I suspect that this is to do with the user profile. There seems to be interference between instances run from the same user profile.

2

General / Re: Agisoft PhotoScan 1.2.0 pre-release

« on: September 29, 2015, 12:39:39 PM »

Ah, quite right. It seems that the server was running build 2154, not 2158 as I had thought.

Thanks!

On a different note, on one of the machines, I'm getting the following error (in launching the client):
Cannot mix incompatible Qt library (version 0x40804) with this library (version 0x40807)

I can get rid of it by overriding the photoscan.sh script to force it to use the system libraries instead of the ones provided. However, the system libraries are older and don't work properly with the 3d display (only get markers, not pointcloud). It seems that although the Qt libraries are provided, it is using a system one as well?

I'm using Mageia linux, 64-bit. Running ldd | grep -i qt shows that it is correctly referencing the 4 libraries in the install directory.
Any suggestions?

3

General / Re: Agisoft PhotoScan 1.2.0 pre-release

« on: September 28, 2015, 06:48:50 PM »

Network Processing bug.

Hi,

I've been trying to run a big project with network processing with the beta version (am using build2158)

Nodes manage to connect to the server, but on the server end I get the following in the terminal:
accepted connection from 163.1.22.50:50684
thread started
Error: no workitem

It does let me continue though, so I tried to start a build dense cloud for the project, which it sent only to one of the nodes, and on that node the terminal displays:
registration failed: unexpected error

Within the network monitor it then continues to display "Working" and the elapsed time starts counting up, but there is no cpu usage on the node machine.

Just gone back and tried with the previous version (1.1.6) and it does seem to work without these error messages.

Lastly, I've just noticed something... when starting the server (running from the new version) it displays:
Starting network server (version 1.1.6 build 2038)
family: 2
socktype: 1
protocol: 6
family: 2
socktype: 1
protocol: 6
thread started
waiting for incoming connections...
waiting for incoming connections...

i.e. The old version number... Is this because it hasn't been updated?


Cheers

4

Feature Requests / Re: Improvement final report

« on: September 15, 2015, 11:08:43 AM »

A slightly different request on the same topic.

The generated report does produce some useful metrics, but only in pdf form. It would be really useful to export some of these maps in georeferenced format for use in GIS (e.g. GeoTiff). In particular the map of number of cameras seeing an area.

5

General / Re: low accuracy align produces better results than high accuracy

« on: September 15, 2015, 11:02:23 AM »

I've often found this to be the case too. I believe this is to do with the scene texture and the length scales of that texture. Using lower accuracy settings forces the software to only use much "larger" features in the image, which may be more stable if the small scale features are very uniform.

One way I get round this is to run the model at low accuracy, and georeference it and save the estimated camera locations and orientations.  Then I re-run at high resolution having imported the prior orientations as the initial parameters (with control based pre-selection).

However, if "low" accuracy alignment is sufficient for your project, I'd probably just stick with that.

6

General / Re: Good XY data, struggling with Z.

« on: September 15, 2015, 10:56:25 AM »

Yes, quite right. Depth of field is necessary in the images to break the tradeoff between radial distortion and focal length, so more topography will have a  similar effect to adding a number of oblique images.

7

General / Re: Good XY data, struggling with Z.

« on: September 14, 2015, 07:03:13 PM »

Are all the images acquired at nadir or near nadir? With such a flat region, I would expect significant tradeoff between the radial distortion and focal length (http://doi.wiley.com/10.1002/esp.3609). Adding some significantly oblique images could help to resolve this. The "optimize" approach is a good after the fact solution, but I suspect that tough projects will break it.

8

General / Re: xy reference points without a z-value

« on: September 14, 2015, 06:49:34 PM »

I don't think this is possible in Photoscan at the moment, but I would really like to see it implemented!

This is also very frequently a problem if one has only handheld GPS to reference a model - in this case the vertical accuracy of the GPS is very much lower than the horizontal accuracy. Mathematically, the problem is solvable with the elevation of one point and only xy locations for all the rest, so it would be great to see it implemented.

Using google earth can work, but it is a very rough and ready solution - this uses the underlying SRTM dataset for elevations, typically accurate to ~15m, so you can end up with significant tilts in your model. Photoscan will trade off the fit in x-y to fit this elevation better unfortunately.

9

Feature Requests / Re: Origin alignment by point selection

« on: February 26, 2015, 03:20:03 PM »

I guess so - one could work out relative coordinates based on the orientation.

I was really going on the fact that it is the elevation azimuth and length that are the easy quantities to measure in the field.

10

General / Re: Do I need GCPs to get an accurate DEM?

« on: February 26, 2015, 03:17:15 PM »

It really depends on how much you need accurate tip-tilts. You can use an accurate scale length to scale the model (e.g. use a tape measure on some object within the scene), and you could use handheld GPS to set a rough georeferencing (good enough for a lot of things).

Alternatively if you're looking at changes through time, you could borrow a survey GPS to measure some control points that wont change over time and just use those repeatedly.

11

Camera Calibration / Re: Use of Macro setting when calibrating a lens

« on: February 26, 2015, 02:14:45 PM »

I guess an easy approach would be to print an A0 poster sized sheet with the same grid. Would it be possible to include a pdf of such a grid with the lens software?

Would the idea of a projector onto a flat wall work also?

12

General / Re: Do I need GCPs to get an accurate DEM?

« on: February 17, 2015, 06:20:27 PM »

Careful survey design is also a really important element of this. While a dense network of GCPs will allow you distort your 3D model back into shape, it is better if you can minimize the camera model distortion in the first place.

Because of the progressive nature of the bundle adjustment adding photos one/two/few at a time, you can get build up of systematic errors across the model.

The most typical case for this is actually planar acquisition - if you take all of your photos at nadir (straight down) then there is a tradeoff between the radial distortion and the focal length for the lens. The net result of this is a "bowling" of the entire model.

You can either fix this after the fact, with lots of ground control, to restore the model to "flat" (I assume this is what the optimize button does in photoscan), or you can minimize it before hand by careful survey design - though ideally you would do both! You need to have a number of off-nadir images included in the dataset - this will significantly reduce the lens miscalibration.

As mentioned above, you will need some precisely located ground control (>=3) in order to get an accurate tip/tilt for your model. Standard GPS (as on the phantom) will give you a reasonable scale for your model if your survey area is large enough (typically ~3m horizontally, which will be 1% over 600m).

As ARF said though, whichever way you do it, you should definitely use plenty of independent checks the first time you do it.

13

Feature Requests / Re: Origin alignment by point selection

« on: February 17, 2015, 06:04:45 PM »

And similarly/equivalently, it would be really useful to be able to specify the orientation of a scale bar (azimuth, elevation and xyz location of one end) to completely specify the orientation of the model.

14

Feature Requests / Re: Origin alignment by point selection

« on: February 17, 2015, 06:02:28 PM »

Definitely second this one.

15

Feature Requests / Re: 6 DOF controller compatibility

« on: September 09, 2014, 12:57:31 PM »

Big +1... Would be really useful. It's frustrating not being able to use mine.