Messages

1

General / Reference Accuracy Values

« on: July 06, 2016, 06:05:49 PM »

Hi,

What is the correct meaning of the accuracy values for camera and marker location and orientation (.accuracy and .accuracy_ypr in python)?  Is it variance, stdev/sigma, 2stdev, "truth must be lower than this number"?  I'm trying to integrate some more accurate GPS data but it doesn't cover all of the photos, so want to be sure the different accuracy values are reasonable.

-John

2

Python and Java API / Set ground altitude

« on: January 06, 2016, 08:13:16 PM »

Hi,

In the Reference Settings dialog there's a ground altitude field that I understand is used for better preselecting images when aligning using reference coordinates.  Is there a way in 1.2.2 to set this via python?

3

General / How to use Vertical Datums?

« on: January 05, 2016, 12:19:32 PM »

Hi,

Can you help me understand how to use the new vertical datums feature in 1.2?  I have downloaded navd88-09.tif and placed in the geoids folder (on mac inside the PhotoScanPro.app package).  I have a project with reference entered in longitude, latitude, WGS84 ellipsoid altitude, using EPSG::4326. I can successfully Build DEM using any normal coordinate system, and a built in compound coordinate system like the "NAD83 + NAVD88 height EPSG::5498". 

However, all of the coordinate systems I use (US State Planes and UTM zones) don't have built-in entries.  So, to get one that's directly useful, I save the NAD83 + NAVD88 entry to a .prj file that looks like:

Code: [Select]

COMPD_CS["NAD83 + NAVD88 height",
  GEOGCS["NAD83",
    DATUM["North American Datum 1983",
      SPHEROID["GRS 1980",6378137,298.257222101,AUTHORITY["EPSG","7019"]],
      TOWGS84[0,0,0,0,0,0,0],
    AUTHORITY["EPSG","6269"]],
    PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],
    UNIT["degree",0.01745329251994328,AUTHORITY["EPSG","9102"]],
    AUTHORITY["EPSG","4269"]
  ],
  VERT_CS["NAVD88 height",
    VERT_DATUM["North American Vertical Datum 1988",2005,AUTHORITY["EPSG","5103"]],
    UNIT["metre",1,AUTHORITY["EPSG","9001"]],
    AUTHORITY["EPSG","5703"]
  ],
  AUTHORITY["EPSG","5498"]
]

I change only the top level name, the GEOGCS block, and remove the outer Authority block for a horizontal CRS that I want, like California State Plane Zone 3.  The resulting prj:

Code: [Select]

COMPD_CS["California Zone 3 + NAVD88 height",
  PROJCS["NAD83(HARN) / California zone 3",
    GEOGCS["NAD83(HARN)",
      DATUM["NAD83 (High Accuracy Reference Network)",
        SPHEROID["GRS 1980",6378137,298.257222101,AUTHORITY["EPSG","7019"]],
        TOWGS84[0,0,0,0,0,0,0],
        AUTHORITY["EPSG","6152"]
      ],
      PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],
      UNIT["degree",0.01745329251994328,AUTHORITY["EPSG","9102"]],
      AUTHORITY["EPSG","4152"]
    ],
    PROJECTION["Lambert_Conformal_Conic_2SP",AUTHORITY["EPSG","9802"]],
    PARAMETER["latitude_of_origin",36.5],
    PARAMETER["central_meridian",-120.5],
    PARAMETER["standard_parallel_1",38.4333333333333],
    PARAMETER["standard_parallel_2",37.0666666666667],
    PARAMETER["false_easting",2000000],
    PARAMETER["false_northing",500000],
    UNIT["metre",1,AUTHORITY["EPSG","9001"]],
    AUTHORITY["EPSG","2768"]
  ],
  VERT_CS["NAVD88 height",
    VERT_DATUM["North American Vertical Datum 1988",
      2005,
      AUTHORITY["EPSG","5103"]
    ],
    UNIT["metre",1,AUTHORITY["EPSG","9001"]],
    AUTHORITY["EPSG","5703"]
  ]
]

The VERT_CS part is totally unchanged.  I can import this, and PhotoScan recognizes the name of the new CRS and that it has a Vertical Datum.  However, when I try to Build DEM with this CRS, I get an "Unsupported vertical datum" dialog and a log message "Error: Vertical datum missing" in the console.  Clearly the datum is supported and present as the exact same VERT_CS worked before.

How is this supposed to work, or what am I doing wrong?  I can reproduce the exact same steps and error using python (and building PhotoScan.CoordinateSystems with strings instead of importing .prj files).  Given that there's at least one geoid on the website (Australia) that has no built in compound CRS entries, it seems like you must be able to build arbitrary combinations manually?

4

General / Re: Agisoft PhotoScan 1.2.0 pre-release

« on: September 09, 2015, 11:29:15 PM »

Hi, I'm hoping you can help me with the vertical datums feature, which will be a huge help.  I have a project referenced in WGS84 Lat/Lng and meters HAE, and would like to export it ideally in a state plane with NAVD88 feet.

I see that when I use the 'Convert' button in the reference pane, and pick the WGS84 + EGM96 geoid height, the z values all change to reasonable geoid heights in meters.  The value of "chunk.crs.wkt" changes to be a COMPD_CS with VERT_CS/VERT_DATUM components that make sense.  However, I can't seem to build my own PhotoScan.CoordinateSystem object with a vertical datum component.  Even trying to create a new CoordinateSystem with the WKT that was chosen automatically fails (with a non-pythonish error in the binding):

Code: [Select]

>>> PhotoScan.CoordinateSystem(PhotoScan.app.document.chunk.crs.wkt)
Traceback (most recent call last):
  File "<console>", line 1, in <module>
SystemError: NULL result without error in PyObject_Call

What I would ideally like to do is build a CoordinateSystem with something like the following, to get state plane data in US Survey Foot units in all three axes, and use it with chunk.exportDem.

Code: [Select]

COMPD_CS["California zone 4 NAVD88 ftUS",
  PROJCS["NAD83(NSRS2007) / California zone 4 (ftUS)",
    GEOGCS["NAD83(NSRS2007)",
        DATUM["NAD83_National_Spatial_Reference_System_2007",
            SPHEROID["GRS 1980",6378137,298.257222101,
                AUTHORITY["EPSG","7019"]],
            TOWGS84[0,0,0,0,0,0,0],
            AUTHORITY["EPSG","6759"]],
        PRIMEM["Greenwich",0,
            AUTHORITY["EPSG","8901"]],
        UNIT["degree",0.01745329251994328,
            AUTHORITY["EPSG","9122"]],
        AUTHORITY["EPSG","4759"]],
    UNIT["US survey foot",0.3048006096012192,
        AUTHORITY["EPSG","9003"]],
    PROJECTION["Lambert_Conformal_Conic_2SP"],
    PARAMETER["standard_parallel_1",37.25],
    PARAMETER["standard_parallel_2",36],
    PARAMETER["latitude_of_origin",35.33333333333334],
    PARAMETER["central_meridian",-119],
    PARAMETER["false_easting",6561666.667],
    PARAMETER["false_northing",1640416.667],
    AUTHORITY["EPSG","3496"],
    AXIS["X",EAST],
    AXIS["Y",NORTH]],
  VERT_CS["EGM96 geoid height",
    VERT_DATUM["EGM96 geoid",2005,
      AUTHORITY["EPSG","5171"]],
    UNIT["US survey foot",0.3048006096012192,
        AUTHORITY["EPSG","9003"]],
    AUTHORITY["EPSG","5773"]]
]

Thanks,
John

5

Python and Java API / Re: DEM Resolution for Imported Model is lower

« on: July 22, 2015, 08:35:52 AM »

Got it, thanks.  I guess importing was losing the depth_downscale value.  Looks like the model.meta has several interesting keys.

6

Python and Java API / DEM Resolution for Imported Model is lower

« on: July 15, 2015, 06:35:08 PM »

I am trying to export a generated model to PLY (but the format is flexible), make some changes, and then re-import it and continue with processing.  However, it seems that the automatically-chosen resolution for DEM export is much lower/worse after the model is imported.  This happens even if I make no changes and just import the exact same file that PhotoScan exported.

I have tried:
* PLY Binary
* PLY Text with a huge number of decimal places (10+)
* OBJ
* DAE
* Export local coordinates
* Export referenced (Lat/Lng as well as UTM)
* Export referenced with shift

Few questions:
* Is the import actually messing up the model precision, or just confusing whatever math you do to decide what resolution to pick by default?
* Are there known settings where this works better?  Happy to use those
* Barring that, is there a way that I can figure out PhotoScan's guess for DEM resolution before importing the edited model?  This is why I put this message in the python forum.  I know I could export the DEM before, use GDAL to get the pixel size, and then use those to export the edited model, but hoping for something less clunky...

Thanks,
John

7

Bug Reports / Python chunk.model.fixTopology() doesn't work.

« on: July 15, 2015, 06:14:30 PM »

In PhotoScan 1.1.5, given a model with topology errors (specifically duplicate/free vertices is what I was working with)

1) Choose tools, mesh, view statistics.  Note number or errors.  Click cancel.
2) In console, run the fixTopology function on the model.
3) The function thinks for a bit, but makes no changes
4) Go back to 'view statistics'.  Error counts have not changed.
5) Click "Fix Topology".  It thinks for a while.  The text output on the console is different than for fixTopology()
6) Go back to "view statistics".  Note that errors have been fixed.

Edit to add:  This is very low impact for me, just wanted to make you aware of it.

8

Python and Java API / Inverting Model

« on: June 04, 2015, 06:38:14 AM »

Hi,

I have a referenced model for which I would like to invert the Z value and export a referenced DEM in a UTM coordinate system.  The purpose is to get the height of the ground beneath overhangs like bridges.  I have tried to change the chunk's coordinate transform by doing:

Code: [Select]

chunk.transform.matrix = PhotoScan.Matrix.diag([1,1,1,-1]) * chunk.transform.matrix
This correctly flips the Z axis in the UI, but it also changes xy coordinates, and when I export the DEM the result is not correct/useful.  Using [-1,-1,-1,-1] keeps the georeferenced coordinates in the same general area, but the image is flipped and not usefully aligned.  What is the correct way to do this?  I don't think setting the projection in chunk.exportDem is useful because I need the output to still be georeferenced.

Thanks,
John

9

General / Re: Slight rotation in referenced model

« on: May 12, 2015, 12:19:58 AM »

No, I'm not using GCPs.  The source georeferencing on the images is very good (usually < .2 meters) but not passing orientation in (I think that PhotoScan doesn't use it even if you do provide?).

I'm looking right now to see if I can set up psuedo-gcps that can be used to correct elevation/rotation without altering the placement of the model in XY.

10

General / Slight rotation in referenced model

« on: May 11, 2015, 10:51:23 PM »

Many of the models we generate have a small rotation component to them.  I've attached a colorized DEM as an example - the ground (and especially the roof) is actually flat throughout the entire image.  I can't tell if this is due to drift in the GPS coordinates during the flight, the camera not pointing exactly straight down, or something else.  Any insight into the problem?