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

Pages: [1]
Python and Java API / Please make the API more stable
« on: October 19, 2022, 05:02:51 AM »
One of the best things about Metashape is that it offers a complete Python API. However, that API is unnecessarily frustrating to use for 2 main reasons:

The first is documentation, which although it exists is rather minimal and very difficult to navigate due to being delivered as a pdf with no useful table of contents. An interactive webpage similar to would be much easier to use.

The second big cause of frustration is how much churn there is in the API. Right now while looking at the 2.0.0 changelog I see this:

  • Renamed PointCloud class to TiePoints
  • Renamed DenseCloud class to PointCloud

and can only imagine how much pain that is going to cause people who don't have their scripts version guarded. Now arguably, this is a major release so it is the right time to make these kinds of breaking changes. However, it seems like these kinds of breaking changes happen in almost every new version, including minor X.X.1 patch releases. For example 1.7.4 includes `Renamed ClusteringMethod enum to ClassificationMethod`. Searching for "Renamed' yields 177 hits in the changelog and that's just the beginning as there are many other breaking changes that were documented in other ways, i.e. removal of methods and functions, changing default arguments, and sometimes completely changing the way a method or function behaves.

Agisoft doesn't even attempt to keep their own example scripts up to date. When 1.8.0 was released, it appears they simply bumped the version number check on all the scripts in their example repo,

without actually updating the scripts for any of the changes in that release and as a result many of those scripts have probably been broken for months.

Which brings me back to documentation. Because the written documentation is so sparse the best way to learn the Metashape API is via examples and experimentation. However, because the API is constantly changing many of the examples, both in public repos and in snippets on this forum are out of date and it is often difficult to figure out how to port them to the current API. That leaves experimentation, which is often needlessly time consuming and frustrating.

My 3 suggestions for how to improve this situation would be:
  • Follow semantic versioning, i.e. given a version number MAJOR.MINOR.PATCH, backwards compatibility can only be broken in a MAJOR release.
  • Test that provided example scripts are compatible with the currently released version. This will help users stay up to date on best practices, while helping assure that point 1 is being adhered to.
  • Move written documentation to a more usable platform than the pdf currently provided.

Please consider these suggestions to improve the stability and user friendliness of Metashape's API. I love the fact that Metashape provides such a detailed API, and we likely wouldn't be users if it didn't, however, its instability is a major hinderance and greatly reduces our ability to test and deploy new versions of the software.

Python and Java API / Undistorting images with ConvertImages class?
« on: March 08, 2022, 09:50:31 PM »
I noticed that the Python release notes for 1.8.1 include:

• Removed fix_pixel_aspect, fix_principal_point, and remove_distortions attributes from ConvertImages class

Does that mean that the ConvertImages class can't be used to create undistorted images anymore? If so what is the recommended way to do that, both via the API and the GUI?

The current version of Metashape 1.7.1 build 11797 fails to use GPUs for depth map generation with the same settings that succeed with 1.6.5 build 11249. This was reported in the pre-release thread in the following post:

I can't seem to use GPU for depth map generation.  I get the following error:

Warning: Device GeForce GTX 1070 Ti ignored because it has 5958/8192 MB available, but 6870 MB required

We're using different GPUs (2080 Ti, driver version 461.40), but get the same error message, albeit with different VRAM values. Presumably, we're also using different size images than the original reporter. Nonetheless, opening the project files that produce this error in version 1.6.5 on the same machine allows us to utilize the GPU for depth map generation. Choosing a lower quality reconstruction in 1.7.1 also uses the GPUs for depth map generation.

The suggested workaround in the pre-release thread:

of setting main/depth_pm_max_neighbors = 40 does not seem to be possible any longer, however, from inspecting the logs it appears that processing is automatically limited to 40 neighbors in this version automatically.

Bug Reports / Scene linear color spaces are handled incorrectly
« on: August 10, 2013, 04:32:22 AM »
I apologize in advance for the long post, but color space issues are always confusing so I'm trying to be as detailed as possible. All testing was on done Windows 7 with version 0.9.1 build 1714.

PhotoScan currently applies some undocumented, lossy, colorspace transformation to OpenEXR images. This makes it almost useless for generating HDR textures. To illustrate the problem I've provided several sample files at:

DSC_0721_lnh.exr ( is the original scene linear source file that has been normalized following the standard convention where an 18% gray card has a luminance value of 0.18. Note that the brightest pixels in the image occur in the specular reflections on the upper left corner of the ColorChecker's frame and have luminances of ~1.4.

ps_color_test.psz ( is a minimal PhotoScan project where all that has been done is loading DSC_0721_lnh.exr. ( is a python script that, when run from within the above project, takes the source image and immediately saves it to DSC_7021_copied.exr then undistorts it and saves it to DSC_7021_undistorted.exr. As expected these two output images are very similar with the mean difference between pixels being ~0.002. However, They are vastly different from the source image.

The image at the bottom of this post shows the difference between the source and output images after conversion to sRGB for display using oiiotool:

Code: [Select]
oiiotool DSC_7021_lnh.exr --tocolorspace sRGB -o DSC_7021_srgb8.jpg
oiiotool DSC_7021_copied.exr --tocolorspace sRGB -o DSC_7021_copied_srgb8.jpg

Note how closely the pixel values of the Neutral 5 patch in the source image match the nominal sRGB values provided by x-rite ( and how much different they are in PhotoScan's version.

There are at least two major problems with the EXR files generate by PhotoScan.
  • The highlights have been clipped. The output file is clipped to the range 0-1, however, even pixels that were well below 1 in the original image, for example the white strap behind the ColorChecker, have also been clipped.
  • An undesired gamma correction of ~2.2 seems to have been applied at some point during PhotoScan's color pipeline as I can get closer to the correct colors by applying the inverse (0.455). This would be less of an issue if it weren't for #1. As long as the transformation was known it could be losslessly reversed if the data hadn't been clipped.
There are also a couple of more minor issues with the EXR output. First the original 16-bit half float image was promoted to a 32-bit float, which is probably not needed for most image data. If so much data had not been destroyed during the color conversions the size of the output image (61 MB) would have nearly doubled relative to the source image (37 MB). Finally, all of the metadata in the original EXR was destroyed, although this is probably less important in the typical workflow where PhotoScan is creating an image from scratch.

It would be great if Agisoft can fix these issues, ideally by letting a well tested third party library such as OpenColorIO handle color conversions.

Bug Reports / Incompatible Qt libraries iwith 0.9.1 build 1714 on Linux
« on: August 10, 2013, 02:04:05 AM »
On a Debian Testing system running KDE attempting to launch build 1714 fails with the error message:

Code: [Select]
Cannot mix incompatible Qt library (version 0x40805) with this library (version 0x40804)

Adding the line:
Code: [Select]
to allows the program to launch.

General / Ring Flash
« on: March 26, 2013, 07:10:47 PM »
I'm curious if anyone has had any success (or failures) using a ring flash for illumination.

I'm looking at a potential project where I'm not sure static off-camera lights are practical and it seems like a ring flash might be an option for surfaces without to much depth variation.

Feature Requests / Forum improvements
« on: February 18, 2013, 08:52:34 PM »
I've been trying to follow this forum using its RSS feed. Unfortunately, the feed only includes the first line or two of each post's body so I have to constantly keep coming back to this site if a post looks like it might be interesting. It kind of defeats the purpose of having an RSS feed.

Feature Requests / Multiple 3D Models per Chunk
« on: February 05, 2013, 12:31:05 AM »
I often find myself wishing I could have more than 1 3D model associated with each chunk. At any given time I may want to have available one or more of: dense point cloud, low-poly mesh, high-poly mesh, edited and raw versions of all of the above. Constantly having to manually save and load them from disk while trying to remember which "3D Model" is currently present in the project gets a bit tedious.

Feature Requests / Python API improvements
« on: February 05, 2013, 12:15:47 AM »
Over the last few days I've been working on integrating PhotoScan with our existing laser scanning and photogrametry workflows. In general I'm impressed and things have gone quite smoothly, however, there are a number of improvements to the Python API that would make things even better. Some of these might be considered bugs but rather than making separate threads, I've consolidated my suggestions below, in no particular order.

  • Use a different hyperref level when generating the PDF documentation so that bookmarks are usable for finding subclasses of PhotoScan. An index with more than 1 entry might be useful too.
  • EXIF data does not seem to be accessible from Python without installing a third party library.
  • A convenience attribute such as PhotoScan.Camera.markers would be useful for getting a list of markers that project on to a specific image without looping over all markers in a chunk.
  • Depending on the values of center_principal_point and square_pixels, the image produced by PhotoScan.Image.undistort may have a different camera matrix than the source image. It would be useful for the method to return the new matrix in addition to the undistorted image. The values for cx an cy are fairly obvious, while the values of fx and fy are not.
  • Specifying a hint for the PhotoScan.Application.get* methods dealing with files and directories doesn't seem to have any effect. The hint should probably be used as the title for the dialog window that pops up.
  • When using the PhotoScan.Application.get* methods for opening and saving files it should be possible to specify a list of file extensions that can be used to filter the list of files in the file selector dialog.
  • On Windows using the PhotoScan.Application.get* methods for opening and saving files and directories always seems to start in PhotoScan's installation directory. On Linux previously accessed directory locations do seem to be remembered correctly.
  • Additional data entry widgets, e.g. dropdown lists, check boxes, radio buttons etc. would be nice to have. TraitsUI does this nicely
  • Make it possible to add scripts to custom menus and toolbars so they appear as full-fledged tools.

Pages: [1]