Messages

1

Bug Reports / importPoints does nothing when running headless

« on: May 28, 2019, 03:35:09 PM »

Hi Alexey,

I've run into a strange issue that seems to affect Metashape when running headless that I'm hoping you can help with.

I have a simple Python script that does the following (please ignore any small typos below as I've pulled out the relevant functionality to keep it brief.

Code: [Select]

    chunk = Metashape.app.document.chunk
    chunk.crs = Metashape.CoordinateSystem('EPSG::28356')
    chunk.updateTransform()
    format = Metashape.PointsFormat.PointsFormatLAS
    chunk.importPoints(path='/Users/guest/example.las',
                       format=format,
                       projection=chunk.crs
                       )
    chunk.updateTransform()
    chunk.resetRegion()
    Metashape.app.document.save('/Users/guest/test.psx')


When I run this code line by line via the Python console on Mac OS X, the pt cloud imports and is visible in the chunk.

When I run Metashape headless on Linux, I am left with an empty project with nothing in it. The operation otherwise seems to complete extremely quickly without logging any errors.

Metashape is run using the following system call

Code: [Select]

./metashape.sh -r my_script.py -platform offscreen
Any ideas why this could be happening?

I also noticed that the help documentation around metashape.sh does not seem to make any mention of the "-platform" option on Linux. Is there somewhere we can see the comprehensive list of options that "metashape.sh"?

Thanks,

J

2

Bug Reports / MetaShape caches python state?

« on: April 15, 2019, 08:50:22 AM »

Hi Alexey,

I'm run into a particularly frustrating issue where MetaShape (and PhotoScan versions prior) seem to not acknowledge script changes on Mac after script execution has failed at lest once.

The issue seems to be fixed by closing and re-opening MetaShape before running  a different script through the "run script" UI without raising an error. At this point the old script and arguments can be entered into the UI and the new code will run.

Does MetaShape do any caching of python resources? Is it possible to get hot-reloading support? As it stands currently it can be very misleading as errors in the console can be a result of flaws in old code that you have actually already fixed.

I hope this makes sense.

3

General / Re: GPU acceleration for tiled model generation

« on: March 29, 2019, 09:11:16 AM »

Hello jbak9141,

Tiled Model Generation procedure would utilize GPU for some sub-steps only when the reconstruction from the Depth Maps is selected as a source.

Great, thanks Alexey, will test it out now

4

General / Re: GPU acceleration for tiled model generation

« on: March 28, 2019, 07:50:59 AM »

Hey Alexey,

Just bumping this one, does this make any sense? We're expecting `chunk.buildTiledModel` to utilise GPU resources where it does not seem to at all.

Cheers,

J

5

Bug Reports / Re: Error: Empty DEM/Surface

« on: March 24, 2019, 04:58:05 PM »

Hello jbak9141,

Enabled Interpolation option is cropping the final surface according to the area visible from at least one aligned camera, if there is no camera alignment - there's no visible surface.

That makes perfect sense, thanks Alexey!

6

General / GPU acceleration for tiled model generation

« on: March 24, 2019, 04:56:45 PM »

Hi Alexey,

I've been running a few tests generating tiled models with GPUs enabled (4x Tesla M60) on my local test bench and don't seem to be able to get any noticeable speed improvements or utilisation at all from the GPUs? I noticed the PhotoScan manual mentions that this operation should be GPU accelerated but it seems to be CPU only?

Is there a caveat or condition I'm missing here to get PhotoScan to use GPUs for tiled model generation?

Cheers,

J

7

Bug Reports / Re: Error: Empty DEM/Surface

« on: March 21, 2019, 08:43:27 AM »

Hello jbak9141,

Try to use disabled interpolation to extrapolated option when building DEM.

Perfect thanks Alexey, that seems to do the trick, is there any info you can offer on why extrapolated is needed? Happy to use this option going forward but it seems a little counter-intuitive when compared to operations performed on dense clouds generated by PhotoScan itself.

8

Bug Reports / Error: Empty DEM/Surface

« on: February 28, 2019, 07:23:08 AM »

Hi there,

I'm trying to build a DEM off an imported point cloud and am running into all varieties of the "Empty X" error (eg: "Empty Surface, Empty: DEM" etc....

The point cloud has been imported from a LAZ that was exported by a separate PhotoScan project
The chunk is referenced in the same CRS as the incoming pt cloud (EPSG:32756 in this case)
The project has been saved in a psx format pre-attempting export
The point cloud is well within the bounding box
All surface generation flows produce the same "Empty DEM/Surface" errors.

Any help would be greatly appreciated.

Cheers

J

9

General / Convert crs slow on Linux

« on: May 08, 2018, 10:06:22 AM »

Hi Alexey,

I've been working a bit with PhotoScan 1.4.2 (build 6205) and have found that some functions perform inconsistently between Mac, Windows and Linux versions of PhotoScan.

For example, converting the chunk.crs via the GUI takes all of a fraction of a second on Mac/Windows, on my linux test bench however it takes between 5-10 seconds for a small project with <500 images. Running python scripts that use any of the CoordinateSystem transform methods or update camera/marker reference locations also run an order of magnitude slower on Linux compared to Mac/Windows.

Any ideas what could be causing this?

The Linux machine's specs are:

Agisoft PhotoScan Professional Version: 1.4.2 build 6205 (64 bit)
Platform: Linux
CPU: Intel(R) Xeon(R)
CPU family: 6 model: 85
RAM: 137.5 GB
OpenGL Vendor: VMware, Inc.
OpenGL Renderer: llvmpipe (LLVM 5.0, 256 bits)
OpenGL Version: 3.0 Mesa 17.2.8
Maximum Texture Size: 8192
Quad Buffered Stereo: not enabled
ARB_vertex_buffer_object: supported
ARB_texture_non_power_of_two: supported

Mac machine specs:

Platform: Mac OS
CPU: Intel(R) Core(TM) i7-4980HQ CPU @ 2.80GHz (laptop)
CPU family: 6 model: 70
RAM: 16.0 GB

Project used for testing in both was identical, reproducible in other project files as well.

Cheers,

J

10

Bug Reports / Re: points0.zip object in PSX files causes project files to be MUCH larger in v1.4

« on: October 23, 2017, 04:07:55 AM »

Hi Alexey,

Apologies for the slow reply, we've checked the application config file and the relevant settings under preferences and can confirm that keep key points is not toggled on. We notice that the points_0.zip is consistently the largest component of the project files and often up to 7 GB for datasets with ~1000 photos.

Is there any other way to confirm that the key point descriptors are being kept?

Cheers,

J

11

Python and Java API / Export all shape types to single DXF

« on: October 23, 2017, 04:05:49 AM »

Hi Alexey,

I've been experimenting with the exportShapes method and don't appear to be ablt to export a DXF with both polygon/polylines contours in the same file. I seem to only be able to specify a single shape type?

I'd like to be able to export both open and closed contours in the same file

Is there a way to replicate the old 1.2.6 behaviour where you could exportContours to DXF with all shape types included?

Cheers,

J

12

Bug Reports / points0.zip object in PSX files causes project files to be MUCH larger in v1.4

« on: October 16, 2017, 07:38:23 AM »

Hi Alexey,

I've been re-running a few old projects through version 1.4 and noticed that after doing the initial alignment, the project files are MUCH larger than what is produced in previous versions of Photoscan.

One set of project files which weighed in at 10's of megabytes now comes in at 2.9Gb. Smaller  projects are also an order of magnitude larger.

It looks like the points0.zip object in the project file tree which I presume stores the sparse point cloud is taking up all the space. These projects have only 1 chunk, <900 photos each and have been aligned once on high before saving the whole project.

Any ideas on why this file is so huge?

Cheers,

J

13

Bug Reports / Re: Generating texture or exporting OBJ causes PhotoScan to segfault?

« on: October 10, 2017, 08:38:52 AM »

Hi Alexey,

Can you please provide the processing log related to the mesh generation end export operations?

And please provide some additional information regarding the following steps:

- chunk.dense_cloud.assignClass[2]
- buildModel - HighFaceCount, HeightField, EnabledInterpolation, ElevationData, classes=[2]
- buildTexture - size=2048

The steps we followed are:

Assign all points to class 2 (Ground) in point cloud)

Buildmodel (we had originally used the elevation data source for this call but since tested with the dense cloud with the same results)

Build UV map and Build Texture

Here are the function calls for each step respectively:

chunk.dense_cloud.assignClass(2)

chunk.buildModel(
            surface=PhotoScan.HeightField,
            interpolation=PhotoScan.EnabledInterpolation,
            face_count=PhotoScan.HighFaceCount,
            source=PhotoScan.DenseCloudata,
            classes=[2]
)

chunk.buildUV(mapping=PhotoScan.AdaptiveOrthophotoMapping)
chunk.buildTexture(size=2048)

chunk.exportModel(
            output_file,
            format=PhotoScan.ModelFormat.ModelFormatDXF_3DF,
            texture=False,
            projection=chunk.crs
        )

We haven't submitted the crash report. What is the proper process for submitting these reports? Is there a way to configure PhotoScan to automatically submit crash logs to you when this happens?

We noticed that on the same project, exporting the DXF from the menu completes in half a second, making what we would expect to be the same call through the Python API takes upwards of an hour for the exact same chunk.

Is there something wrong with the way we're calling export Model?

We also stumbled upon a peculiar behaviour where specifying the callback function parameter in the export Model function causes it to take an order of magnitude longer than calling the function without the callback.

IE: The command below completes in a second for our test case

chunk.exportModel('test.dxf',
    format=PhotoScan.ModelFormat.ModelFormatDXF_3DF,
    texture=False)

While this command takes >10 seconds

chunk.exportModel('test.dxf',
    format=PhotoScan.ModelFormat.ModelFormatDXF_3DF,
    texture=False,
    projection=chunk.crs, progress=lambda arg: print(arg))

Is it possible that the callback is being called too frequently? We really only need this every few seconds or so.

Cheers,

J

14

Bug Reports / Generating texture or exporting OBJ causes PhotoScan to segfault?

« on: October 06, 2017, 03:26:12 AM »

Hi all,

I've been testing a small python export script to generate and export a model in various formats and have run into a few issues with the OBJ/texture.


Platform details, steps run and a few observations prior to the crash are as follows:

Platform details:

Agisoft PhotoScan Professional Version: 1.3.4 build 5067 (64 bit)
Platform: Linux
OpenGL Vendor: VMware, Inc.
OpenGL Renderer: Gallium 0.4 on llvmpipe (LLVM 4.0, 256 bits)
OpenGL Version: 3.0 Mesa 17.0.7
Maximum Texture Size: 8192
Quad Buffered Stereo: not enabled
ARB_vertex_buffer_object: supported
ARB_texture_non_power_of_two: supported

Steps run:

• buildDenseCloud - medium / aggressive / keep + reuse depth
• chunk.dense_cloud.assignClass(2)
• buildDem - DenseCloudData, EnabledInterpolation
• exportDem - RasterFormatTiles+ImageFormatTIFF, tiff_big=True
• buildOrthomosaic - ElevationData, MosaicBlending, color_correction=False
• exportOrtho - RasterTransformNone, RasterFormatTiles+ImageFormatTIFF, tiff_big=True
• buildModel - HighFaceCount, HeightField, EnabledInterpolation, ElevationData, classes=[2]
• buildTexture - size=2048
• exportModel - ModelFormatOBJ, texture=True, normals=False, colors=False, cameras=False

Observations:

 — Building the texture took much longer than expected. For a 402 image run, it took several hours. Nothing else intensive is running on the machine at all.
 — Exporting the model took MUCH longer than expected: projected times varied, but were in the hundreds of hours. I'm calling the export method with a callback and get the progress updates, which indicate that progress is about 0.25 percentage-units per MINUTE.
 — Except for these things, there is nothing really suspicious in the logs before the crash.
 — Some exports crash when they are a tiny tiny bit through (1% or 2%) and some get much longer (45%) before crashing. Some, the smallest ones, make it all the way through.
 — Not surprisingly, the texture takes longer to build with more photos/megapixels. However, while it takes seconds to minutes for tens of photos it seems to take many hours for hundreds of cameras, which is significantly longer than expected.   — Similarly the "exportModel" call seems to exhibit an even higher order of non-linearity.

For the two most recent tests using the same series of steps above I found the following:

 — A small run with 82 photos got to about 42% before crashing.
 — A larger run with 402 photos got to 0.55% before crashing.

Is there any known issue with the OBJ export, or a way to debug this further?


Cheers,

J

15

Python and Java API / Re: Python export contours

« on: October 03, 2017, 06:31:58 AM »

Hi Alexey,

Thank you for confirming, how do I export a DXF with both polygon/polylines contours in the same file using the Python API? I seem to only be able to specify a single shape type?

Having them split by default limits the usefulness of the function as both closed and open contours are needed for our workflow.

Cheers,

J