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.


Messages - andyroo

Pages: [1] 2 3 ... 32
1
I've started experimenting with coalignment of aerial lidar and SfM and I'm seeing some intriguing results but it's painful and time-consuming to explore at scale because point clouds are imported one-at-a-time even in network mode, so it can take several hours to import a survey with 100-200 tiles. Since the laser scan point clouds are distinct entities it seems like this maybe could be parallelized? I realize that my perspective may be overly simplistic, but thanks for considering...

2
I still have this question.

3
I've been working with aerial lidar data and I'm trying to import a fairly large project divided into ~1km blocks. During import I am getting these "bad allocation Retry Processing?" dialogs that pop up and freeze import (see screenshot) but seem to be resolved when I hit "continue". I also noticed that I see in the import log messages,

"Working in temporary directory C:/<redacted>/AppData/Local/Temp//import_points.tmp
Importing point cloud in memory. Save project in .psx format for big file import.


Would it speed up import and potentially avoid these msgs if a .psx was created/saved before importing?
Would it speed up import if there was a SBET? (not possible for many older projects).

4
I would love to be more easily able to view matches, especially for the new matching with laser scans.

If you could add something like "all laser scans" or "totals per laser scan group" (and per camera group) options in the top of the first "view matches" dropdown (like there is for "all images"), that would be useful for me. For now, in order to see valid matches between scans and images I have to manually (1) widen the "view matches" window to see valid matches, (2) sort descending by valid matches, (3) scroll down to the laser scans at the bottom of the images, then scroll to the top of that scan to see the highest valid matches, then examine each scan to see the same.

Also would love to see an elevation/distance heatmap instead of just black for the laser scans (I'm using lidar clouds with no trajectory info) and API access to these matches.

5
I'm doing some testing on the new option in 2.3 to Align Laser Scans/ Match depth maps to co-align imagery with individually fixed laser scans in a fixed group.

I noticed that after I do the initial align and filter points by Reconstruction Uncertainty and Projection Accuracy, I end up with the same matches even if I re-align with a different resolution for the scan/photo depth maps and different numbers of key points.

In other words, if I align matching depth maps on Ultra high/highest with 400,000 and 40,000 for my kp limits, and end up with 161 matches, filtered to 72 with Reconstruction Uncertainty, then 1 match with Projection Accuracy, then I attempt an alignment at high/high with 100,000 and 10,000, I see that new depth maps are generated, but the match and align stages take basically no time, and I end up with 1 match again. This happens regardless of whether I select "keep depth maps"

It seems like the only way to attempt a new photo-to-laser scan alignment is to start with a new copy of the chunk. Is there any way to reset this in the API or doing something I haven't figured out yet in the GUI? I haven't figured out how to do anything with chunk.tie_points.projections_3d but it seems like maybe I need to delete them? And I don't see a corresponding component in the GUI for the chunk either.

6
I noticed that in batch operations I can't set the photo-matching/depth-map options in the "align laser scan" method. Would love to have that feature

7
Bug Reports / Error: vector_sub_Ab: wrong dimensions (v2.1.4)
« on: December 17, 2025, 03:39:04 AM »
This is a new one to me. Seems like it happened on the " (3 px, 2 3d) sigma filtering" step?

Aligning 37841 images from a multi-camera downward-looking rig with 4 cameras in a triangle config. Separate camera configuration and lever arm offsets with precise positions. Last bit of processing log:

...
2025-12-12 21:53:52 adding 56196 points, 16 far, 55186 inaccurate, 73 invisible, 7 weak
2025-12-12 21:53:52 adjusting: xxxxxxxxxx 1.78046 -> 1.77809
2025-12-12 21:53:52 adding 55222 points, 4 far, 55427 inaccurate, 67 invisible, 40 weak
2025-12-12 21:53:52 optimized in 0.271 seconds
2025-12-12 21:53:52 adding camera 15 (104 of 104), 106 of 175 used
2025-12-12 21:53:52 adding 55986 points, 9 far, 55806 inaccurate, 68 invisible, 12 weak
2025-12-12 21:53:52 removed 1 cameras: 21
2025-12-12 21:53:52 removed 1 stations
2025-12-12 21:53:52 removed 1 points
2025-12-12 21:53:52 adjusting: xxxxxxxxxx 1.80638 -> 1.80506
2025-12-12 21:53:52 adding 55202 points, 4 far, 55376 inaccurate, 62 invisible, 37 weak
2025-12-12 21:53:52 optimized in 0.283 seconds
2025-12-12 21:53:52 (3 px, 2 3d) sigma filtering...
2025-12-12 21:53:52 removed 4 cameras: 46, 52, 73, 98
2025-12-12 21:53:52 removed 4 stations
2025-12-12 21:53:52 removed 1 points
2025-12-12 21:53:52 adjusting: xxxxxxxxxxxxxxxxxxxx 1.80006 -> 1.79717
2025-12-12 21:53:53 point variance: 1.75717 px, threshold: 5.27151 px
2025-12-12 21:53:53 adding 51076 points, 3 far (5.27151 px threshold), 51317 inaccurate, 58 invisible, 29 weak
2025-12-12 21:53:53 removed 1 cameras: 24
2025-12-12 21:53:53 removed 1 stations
2025-12-12 21:53:53 adjusting: xxxxxxxxxxxxxxxxxxxx 1.83959 -> 1.8383
2025-12-12 21:53:53 point variance: 1.77447 px, threshold: 5.32341 px
2025-12-12 21:53:53 adding 50695 points, 8 far (5.32341 px threshold), 50939 inaccurate, 47 invisible, 33 weak
2025-12-12 21:53:53 adjusting: xxxxxxxxxxx2025-12-12 21:53:54 Error: vector_sub_Ab: wrong dimensions
Saving project...
2025-12-12 21:53:56 saved project in 2.08 sec
2025-12-12 21:53:56 Finished batch processing in 22398.5 sec (exit code 1)

8
Hi MarinK,

What was the computer issue? Was it a hardware problem?

9
Bug Reports / Re: error: wrong jacobian size (v 2.2.2)
« on: September 30, 2025, 11:24:56 PM »
Hi Alexey,

I already shared a link for a zip with you (to support email) before I read this. The zip has an image folder and psx with 5 frames from the 4-camera rig in a multi-camera chunk and generates the error when you try to align. I was able to load the cameras to individual independent calibration groups with the same markers and scale bars and get them to align (not well) without error. Also if you export/import markers/cameras in xml format from the reference pane you should see the "invalid format" error I was talking about. I can only export and import markers by using export/markers and import/markers from the file menu.

Andy

10
Bug Reports / Re: error: wrong jacobian size (v 2.2.2)
« on: September 29, 2025, 09:40:12 PM »
This seems to be related to marker export/import from different camera setups (I was trying to avoid manually placing markers again).
Are you able to reproduce the issue on smaller subset of original imagery?
I can reproduce the issue with 5 sets of 4 images.

In the chunk with the jacobian size error, I imported markers from a chunk with the same set of images, but  with each camera loaded separately and configured with an independent camera model in the camera calibration dialog. The chunk had been aligned.

I tried to export markers from the "independent" chunk and and import markers to the "multi-camera" chunk from the reference pane but got a "invalid format" message when importing, so I exported from one chunk and imported to the other with file/export/markers and file/import/markers.

What parameters you are using for Align Photos command and whether you can share the log with the error?
Alignment (no image positions):
Accuracy: High, generic preselection checked, kp limit 60000, tp limit 0, everything else unchecked.
Markers checked and scalebars checked: Alignment fails
Markers checked and scalebars unchecked: Alignment succeeds

I am aligning with no image coordinates, and using estimated coordinates for markers on the calibration plate (local coordinates). The coordinates were imported from estimated coordinates from a previous metashape project with a DSLR, which we used to validate the measurements of our machined measurements (scalebar values) on the calibration plate.

I can share the log but I don't think it's very informative. I'm guessing the relevant part to see where it's happening is:

#start of log excerpt
evaluating initial pair...
initial pair evaluated in 0.015 sec.
initial pair unstable, considering additional pairs.
additional pairs considered in 0 sec.
optimizing initial pair...
Finished processing in 3.994 sec (exit code 0)
Error: Wrong jacobian size

11
Bug Reports / error: wrong jacobian size (v 2.2.2)
« on: September 26, 2025, 11:22:25 PM »
Hi Agisoft folks!

I'm evaluating test data from a multicamera mapping system with 4 cameras (this system).

I was able to process 3880 images (no GPS data) loaded to individual camera calibration models in a "normal" project, but when I loaded them as 970 multi-camera images ("as folder"), I get a "wrong jacobian size" error during alignment. In camera calibration initially I enabled the "adjust offset" option for slave camera position/rotation but did not indicate an initial reference. I tried again after estimating the camera positions and rotations and entering them based on rough measurements (still allowing to adjust) and got the same error.

I am processing on Win11 with a Dell Precision 7680 w/ 64GB RAM and a NVIDIA RTX 2000 with Metashape 2.2.2 and all the latest drivers as of a couple weeks ago. It looks like it holds pretty steady at about 20% RAM used, and it didn't look like the GPU was choking either.

The only non-standard thing I did(?) is to load the markers after exporting from the non-multicam project because I didn't want to re-place them.

**potentially another bug** I tried exporting markers in xml format from the reference frame on the non-multicam project and re-importing them to the multicam project and I got an error that was something like "invalid format" - so I exported markers from file/export, then imported from I think the reference pane, and it worked.


12
Just had a colleague ask me if I knew a way to have more than one node process if you're doing a partial realign, or adding to existing alignment, so I pointed them to this thread and figured I'd bump.

13
On a related note, the default region for the full realign was a random disconnected group (part?) of about 2,000 pts that was so far from the other 47 million points that they were a dot.

Seems like (1) that should have been another disconnected component, and (2) if you have a component that has disconnected parts composed of (a) points derived from cameras with positions (b) points derived from cameras with no position, then the default region should be around the point group with positions.

14
Metashape 2.1.4, Network processing, 6 camera groups, each with their own camera calibration model.

Is it expected behavior that, if you do a partial alignment/optimization and keep keypoints, then align additional images without resetting alignment, the whole alignCameras portion will run on a single node, while if you do a complete realignment, it will use all nodes (except for the alignCameras.finalize and a few other steps I think)?

Also, because I optimized, some tiepoints were eliminated from the original alignment (only 1.9m remaining) - I'm wondering if that played a role in the much lower number of total tiepoints found without resetting alignment.

Ideally for me both of the scenarios below would run in about the same time:

I have a project with about 15000 images and about half with positions. I aligned and optimizes the half with positions (keep keypoints = true), then added the images without positions and aligned again in two ways, using the batch operation in GUI:

1) reset current alignment = No**
2) reset current alignment = Yes**

In both projects, matchPhotos was fast and multi-node.

In the reset alignment = No project, the alignCameras portion used a single node and took about 60 hours, resulting in a total of 16,143,850 tiepoints (1 component with no subparts, 13780 of 14520 images aligned)

In the reset alignment = Yes project, the alignCameras portion used all nodes and took about 8 hours, resulting in a total of 47,915,643 tiepoints (3 components* 13756 of 14520 images aligned)

*component 1 had 13,756 cameras, 47.9m tie points and 2 parts, each of which had a "part tree" with many subparts
*component 2 had  56 cameras and 83k tiepoints (no parts)
*component 3 had 4 cameras and 800 tiepoints (no parts)

**remaining settings were the same (Accuracy = High, Generic preselection = Yes, Reference preselection = Source, Keypoint limit = 60,000, Tiepoint Limit = 0, Exclude stationary tiepoints = Yes, Guided image matching = No, Adaptive camera model fitting = No)

Thanks for any insight!

Pages: [1] 2 3 ... 32