Messages

1

Python and Java API / Re: 2.2.0 BUG in `cameras` argument for xportCameras() with CamerasFormatXML?

« on: January 14, 2025, 07:22:00 PM »

Hi Alexey,

Explicitly passing the list of keys as you suggest produces the same result as passing the camera objects and letting them be implicitly converted to keys by the method. In both cases, the exported Alembic and FBX files contain the correct subset of cameras but exported XML files contain all of the cameras in the chunk.

Best,

2

Python and Java API / 2.2.0 BUG in `cameras` argument for xportCameras() with CamerasFormatXML?

« on: January 14, 2025, 03:57:27 AM »

I think Metashape version 2.2.0 may contain a bug in the usage of the `cameras` argument to exportCameras() that was added in version 2.1.3 for exporting a subset of a chunk's cameras.
 
If I want to export just the first 4 cameras in a chunk I would expect to write:

Code: [Select]

chunk.exportCameras("test_cams.xml", cameras=chunk.cameras[:4])
When I run that snippet the console reports the correct ids of the first 4 cameras in the chunk and seems to complete successfully, however, the resulting xml file still contains all of the cameras in the chunk.

Maybe this is just an issue with the default CamerasFormatXML though as writing to CamerasFormatABC or CamerasFormatFBX seems to correctly filter the cameras. I have not tested any of the other export formats. Note that using the class Metashape.Tasks.ExportCameras instead of chunk.exportCameras() also exhibits the same behavior.

3

General / Re: Quality report for aligning laserscans

« on: November 01, 2024, 06:33:30 PM »

I’d second Dieter’s assessment of the lidar support. At the moment, it’s not really adequate for laser scan registration. When we combine scans and photos it feels like we need to jump through quite a few hoops to make it work and prevent Metashape from messing  up our high quality existing scan alignments.

I don’t actually think it is a problem that Metashape isn’t good at lidar alignments, there are other good software packages for doing that. Rather than invest time on lidar alignment, I’d much rather have the Agisoft team improve the process for conforming the photo alignment to the lidar.

4

General / Re: Agisoft Metashape 2.2.0 pre-release

« on: October 29, 2024, 01:50:47 AM »

Some users need to be able to work completely offline, so that should be a consideration as well.

5

General / Re: Product release thread for notification purposes

« on: June 20, 2024, 07:32:09 PM »

Do you think, if it would be helpful, if we create a closed thread in general that will duplicate the Change Log information?

I would subscribe to that thread.

6

General / Re: Export Laserscans as E57 in structured format?

« on: May 22, 2024, 07:24:29 PM »

Did you try LAS?

How do you store structured scans in LAS?

7

General / Re: Transform Matrix is Translating Chunk to Incorrect Location

« on: November 01, 2023, 02:00:26 AM »

I'm not sure if this is the issue, but personally I would:

• Import into WGS84 Lat/Long chunk
• Transform chunk to UTM
• Export dense cloud
• Do external alignment
• Import transform from external alignment

That way you're only doing the transform from Lat/Long to UTM once and there is less room for things to go wrong.

8

Bug Reports / Re: TIFF/LAB files displayed in Black White only

« on: September 05, 2023, 09:40:25 PM »

any merging/processing operation happening inside is assuming sRGB, so colors won't be optimal even if you assign back the right color profile to the final texture.

Do you have a reference for that as it doesn't seem to match the testing I've done?

At least when working with scene-linear floating point images it is entirely possible to generate accurate texture maps without Metashape doing any color management. Admittedly, I haven't tested this with integer image pipelines, so I suppose they could be attempting to do some sort of color management and messing things up. That seems somewhat unlikely to me though, based on what I've seen working with both the applications UI and its Python API.

9

Bug Reports / Re: TIFF/LAB files displayed in Black White only

« on: September 02, 2023, 01:46:36 AM »

ACES is not well supported by many RAW processors.

You mentioned Affinity Photo earlier. Have you tried it? If I remember correctly Affinity's raw development uses libraw, which has had good support for ACES for quite awhile. I know Affinity also has good support for ACES in general via OCIO so that shouldn't be an issue either. For development from camera raw to aces (stored as exrs) we use OpenImageIO, which also uses libraw, and it works well. As long as they expose the appropriate settings, I think any of the other front ends that rely on libraw to do the heavy lifting should also work fine.

With regard to ICC profiles, I presume that was in reference to ProPhoto not ACES?

The good thing about using Metashape and a scene linear ACES based workflow is that even though the display transform inside of Metashape isn't quite right and your images will look a little funny inside the application the underlying pixel values aren't modified. If your source images are in the correct colorspace the resulting texture maps will be generated correctly in the same color space and will render properly once you move them to an application that is color managed. In other words, the fact that Metashape doesn't attempt to do ad-hoc color management (like some other applications do) makes it work well inside of a color-managed pipeline.

If I had one feature request to make in this vein it would actually be for Metashape to adopt OpenImageIO and OpenColorIO for image handling and color management. I imagine that could require a significant development effort depending on how the existing code is structured, but it would provide a number of benefits to users including support for non-RGB images like you're asking for, additional image formats including RAW for many cameras, color management, and the ability for users to do pretty sophisticated image math and compositing within the application.

10

Bug Reports / Re: TIFF/LAB files displayed in Black White only

« on: August 31, 2023, 06:31:14 PM »

ACES AP0 covers the entire CIE 1931 standard-observer spectral locus so theoretically includes all visible colors (and more) but still has all the tooling benefits of using a RGB based color space, including working more or less seamlessly in Metashape. However, even that seems a bit overkill for most photogrammetry processes and the more user friendly ACEScg (AP1) seems like a better working color space if you just want to have a wide gamut scene referred color space.

11

Bug Reports / Re: TIFF/LAB files displayed in Black White only

« on: August 31, 2023, 01:51:20 AM »

LAB is a reference color space AND a document format, means all visible colors are there.

What's the benefit of this when you're dealing with images captured by a physical device that can't capture all of those colors anyway?

12

Bug Reports / Re: TIFF/LAB files displayed in Black White only

« on: August 30, 2023, 02:37:55 AM »

If you're just after a color space with a wider gamut, why not try something like ACEScg (or ACES if you absolutely must cover the entire visible spectrum) that is already pretty well supported by Agisoft?

13

General / Re: Multiple Different cameras used in one scan - possible - normal results...?

« on: June 14, 2023, 05:49:00 PM »

Correct, I would not expect to see any significant differences with regard to the geometry. For multicamera rigs like this you usually want to end up with a different camera calibration for each physical camera so having them all be the same model doesn't necessarily help that much in that regard.

14

General / Re: Multiple Different cameras used in one scan - possible - normal results...?

« on: June 12, 2023, 05:40:41 PM »

The biggest issue you'll have with mixing different camera models is that the color balance from the different sensors will vary slightly. It may be a challenge to smoothly blend the texture maps without very carefully normalizing the images ahead of time.

15

General / Re: Undistort Images no longer an option?

« on: December 28, 2022, 08:12:16 AM »

The removal of the ability to export undistorted images from the GUI was discussed in this thread:

https://www.agisoft.com/forum/index.php?topic=14738

along with some workarounds. Hopefully, one of them will work for you.

I can't say I've ever used undistorted images as part of a workflow to transfer alignments to RC so I can't vouch for how well that works in particular. But by using the Python API, which still includes the ability to export undistorted images, we're able to export images that are identical to images exported by the GUI in older versions. We've also used STMaps exported from the latest versions of Metashape to undistort the original photos externally and produce undistorted photos that are identical so it should be possible to achieve what you're after.