Forum

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 - jbak9141

Pages: [1]
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 / 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

4
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


5
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

6
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

7
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


8
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

9
Python and Java API / Python export contours
« on: September 15, 2017, 09:12:28 AM »
Hi all,

I noticed the exportContours() method no longer exists in the PhotoScan API, is there a way to export contours through the python API anymore?



10
Python and Java API / PhotoScan WKT Support
« on: July 21, 2017, 08:42:29 AM »
Hi Alexey,

I've been trying to define a Local CRS projection file using a WKT string in a ".PRJ" and am running into a few issues loading the example file attached.

Can you confirm if PhotoScan supports WKT strings with a projection followed by one or more affine transformations (possibly using CONCAT_MT)?

If so, do you have an example?

Any advice would be greatly appreciated.

Cheers




Pages: [1]