Meshroom icon indicating copy to clipboard operation
Meshroom copied to clipboard

[bug] Error on node "FeatureMatching" after feature file concatenation

Open KevinDepedri opened this issue 1 year ago • 0 comments

Describe the bug I am trying to perform a 3D reconstruction with an augmented number of keypoints and descriptors, exploiting the same set of images in 3 different color bands (band1, band2, band3). More in detail, the reconstruction will need to rely on band3 images, but using the joint features extracted from band1 and band2.

The problem occurs when running the FeatureMatching node after joining the features. Indeed, as soon as that starts, I get the following error (as you can see in less than 2 seconds):

1/1 (1/2) FeatureMatching commandLine: aliceVision_featureMatching --input "/path_to_run/output_sift_ultra_ultra_GPU_0toNone/CameraInit/0310d6c605b30ab0a07a6218478dcbd2aec8fedf/cameraInit.sfm" --featuresFolders "/path_to_run/output_sift_ultra_ultra_GPU_0toNone/FeatureExtraction/9c5d37075118d0a9c4bf069fe301efde523d5973" --imagePairsList "/path_to_run/output_sift_ultra_ultra_GPU_0toNone/ImageMatching/b1731e47a010096be3dff4f02ab88b2810a348d0/imageMatches.txt" --describerTypes sift --photometricMatchingMethod ANN_L2 --geometricEstimator acransac --geometricFilterType fundamental_matrix --distanceRatio 1.0 --maxIteration 4096 --geometricError 0.0 --knownPosesGeometricErrorMax 5.0 --minRequired2DMotion -1.0 --maxMatches 0 --savePutativeMatches False --crossMatching False --guidedMatching False --matchFromKnownCameraPoses False --exportDebugFiles True --verboseLevel trace --output "/path_to_run/output_sift_ultra_ultra_GPU_0toNone/FeatureMatching/3fe91045d9c7c8f247ce854f21817ca51832063e" --rangeStart 0 --rangeSize 20

logFile: /path_to_run/output_sift_ultra_ultra_GPU_0toNone/FeatureMatching/3fe91045d9c7c8f247ce854f21817ca51832063e/0.log ERROR CODE: -11 [2024-02-15 17:18:32,599][INFO] - elapsed time: 0:00:01.281256 [2024-02-15 17:18:32,600][ERROR] Error on node computation: Error on node "FeatureMatching_1(0)":

[2024-02-15 17:18:32,600][WARNING] Downgrade status on node "FeatureMatching_1(1)" from Status.SUBMITTED to Status.NONE Traceback (most recent call last): File "/path_to_py_file/meshroom_fused_reconstructor.py", line 684, in fused_rec.build_and_run_graphs() File "/path_to_py_file/meshroom_fused_reconstructor.py", line 283, in build_and_run_graphs executeGraph(self._fusion_graph) File "/path_to_py_file/meshroom/core/graph.py", line 1574, in executeGraph chunk.process(forceCompute) File "/path_to_py_file/meshroom/core/node.py", line 411, in process self.node.nodeDesc.processChunk(self) File "/path_to_py_file/meshroom/core/desc.py", line 645, in processChunk raise RuntimeError('Error on node "{}":\n'.format(chunk.name))

To Reproduce Steps to reproduce the behavior (using the Meshroom python API):

  1. Build graph 1 (using band1 images), compute cameraInit and extract the SIFT features for each image
  2. Build graph 2 (using band2 images), compute cameraInit and extract the SIFT features for each image
  3. Build graph 3 (using band3 images), compute cameraInit and extract the SIFT features for each image
  4. For each image, open its graph3 .feat file and erase its content. Then, set it to the concatenation of band1 and band2 .feat files relative the same image. Repeat this procedure also for the .desc file of each image
  5. Extended graph 3 by adding ImageMatching (Exhaustive) and perform the matching
  6. Extended graph 3 by adding FeatureMatching and perform the matching. Here the error occurs.

Expected behavior I would expect the feature matching to be performed as usual. In the worst case, I would anticipate the RANSAC framework returning an empty inlier set. This assumes a scenario where it is not possible to find a robust inlier set due to geometrical inconsistencies between the keypoints in band1 and band2.

Log

As you can see, the lasts lines in the log file before the crash are:

[17:18:31.611793][info] Putative matches (unknown poses): 550 image pairs. [17:18:31.611817][info] sift Regions Matching [17:18:31.611828][debug] Using the OPENMP thread interface

0% 10 20 30 40 50 60 70 80 90 100% |----|----|----|----|----|----|----|----|----|----|

It seems like the crash happens as soon as the OPENMP part starts.

Desktop:

  • OS: Ubuntu 22.04.4LTS
  • Python version 3.10
  • Meshroom version: --Release version 2023.3.0 (to import meshroom_path and alicevision_path in python) --Latest github repo version (cloned on 22th February 2024) to import Graph, executeGraph and Node from meshroom.core in python

Additional context

  • I have added the print of the returned return code above (ERROR CODE: -11). I looked for that error in all the repository (and also in the AliceVision one) but I was not able to find anything related to returnCode -11.
  • To check the correctness of the jointed sift.desc and sift.feat features I have tried to append just a few features coming from band2 to band1, in this case everything worked without problems.
  • Doing those tests, starting with around 3000 features points from band1, I was able to append up to 275 features point from band2 (over the 5000 available in band2) when using ANN_L2 as photometric matching method.
  • In the same way, I was able to append up to 250 features when using brute-force (BF) as photometric matching method.
  • After such thresholds, the node crashes as described above (with the same error, independently from the photometric matching method).
  • I think that the success of the BF matcher confirms the correctness of the jointed sift.desc and sift.feat files, excluding possible errors on this side.
  • When working with DSPSIFT (with quality and density set to ultra), the number of keypoints found for band1 is between 20K and 30K, same for band 2, In this case, I am able to concatenate successfully just up to 15point. Then the same crash happens. This highlights that, as the total number of keypoints/features increases, the number of keypoints/features that can be added without causing a crash decreases.
  • Furthermore, such thresholds seem to change also depending on the total number of images used in the reconstruction.

If anyone can help me or give me some insights toward the possible issue I would really appreciate that. Thanks in advance!

KevinDepedri avatar Feb 22 '24 14:02 KevinDepedri