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