Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

On model_splitter: After spliting the model, the output reconstruction is the same as the input reconstruction #1513

Closed
Serenitysmk opened this issue May 5, 2022 · 1 comment

Comments

@Serenitysmk
Copy link
Contributor

Describe the bug

This may be a bug, or maybe I didn't use understand the usage of the command model_splitter .

I try to use split the reconstruction into 4 parts using the command like this:

colmap model_splitter \
--input_path ~my_input_path \
--output_path ~my_output_path \
--split_type parts \
--split_params "4"

And, the console message is:

==============================================================================
Splitting sparse model
==============================================================================

 => Using "parts" split type

Computing bound_coords
----------------------

Applying split and writing reconstructions
------------------------------------------
 => Splitting to 4 parts
Writing reconstruction 3 with 557 images, 145957 points, and 33.86% area coverage
Writing reconstruction 0 with 401 images, 443576 points, and 51.17% area coverage
Writing reconstruction 2 with 1105 images, 712636 points, and 40.77% area coverage
Writing reconstruction 1 with 1137 images, 1099260 points, and 50.82% area coverage
Elapsed time: 0.450 [minutes]

It looks like the model is divided into 4 parts. However, when writing the 4 sub-models into the output directory, I saw that the sub-models are exactly the same as the original input reconstruction.

I don't know if this is a bug or if I didn't use it properly. After some searching, I didn't find similar issues.

So I looked into the code at line 959 of ~src/exe/model.cc:

  auto SplitReconstruction = [&](const int idx) {
    Reconstruction tile_recon = reconstruction.Crop(bounds[idx]);
    // calculate area covered by model as proportion of box area
    auto bbox_extent = bounds[idx].second - bounds[idx].first;
    auto model_bbox = tile_recon.ComputeBoundingBox();
    auto model_extent = model_bbox.second - model_bbox.first;
    double area_ratio =
        (model_extent(0) * model_extent(1)) / (bbox_extent(0) * bbox_extent(1));
    int tile_num_points = tile_recon.NumPoints3D();

    std::string name = use_tile_keys ? tile_keys[idx] : std::to_string(idx);
    const bool include_tile =
        area_ratio >= min_area_ratio &&       //
        tile_num_points >= min_num_points &&  //
        tile_recon.NumRegImages() >= static_cast<size_t>(min_reg_images);

    if (include_tile) {
      std::cout << StringPrintf(
                       "Writing reconstruction %s with %d images, %d points, "
                       "and %.2f%% area coverage",
                       name.c_str(), tile_recon.NumRegImages(), tile_num_points,
                       100.0 * area_ratio)
                << std::endl;
      const std::string reconstruction_path = JoinPaths(output_path, name);
      CreateDirIfNotExists(reconstruction_path);
      reconstruction.Write(reconstruction_path);
      WriteBoundingBox(reconstruction_path, bounds[idx]);
      WriteBoundingBox(reconstruction_path, exact_bounds[idx], "_exact");

    } else {
      std::cout << StringPrintf(
                       "Skipping reconstruction %s with %d images, %d points, "
                       "and %.2f%% area coverage",
                       name.c_str(), tile_recon.NumRegImages(), tile_num_points,
                       100.0 * area_ratio)
                << std::endl;
    }
  };

I saw that the input reconstruction is splitted and cropped and saved into tile_recon, but calling reconstruction.Write(reconstruction_path) to the output path, which is the original reconstruction.

Am I correct? Or if I understood somewhere wrong?

@Serenitysmk
Copy link
Contributor Author

Thanks for the fix. I am closing the issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant