Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - photogrammetrix

Pages: [1]
General / The future has just begun ...
« on: September 15, 2015, 07:31:02 PM »
Hi everybody,

just recently stumbled across this:, in realtime!


General / Quo vadis, PhotoScan?
« on: October 02, 2014, 11:40:51 PM »
Hi all,

thanks to the Agisoft team for putting a lot of effort in developing this good piece of software. Please forgive me the pathetic attitude in the title of this posting.

I was crossreading some of the latest feature requests and looked around on the fresh designed website. Photoscan is meanwhile used for a broad spectrum of applications reaching from gaming, multimedia and art to geoscience, GIS, mapping and surveying. This is an undoubtable proof for Photoscan's outstanding versatility.

Naturally all these different fields of interest have their legitimate wishes and needs for new functionality in the future.

For the moment Photoscan exposes itself to the user as more or less monolithic block of software covering everything "under one hood". I am wondering about the way and strategy the increasing number of features and functionality will be managed in the future - e.g. plugins, branche specific sub-versions, anything else???

In other words: "Quo vadis, Photoscan?"


Feature Requests / 3D-Cursor Coordinate display and coordinate/point picking
« on: September 28, 2014, 10:48:14 AM »
Dear Agisoft Team,

what I am really really missing in Photoscan is a realtime 3D Cursor Coordinate display and picking tool when in Model view or 2D-Cursor coordinate display when in photo view, that are independent from creating markers. Best would be a combo with a fast measuring tool.

The coordinates should display as local, and if a Mapprojection is existent, as geocentric and map-projected too and when in photoview image coords (row,col, RGB) and the asoziated 3D coords. That would be really great.

If the python Api will become more flexible and expose the necssary interfaces for accessing the model and photoview graphics to do such things, I would try it on my own.

So this is another great wish: a more extended and flexible python api that allows acces to the graphics. e.g. in broader sense like ESRI does with python interface in ArcGIS.

And here comes the last one for today:
a crosshair marker style, so thet the position can be checked better without having to zoom in too far  as with the dot/flag symbols.

Cheers and thanks!

General / ground vs. non-ground points classification
« on: September 25, 2014, 11:29:59 AM »
Hi all,

taking a look at the dense point cloud point classification functions and performing just a first initial run , I found the following:

When creating a mesh from ground point class, it seems that resulting mesh does not represent the exact same area as depicted by the red groundpoints-mask, although interpolation/extrapolatiion was switched off.  So unwanted objects seem to remain in the ground-mesh.

Please see attached Screenshot

Tested on lUbuntu 12.04. LTS with PS and 1.1.0 1976


General / Short report on reconstruction with WW2 air-recce images
« on: January 15, 2014, 02:50:08 AM »
Hi all,
for a history project we tested PS reconstruction capabilities with 2 sets of  WW2 airial reconnaissence images:

Set 1: British Royal  Airforce recon images from a small town in Germany, late summer 1943, camera unknown, geometry etc. were unknown to us, poorly scanned by the vendor, low resolution, partly cloud cover, a minimum set of only two images.

Set 2: A couple of images from two flights over Volgograd (aka Stalingrad), August and Oktober 1942, German Luftwaffe (Source is an archive in the US, please send PM if you are interested), Images were of good quality and hr-scans provided by the archive were really good, 3.7k by 3.7 k pixel, fiducials were visible, so we were able to reduce some image distortion introduced by the scanning process. Camera was Zeiss RB 70/30 and RB 50/30.


Set 1: Even with this poor set PS was able to do a mosaicking.
Please see first image. no acceptable dsm.

Set 2: Very good mosaicand a more or less acceptable dsm, generation of textured 3 model, based on an 41 Mio point cloud. Please see image 2.

PS did a great job for this test.

General / How does PS Pro handle geodetic datum transormations?
« on: September 15, 2013, 12:23:45 PM »
Hi everybody,

I just recently came across the question, whether PS Pro automatically takes the appropriate geodetic datum transformations into account, when conversion between coordinate reference systems requires to do so.

Photoscan project file was set up using manually picked gcp from CAD drawing which was in DHDN GK Zone 3 (EPSG:31467) projected coordinate system.
Parameters for that are (in ESRI-PRJ File compatible notation):


Task was, to convert to geographic coordinates in WGS84 (EPSG:4326), which is defined by:


Depending on the location of the project area, there are different Datum transformations applicable (here as suggested by ArcGIS projection engine):

DHDN_To_WGS_1984_1           1673        Germany - West
DHDN_To_WGS_1984_2           1777        Germany - West
DHDN_To_WGS_1984_3           15869       Germany - Brandenburg, Mecklenburg-Vorpommern, Sachsen, Sachsen-Anhalt, Thueringen
DHDN_To_WGS_1984_3x          108206      Germany - South of 50°20' N
DHDN_To_WGS_1984_4_NTv2      15949       Germany - onshore
DHDN_To_WGS_1984_4x          108207      Germany - between 50°20' N and 52°20' N
DHDN_To_WGS_1984_5x          108208      Germany - North of 52°20' N
DHDN_To_WGS_1984_6x          108209      Germany - Thuringen
DHDN_To_WGS_1984_7x          108210      Germany - Sachsen

In ArcGIS projection engine these are implemented as 7-Parameter Helmert-like transformations with the following parameters (except NTv2):

Naming               Code     Method            dx     dy    dz     rx       ry       rz     ds
DHDN_To_WGS_1984_1   1673     Coordinate_Frame  582    105   414    -1.04    -0.35    3.08   8.3
DHDN_To_WGS_1984_2   1777     Position_Vector   598.1  73.7  418.2   0.202    0.045  -2.455  6.7
DHDN_To_WGS_1984_3   15869    Position_Vector   612.4  77    440.2  -0.054    0.057  -2.797  2.55
DHDN_To_WGS_1984_3x  108206   Position_Vector   597.1  71.4  412.1   0.894    0.068  -1.563  7.58
DHDN_To_WGS_1984_4x  108207   Position_Vector   584.8  67    400.3   0.105    0.013  -2.378 10.29
DHDN_To_WGS_1984_5x  108208   Position_Vector   590.5  69.5  411.6  -0.796   -0.052  -3.601  8.3
DHDN_To_WGS_1984_6x  108209   Position_Vector   599.4  72.4  419.2  -0.062   -0.022  -2.723  6.46
DHDN_To_WGS_1984_7x  108210   Position_Vector   612.4  77    440.2  -0.054    0.057  -2.797  2.55

dx = x axis translation (meters)
dy = y axis translation (meters)
dz = z axis translation (meters)
rx = x axis rotation (arc-seconds)
ry = y axis rotation (arc-seconds)
rz = z axis rotation (arc-seconds)
ds = scale difference (parts per million, ppm)

(Source: ESRIS ArcGIS Documentation, ArcGIS 9.3.1, geographic_transformations.pdf)

My question is:
How are these things handled by Photoscan PRO?


General / Octree-Level
« on: August 14, 2013, 09:06:54 PM »

when creating meshes with arbitrary/smooth  a Poisson surface reconstruction is performed and PS tries to generate a water-tight surface. One important parameter that controls the richness of detail for the surface is the octree-level. While in other software packages like meshlab, cloudcompare, PCL etc this parameter can be set manually within a defined range, PS calculates it automatically.

I would lke to know which parameters this calculation is using, e.g. regionbox size in combination with local point density or similar criteria?

I really would appreciate to have this option under manual control.


Hi everybody,

we use coded targets as standard in close range photogrammetry, for which they work also fine in PS.

But I was wondering, if they may be also usefull  - time-saving - in aerial surveying with UAS and UL aircraft up to mid altitude like 700 to 1000 metres a. Gr.

I ran some simple tests with a 12 bit scheme and came to the conclusion that the coded targets should be imaged at least with 40x40 pixel, otherwise they are not recognized by the search algorithm.

Can somebody confirm this or has other experiences?


Pages: [1]