Messages

1

General / Re: historic aerial frames, same pixel dimensions, fiducials slightly different

« on: March 27, 2020, 02:15:26 PM »

First, which country, agency/company and camera? I have some archive camera calibration reports and you never know, they might match...!

Second, the variations you report (0.2 and 0.5 mm)... are these with reference to the [assumed] principal point?

Andy

2

Camera Calibration / Clarification regarding Calibrate Fiducials

« on: March 20, 2020, 01:08:12 AM »

Am I correct in guessing that Calibrate Fiducials assumes the fiducial marks are symmetrical (equidistant from the principle point) and uses the given scan resolution to calculate their approximate coordinates? Is this done on a per-image basis, or use means (or some other statistic) if multiple images are selected together (therefore more representative coordinates)? I'm just seeking some clarification please. 

If this is correct it'd be great to add such to the manual for future reference.

Many thanks

Andy

3

Feature Requests / Calibrate Fiducials: um & dpi options

« on: March 20, 2020, 12:56:23 AM »

When using Calibrate Fiducials it would be wonderful to have the options to input the scan resolution in um (microns) and dpi please.

Many thanks

Andy

4

Feature Requests / 2D/horizontal (x,y) vs. 1D/vertical (z) markers and accuracy

« on: June 19, 2019, 05:38:04 PM »

There may be a way of doing this which I haven't yet discovered (please provide instructions if there is) but we really need a means creating 2D (i.e. horizontal) markers... i.e where only x,y coordinates were able to be measured. Also, where 3D markers are used (i.e. the only kind of marker I'm aware of in the current version) it would be very useful indeed to differentiate between 2D/horizontal (x,y) and 1D/vertical (z) marker accuracy, as the two are often very different indeed (e.g. when using GNSS to survey marker locations). Using just one overall Accuracy for each marker is very limiting when it comes to bundle adjustment with markers surveyed by different means or in different conditions.

5

General / Re: Patches of high/low areas in point cloud of terrain

« on: March 02, 2018, 07:36:21 PM »

I can't export as XML, when when I import the same XML nothing appears (there are no error messages either)...

6

General / Re: Patches of high/low areas in point cloud of terrain

« on: March 02, 2018, 04:56:36 PM »

Here it is: http://www.mediafire.com/file/lb3luqhv8gf54rb/Report%20for%20OS%201982%20vertical%20aerial%20photographs%20March%202018.pdf

7

General / Re: Patches of high/low areas in point cloud of terrain

« on: March 02, 2018, 01:54:33 PM »

I'm revisiting this thread because, unfortunately, I was never able to get rid of these artifacts. I'd hoped that new versions might provide a fix (I'm now running 1.4.1) but to no avail. I followed the instructions in the previous post to the letter, but with no improvement.

8

Feature Requests / Ingest *.vrt and *.geom metadata for images automatically

« on: November 08, 2017, 01:28:40 PM »

The *.geom and *.vrt formats are becoming ever more popular for photo station ephemeris, camera models and RPC, not least in the airphoto sector. With 1000s of images having to be processed it is impractical to add this data manually. Can PhotoScan be updated to automatically recognise and import this data please?

Many thanks

Andy

9

General / Using *.geom for ephemeris and camera model for images?

« on: November 08, 2017, 01:25:08 PM »

I have a bunch of vertical and oblique airphotos I wish to use in SfM (*.jpg as it happens). Each one has a *.geom file, which appears to contain the photo station ephemeris data and the camera model for each. My question is, how can I automatically add all this metadata into PhotoScan. I have 1000s of images and doing it manually is not practical!

Many thanks in advance.

Andy

10

General / Re: Using *.vrt for ephemeris/RPC of oblique airphotos?

« on: November 08, 2017, 01:21:43 PM »

No thoughts on this from anyone, including the AgiSoft ream??? 

11

General / Using *.vrt for ephemeris/RPC of oblique airphotos?

« on: October 27, 2017, 07:37:17 PM »

I'm using oblique airphotos acquired by NOAA and made freely available as TIFF here:

https://geodesy.noaa.gov/storm_archive/coastal/viewer/index.html

Each TIFF comes with an associated *.vrt file... a format I'm not familiar with. To me it appears to contain ephemeris/RPC.

I want to generate geo-referenced point clouds, as well orthophotos from multiple TIFFs. Is there a way for importing the information from the VRT files into PhotoScan for this purpose (therefore with no GCP required)?

12

General / Copying markers between chunks

« on: April 29, 2017, 07:25:43 PM »

My project needs to be processed as several chunks. In the first chunk I have spent a lot of time carefully placing and naming a LOT of markers (non-georeferences, i.e. no XYZ coordinate, I just want to use them to align my chunks). How can I copy markers from one chunk and use them in another (granted, I'll have to place them all again in the photos, which is the whole point, but I won't have to carefully name each one over and over for each of my multiple chunks)...

13

General / Re: Patches of high/low areas in point cloud of terrain

« on: December 20, 2016, 08:56:46 PM »

BTW, before any culling of tie points none of them have a Reprojection Error exceeding 0.7

14

General / Re: Patches of high/low areas in point cloud of terrain

« on: December 20, 2016, 08:54:42 PM »

With those settings I get 6000+ tie points remaining, from an initial 11000+. When viewing the points on the photos they are also well distributed.

I've tried creating a dense point cloud without culling any points (i.e. the full 11000+) and I get the same patch features.

15

General / Re: Patches of high/low areas in point cloud of terrain

« on: December 20, 2016, 06:53:03 PM »

Here is the report:

Code: [Select]

# Cameras (4)
# PhotoID, X, Y, Z, Omega, Phi, Kappa, r11, r12, r13, r21, r22, r23, r31, r32, r33
os_82033_v_007.tif   385919.2062696178900000   80746.1490088077700000   2427.9801713772022000   0.7060472463219131   0.2065422957097703   107.2342390549936500   -0.2962769314526411   0.9550158037652961   0.0128372289662858   -0.9550952753791041   -0.2962987877252764   -0.0002081851235714   0.0036048352973428   -0.0123224571842452   0.9999175777089938
os_82033_v_008.tif   386584.1999433031300000   80927.3854616020980000   2425.6020255756343000   -0.5128383450749853   -0.4169149396235561   105.5489794258962300   -0.2680549433469141   0.9633456018838577   -0.0105734894103801   -0.9633761468246594   -0.2681140473115296   -0.0046105708435342   -0.0072764741843152   0.0089503611804028   0.9999334697659568
os_82047_v_412.tif   386081.3126213328800000   81161.9456559692480000   2431.9811098230434000   -0.2335982434049884   -0.6860605727900033   91.5673559836439070   -0.0273501499821671   0.9996162176851944   -0.0044030258572207   -0.9995542001773864   -0.0274006826591848   -0.0118576345683536   -0.0119737297321647   0.0040767549051963   0.9999200017330107
os_82047_v_413.tif   386693.7980145422600000   81184.8961358359810000   2436.3725434047310000   -0.0936927697184504   -0.1114061128241012   92.0538592661327900   -0.0358388622876644   0.9993561290843859   -0.0017038812747297   -0.9993556900572562   -0.0358420596531271   -0.0018845450398761   -0.0019444022504265   0.0016352434969241   0.9999967726340895