![\"\"](\"https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F611870%2F5c181b25c0664a66e0d351bfac0c6105%2Foverview.svg?generation=1748995502557044&alt=media\")
Update: Code is now available
\nNotebook
\nScripts
We introduced our team's solution here. In this section, I will focus on the VGGT-based approach that I worked on.
\nE2E 3D Geometric Foundation Models have been attracting attention as potential game-changers in the field of image matching. Among them, I chose to apply VGGT, developed by @jianyuanv, to this IMC challenge. However, applying VGGT to IMC2025 posed three key challenges:
\nTo address these issues, we implemented the following improvements:
\n
Note: To meet the 9-hour time constraint imposed by Code Requirements, the following additional optimizations were made:
\nVGGT provides not only camera pose estimation, but also a tracking function. Through experiments, we observed that it captures global context more effectively than conventional keypoint-based methods.
\nFor example, in the fbk_vineyard dataset, the correspondences stopped appropriately at scene transition boundaries.
\n![\"\"](\"https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F611870%2F012feab94341ecf48e0eaedf334048e9%2FVGGT-tracker.png?generation=1748995541504832&alt=media\"){kind=tracking}
In the original implementation, all target images were input at once for a single query image, resulting in high memory usage. To address this, I split the target images into 1/N chunks and processed them sequentially with the query image. This significantly reduced VRAM consumption.
\nWhile the matching from the VGGT tracker captured the overall scene structure, its absolute accuracy was limited. This is partly due to VGGT resizing images to 518, which leads to reduced spatial precision in keypoint localization.
\nTo overcome this, I refined the coarse camera poses estimated by VGGT using high-precision correspondences obtained from ALIKED + LightGlue. The refinement was done using the incremental_model_refiner, which was also used in the 1st place solution of IMC2023.
https://github.com/zju3dv/DetectorFreeSfM/blob/main/src/sfm_runner/sfm_model_geometry_refiner.py
\nWe evaluated the effectiveness of our method using validation data provided by the organizers.
\n![\"\"](\"https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F611870%2F2bb53df3cdff4aae5da03ecd08118c69%2Fresults.png?generation=1748995584825997&alt=media\")
| Method | \nPublic LB | \nPrivate LB | \nVal (amy_gardens) | \nVal (fbk_vineyard) | \nVal (ETs) | \nVal (stairs) | \n
|---|---|---|---|---|---|---|
| LightGlue with refiner | \n39.91 | \n42.33 | \n27.19 | \n45.91 | \n61.33 | \n6.25 | \n
| VGGT with refiner | \n38.55 | \n41.02 | \n44.88 | \n63.26 | \n66.67 | \n11.77 | \n
| VGGT w/o refiner | \n31.04 | \n36.65 | \n39.34 | \n66.23 | \n17.54 | \n14.29 | \n
Below are some qualitative results on selected scenes:
\namy_gardens
\n![\"\"](\"https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F611870%2Fc47def199d10a5760c9137fafea5d1af%2Famy_gardens.png?generation=1748995608568829&alt=media\")
fbk_vineyard
\n![\"\"](\"https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F611870%2F6cf484b03ac0275c9fce24190cdd5e1c%2Fvineyard1.png?generation=1748995649687449&alt=media\")
ETs
\n![\"\"](\"https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F611870%2Fc21f6edecaf0ded471376ff0f816d827%2FET1.png?generation=1748995665949055&alt=media\")
![\"\"](\"https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F611870%2F29d19e09d6db3ef6e622e356d15c981b%2FET2.png?generation=1748995676428148&alt=media\")
Although the proposed method performed well on the validation data, it underperformed on the leaderboard compared to conventional LightGlue-based approaches. As a result, the final submission was based on the baseline LightGlue-based method.
", "messages": [ { "id": 3216675, "postDate": "2025-06-04T00:10:14.303Z", "content": "Update: Code is now available
\nNotebook
\nScripts
We introduced our team's solution here. In this section, I will focus on the VGGT-based approach that I worked on.
\nE2E 3D Geometric Foundation Models have been attracting attention as potential game-changers in the field of image matching. Among them, I chose to apply VGGT, developed by @jianyuanv, to this IMC challenge. However, applying VGGT to IMC2025 posed three key challenges:
\nTo address these issues, we implemented the following improvements:
\n
Note: To meet the 9-hour time constraint imposed by Code Requirements, the following additional optimizations were made:
\nVGGT provides not only camera pose estimation, but also a tracking function. Through experiments, we observed that it captures global context more effectively than conventional keypoint-based methods.
\nFor example, in the fbk_vineyard dataset, the correspondences stopped appropriately at scene transition boundaries.
\n
In the original implementation, all target images were input at once for a single query image, resulting in high memory usage. To address this, I split the target images into 1/N chunks and processed them sequentially with the query image. This significantly reduced VRAM consumption.
\nWhile the matching from the VGGT tracker captured the overall scene structure, its absolute accuracy was limited. This is partly due to VGGT resizing images to 518, which leads to reduced spatial precision in keypoint localization.
\nTo overcome this, I refined the coarse camera poses estimated by VGGT using high-precision correspondences obtained from ALIKED + LightGlue. The refinement was done using the incremental_model_refiner, which was also used in the 1st place solution of IMC2023.
https://github.com/zju3dv/DetectorFreeSfM/blob/main/src/sfm_runner/sfm_model_geometry_refiner.py
\nWe evaluated the effectiveness of our method using validation data provided by the organizers.
\n
| Method | \nPublic LB | \nPrivate LB | \nVal (amy_gardens) | \nVal (fbk_vineyard) | \nVal (ETs) | \nVal (stairs) | \n
|---|---|---|---|---|---|---|
| LightGlue with refiner | \n39.91 | \n42.33 | \n27.19 | \n45.91 | \n61.33 | \n6.25 | \n
| VGGT with refiner | \n38.55 | \n41.02 | \n44.88 | \n63.26 | \n66.67 | \n11.77 | \n
| VGGT w/o refiner | \n31.04 | \n36.65 | \n39.34 | \n66.23 | \n17.54 | \n14.29 | \n
Below are some qualitative results on selected scenes:
\namy_gardens
\n
fbk_vineyard
\n
ETs
\n
Although the proposed method performed well on the validation data, it underperformed on the leaderboard compared to conventional LightGlue-based approaches. As a result, the final submission was based on the baseline LightGlue-based method.
", "rawMarkdown": "**Update:** Code is now available\n[Notebook](https://www.kaggle.com/code/tmyok1984/imc2025-exp66-vggt-with-refiner?scriptVersionId=243529440) \n[Scripts](https://www.kaggle.com/datasets/tmyok1984/imc2025-exp66-vggt-with-incremental-model-refiner)\n\n----\n\nWe introduced our team's solution [here](https://www.kaggle.com/competitions/image-matching-challenge-2025/discussion/582898). In this section, I will focus on the VGGT-based approach that I worked on.\n\n**E2E 3D Geometric Foundation Models** have been attracting attention as potential game-changers in the field of image matching. Among them, I chose to apply **VGGT**, developed by @jianyuanv, to this IMC challenge. However, applying VGGT to IMC2025 posed three key challenges:\n\n- It does not assume inputs containing multiple unrelated scenes\n- It requires large amounts of VRAM\n- Its camera pose estimation accuracy is relatively low\n\nTo address these issues, we implemented the following improvements:\n\n- Robust image matching based on global features using the **VGGT tracker**\n- Chunk-wise processing of VGGT tracker to reduce memory usage\n- Camera pose refinement using high-precision correspondences from **ALIKED + LightGlue**\n\n## Overview\n\n\n\n**Note**: To meet the 9-hour time constraint imposed by Code Requirements, the following additional optimizations were made:\n\n- Pre-filtering of candidate image pairs using **keynet-adalam** [details](https://www.kaggle.com/competitions/image-matching-challenge-2025/discussion/582898)\n- VGGT processing was limited to dataset with ≤128 images\n\n## VGGT Tracker\n\nVGGT provides not only camera pose estimation, but also a **tracking** function. Through experiments, we observed that it captures global context more effectively than conventional keypoint-based methods.\n\nFor example, in the fbk_*vineyard* dataset, the correspondences stopped appropriately at scene transition boundaries.\n\n\n\n## Memory Reduction via Chunked Processing\n\nIn the original implementation, all target images were input at once for a single query image, resulting in high memory usage. To address this, I split the target images into 1/N chunks and processed them sequentially with the query image. This significantly reduced VRAM consumption.\n\n## Camera Pose Refinement\n\nWhile the matching from the VGGT tracker captured the overall scene structure, its absolute accuracy was limited. This is partly due to VGGT resizing images to 518, which leads to reduced spatial precision in keypoint localization.\n\nTo overcome this, I refined the coarse camera poses estimated by VGGT using high-precision correspondences obtained from ALIKED + LightGlue. The refinement was done using the `incremental_model_refiner`, which was also used in the 1st place solution of IMC2023.\n\nhttps://github.com/zju3dv/DetectorFreeSfM/blob/main/src/sfm_runner/sfm_model_geometry_refiner.py\n\n## Experiments\n\nWe evaluated the effectiveness of our method using validation data provided by the organizers.\n\n\n\n| Method | Public LB | Private LB | Val (amy_gardens) | Val (fbk_vineyard) | Val (ETs) | Val (stairs) |\n|------------------------|-----------|------------|--------------------|---------------------|-----------|---------------|\n| LightGlue with refiner | 39.91 | 42.33 | 27.19 | 45.91 | 61.33 | 6.25 |\n| VGGT with refiner | 38.55 | 41.02 | 44.88 | 63.26 | 66.67 | 11.77 |\n| VGGT w/o refiner | 31.04 | 36.65 | 39.34 | 66.23 | 17.54 | 14.29 |\n\n\nBelow are some qualitative results on selected scenes:\n\n**amy_gardens**\n\n\n\n**fbk_vineyard**\n\n\n\n**ETs**\n\n\n\n\n\nAlthough the proposed method performed well on the validation data, it underperformed on the leaderboard compared to conventional LightGlue-based approaches. As a result, the final submission was based on the baseline LightGlue-based method.", "votes": 28 } ], "comments": [], "raw_markdown_by_id": { "3216675": "**Update:** Code is now available\n[Notebook](https://www.kaggle.com/code/tmyok1984/imc2025-exp66-vggt-with-refiner?scriptVersionId=243529440) \n[Scripts](https://www.kaggle.com/datasets/tmyok1984/imc2025-exp66-vggt-with-incremental-model-refiner)\n\n----\n\nWe introduced our team's solution [here](https://www.kaggle.com/competitions/image-matching-challenge-2025/discussion/582898). In this section, I will focus on the VGGT-based approach that I worked on.\n\n**E2E 3D Geometric Foundation Models** have been attracting attention as potential game-changers in the field of image matching. Among them, I chose to apply **VGGT**, developed by @jianyuanv, to this IMC challenge. However, applying VGGT to IMC2025 posed three key challenges:\n\n- It does not assume inputs containing multiple unrelated scenes\n- It requires large amounts of VRAM\n- Its camera pose estimation accuracy is relatively low\n\nTo address these issues, we implemented the following improvements:\n\n- Robust image matching based on global features using the **VGGT tracker**\n- Chunk-wise processing of VGGT tracker to reduce memory usage\n- Camera pose refinement using high-precision correspondences from **ALIKED + LightGlue**\n\n## Overview\n\n\n\n**Note**: To meet the 9-hour time constraint imposed by Code Requirements, the following additional optimizations were made:\n\n- Pre-filtering of candidate image pairs using **keynet-adalam** [details](https://www.kaggle.com/competitions/image-matching-challenge-2025/discussion/582898)\n- VGGT processing was limited to dataset with ≤128 images\n\n## VGGT Tracker\n\nVGGT provides not only camera pose estimation, but also a **tracking** function. Through experiments, we observed that it captures global context more effectively than conventional keypoint-based methods.\n\nFor example, in the fbk_*vineyard* dataset, the correspondences stopped appropriately at scene transition boundaries.\n\n\n\n## Memory Reduction via Chunked Processing\n\nIn the original implementation, all target images were input at once for a single query image, resulting in high memory usage. To address this, I split the target images into 1/N chunks and processed them sequentially with the query image. This significantly reduced VRAM consumption.\n\n## Camera Pose Refinement\n\nWhile the matching from the VGGT tracker captured the overall scene structure, its absolute accuracy was limited. This is partly due to VGGT resizing images to 518, which leads to reduced spatial precision in keypoint localization.\n\nTo overcome this, I refined the coarse camera poses estimated by VGGT using high-precision correspondences obtained from ALIKED + LightGlue. The refinement was done using the `incremental_model_refiner`, which was also used in the 1st place solution of IMC2023.\n\nhttps://github.com/zju3dv/DetectorFreeSfM/blob/main/src/sfm_runner/sfm_model_geometry_refiner.py\n\n## Experiments\n\nWe evaluated the effectiveness of our method using validation data provided by the organizers.\n\n\n\n| Method | Public LB | Private LB | Val (amy_gardens) | Val (fbk_vineyard) | Val (ETs) | Val (stairs) |\n|------------------------|-----------|------------|--------------------|---------------------|-----------|---------------|\n| LightGlue with refiner | 39.91 | 42.33 | 27.19 | 45.91 | 61.33 | 6.25 |\n| VGGT with refiner | 38.55 | 41.02 | 44.88 | 63.26 | 66.67 | 11.77 |\n| VGGT w/o refiner | 31.04 | 36.65 | 39.34 | 66.23 | 17.54 | 14.29 |\n\n\nBelow are some qualitative results on selected scenes:\n\n**amy_gardens**\n\n\n\n**fbk_vineyard**\n\n\n\n**ETs**\n\n\n\n\n\nAlthough the proposed method performed well on the validation data, it underperformed on the leaderboard compared to conventional LightGlue-based approaches. As a result, the final submission was based on the baseline LightGlue-based method." } }