We thank the reviewer for the constructive comments. Below, we provide a point-by-point response to address your concerns. We welcome further discussion to improve the clarity and effectiveness of our work.

>>> W1: Not an optimal approach. A more effective approach might directly leverage images for optimization, as demonstrated by methods like 3DGS.

>>> A1:

• 3DGS-based model. We would like to clarify that our method and 3D Gaussian Splatting (3DGS) serve different purposes and are based on fundamentally different design principles. 3DGS is designed for photorealistic appearance reconstruction through iterative photometric optimization. In contrast, our approach focuses on accurate geometric prediction using feed-forward models, similar to DUSt3R [1], MAST3R [2], and VGGT [3]. These methods play a role similar to Structure-from-Motion (SfM) in the reconstruction pipeline. Therefore, direct comparisons with methods like 3DGS are not fully aligned in scope. Importantly, our method can provide accurate geometric initialization and camera poses, which can serve as a strong complement for iterative 3D reconstruction models such as 3DGS and NeRF.

• NOT suboptimal. Our method is designed to achieve optimal geometric prediction under the feed-forward paradigm. By enforcing geometric consistency across triplets, our method leverages the mutual constraint between partial reconstructions, which is a fundamental signal in scene geometry. In an ideal scenario with perfect reconstruction, this consistency loss would naturally vanish. This principled design allows our model to generalize across scenes with minimal testing-time optimization, making it efficient and robust in practice.

[1] DUSt3R: Geometric 3D Vision Made Easy.

[2] Grounding Image Matching in 3D with MASt3R.

[3] VGGT: Visual Geometry Grounded Transformer.

>>> W2: Discussion and comparison with recent feed-forward approaches such as VGGT.

>>> A2:

• Comparison: We have provided a comparison with two feed-forward approaches, VGGT[1] and Fast3R[2], in the Tab.6 in the Appendices. As shown in this table, Test3R achieves significantly superior reconstruction quality compared to Fast3R. Moreover, it outperforms VGGT across the vast majority of evaluation metrics.

• Discussion: While VGGT processes multiple views jointly and avoids pairwise depth estimation, it still suffers from cross-pair inconsistency in predicted geometries. We would like to highlight that this inconsistency can still be leveraged through our method to enhance the reconstruction quality of VGGT. To demonstrate this, we implemented our method on VGGT. Specifically, we insert the prompts into the image tokens of each input image, like the operation of VGGT’s handling of the register token. During test-time training, it still takes a triplet as input to predict two pointmaps under the same reference view but paired with different source views as introduced in Sec.4.2. We evaluated it on the Office-07 scene on the 7Scenes dataset. The final results are shown in the table below. It indicates that Test3R significantly enhances both Acc. and Comp. of pointmap predicted by VGGT[1].

[1] VGGT: Visual Geometry Grounded Transformer.

[2] Fast3R: Towards 3D Reconstruction of 1000+ Images in One Forward Pass

>>> W3: A thorough analysis and comparison of reconstruction speed. Comparisons with other per-scene optimization methods, such as some 3DGS-based methods.

>>> A3:

• Reconstruction speed. We appreciate the reviewer’s concern about runtime. The optimization process is relatively short, taking approximately 14 seconds on a single GPU. The majority of Test3R’s time overhead comes from the pair-wise prediction and global alignment in the original DUSt3R's pipeline, which together take 320 seconds for a set of 50 images on the 7Scenes dataset.

• Runtime comparison with 3DGS. While these two methods are not directly comparable as discussed in W1, our method only introduces a few seconds of extra overhead; the total reconstruction time remains much shorter than that required by 3DGS to reconstruct a large-scale scene, which typically takes about an hour.

  We will include this discussion and timing statistics in the revision for clarity and completeness.

>>> W4: The limited novelty and technical contribution of this paper.

>>> A4: We thank the reviewer for this question. It gives us a valuable opportunity to clarify our design.

Yes, our method is simple, but this simplicity is intentional and highlights our strength. Simplicity does not diminish novelty; rather, it underscores the effectiveness of our insight.

Specifically, Test3R is novel in both new paradim and technical application:

1. A New Paradigm, Not Post-Processing: We are the first to introduce TTA to feedforward 3D reconstruction. This shifts from static inference to dynamic, per-scene model adaptation. Crucially, this is not post-processing, which operates on fixed outputs. Instead, we dynamically adapt the model's parameters for each scene during inference, which is fundamentally different from refining a static result.

2. Technical novelty: Our technical approach enables this new paradigm with two key contributions:

• Self-consistency as new objective. Our objective is straightforward by design, but it is not suboptimal. It is based on the universal principle of geometric self-consistency: any partial reconstructions of the same scene must be consistent with one another. For a perfect reconstruction, this self-consistency loss would naturally be zero. This self-consistency loss is never introduced in any paper before.
• First use of VPT in 3D While VPT is an established PEFT method, we are the first to apply it to feedforward 3D models under TTA. Adapting visual prompts for dense 3D geometry prediction is non-trivial and requires careful integration.

We will highlight those points in the revision. Thanks!

>>> W5: There are minor issues, such as the typo "recomstruction" on line 39.

>>> A5:

We appreciate your reminder and will revise it.

Thank you for your positive feedback and insightful comments! Below, we respond to address your concern. We welcome further discussion to enhance the clarity and effectiveness of our work.

>>> W1: The authors repeatedly claim that their method is nearly cost-free; however, prompt tuning clearly incurs computational cost. No runtime analysis or comparison is provided.

>>> A1: We appreciate your suggestion and apologize for the oversight. The test-time optimization process is relatively short, taking approximately 14 seconds per scene on average with a single GPU. Regarding GPU memory usage during pair-wise prediction, Test3R consumes 2.57 GB, compared to 2.54 GB for vanilla DUSt3R. We consider this additional memory footprint negligible.

>>> W2: The motivation for using prompt tuning is not sufficiently ablated. While test-scene fine-tuning can naturally improve performance, it remains unclear why prompt tuning is specifically needed. There are lots of other fine-tuning methods that can be used, such as fine-tuning or LoRA.

>>> A2: Thanks for your suggestion. We conducted experiments on the Office-09 scene on the 7Scenes dataset. We perform fine-tuning of the DUSt3R encoder via two methods: full-parameters fine-tuning and LoRA. The quantitative results are shown in the table below and will be included in the main paper. Specifically, by maximizing cross-pair consistency introduced in Sec.4.2, all three test-time training approaches improve reconstruction quality. However, our method that uses prompts significantly outperforms both the full-parameters and LoRa-based approaches.

>>> W3: The authors claim the method is "universally applicable and nearly cost-free" yet all experiments are conducted on DUSt3R/MASt3R/MonST3R, which share the same architecture. It is unclear how well the method generalizes to other models like CUT3R or VGGT, which support more input images.

>>> A3: Thank you for pointing this out. We would like to clarify that our method remains applicable to multi-image input methods such as VGGT[1]. Specifically, we insert the prompts into the image tokens of each input image, in a manner similar to VGGT’s handling of the register token. During test-time training, it still takes a triplet as input to predict two pointmaps under the same reference view but paired with different source views as introduced in Sec.4.2. To validate the effectiveness of the model, we conducted an evaluation on the Office-07 scene on the 7Scenes dataset. Following the default setting in Sec.5, the number of triplets as test-time training sets is 125, and we optimize the prompt using only one epoch. The final results are shown in the table below. It indicates that our method significantly enhances both Acc. and Comp. of the pointmap predicted by VGGT[1]. This further provides evidence of the "universally applicable" nature of our method. This experiment will be included in the main paper.

[1] VGGT: Visual Geometry Grounded Transformer.

>>> W4: Since the method operates directly on image pairs, qualitative results showing outputs before and after applying Test3R would help demonstrate its effectiveness.

>>> A4: We apologize we are currently unable to provide similar visualizations here due to NeurIPS policy restrictions. However, we provide a comparison of depthmap consistency in Fig. 5 in the Appendices. This comparison can also illustrate the improvement in pointmap consistency, according to Eq.9. As shwon in this Figure, our model effectively improves cross-pair consistency, and generates consistent and reliable depth in regions with limited overlap. We will supplement the visualization results of the pointmap in subsequent versions.

>>> W5: Other writing issues.

>>> A5:

Thanks for your suggestions for our writing issues; they are helpful in improving the clarity and readability.

• Line 39 typo: "reconstruction."
  • We will revise it.
• Section 4.1 is redundant and overlaps with content in Lines 31–43.
  • We will reorganize these two parts accordingly. An overview will be provided in the Introduction section, followed by a detailed description in Section 4.1.
• The method operates on only two image pairs, making the ellipsis in the left part of Fig. 2 unnecessary.
  • We will revise the figure.
• Line 232 mentions using DUST3R as the backbone, while Line 64 refers to MAST3R and MonST3R. This inconsistency should be clarified.
  • We would like to clarify that the experiments in Sec.5 are all based on the DUSt3R(Line232). We applied Test3R to MASt3R and MonSt3R to demonstrate the universal applicability of our model(Line 64). We apologize for the misunderstanding and will correct the description in Line 232.

>>> Q1: The method is limited to handling three input views. However, in Sec. 5.1, experiments are conducted with 3–5 and 2–4 views. How is this discrepancy addressed?

>>> A1: Sorry for any confusion. We would like to clarify that our model can handle an arbitrary number of images. The input during test-time training is three images. Specifically, in Sec.5.1, we consider all input viewpoints to construct the triplets. Subsequently, these triplets serve as the test-time training set to optimize our model.

>>> Q2: Can the method be extended to handle a larger number of input views, such as more than 10?

>>> A2: Yes. Our model can handle an arbitrary number of images.

>>> Q3: In Fig. 1, the point maps are aligned using only ICP, as DUST3R outputs lack consistent scale. This undermines the reliability of the visualizations. Additionally, no comparable visualization of Test3R is provided.

>>> A3: Thanks for pointing this out. In fact, we consider scale inconsistency to be a specific part of cross-pair inconsistency. If the model can fully adapt to the scene, the scale of its pointmaps would also be consistent. Therefore, we only use ICP to align the pointmap.

Visualization. Due to NeurIPS policy restrictions, similar visualizations of Test3R are not able to be included in the rebuttal phase. We will supplement the visualization results of the pointmap in revision. We would like to kindly invite you to refer to Fig.5 in the appendix, which provides a comparison of cross-pair consistency on the depthmap. It can reflect our improvement for pointmap consistency, according to Eq.9.

I sincerely thank the Reviewer-dVwe for the new suggestions!

>>> Q1: Test-time Optimization.

>>> A1: Thanks for the question! We estimate the time on the 7Scenes dataset. For the test-time training phase, we process all available image triplets, up to a maximum of 165. If a scene contains more than 165 triplets, we randomly sample this maximum amount. With a batch size of 2, this takes at most $165/2\approx 83$ iterations. Each image is resized to a resolution of $512\times 384$, matching the setting in the DUSt3R. Under this setup, the average processing time across all scenes is 14 seconds.

Nearly cost-free. Sorry for the confusion! While 14 seconds may not seem short on its own, it is negligible compared to the overall runtime of pipelines like DUSt3R and MonST3R. For example, processing 50 images from the 7Scenes dataset already takes 320 seconds with DUSt3R alone. In this context, the additional 14 seconds is relatively minimal, "nearly cost-free".

>>> Q2: Average results across the entire dataset.

>>> A2: We appreciate your suggestion! In response, we conducted additional experiments on all 18 scenes in the 7Scenes dataset.

PEFT evaluation. We report averaged results across all 18 scenes on the 7Scenes dataset. All experimental settings remain consistent with our default setting provided in Sec.A. The average scores of all scenes are presented in the table below. As shown, leveraging our training objective to maximize cross‑pair consistency enables all three fine‑tuning methods to achieve improvements in the final reconstruction results. The LoRA-based method, direct fine-tuning, and our approach resulted in decreases in Acc. of 0.012, 0.009, and 0.04, respectively.

These results support our claim that prompt tuning is a strong choice for test-time training.

VGGT Implementation. We further evaluated the results of implementing our method on VGGT across all 18 scenes from the 7Scenes dataset. For detailed implementation, we specifically insert the prompts into the image tokens of each input image, in a manner similar to VGGT’s handling of the register token. During test-time training, it still takes a triplet as input to predict two pointmaps under the same reference view but paired with different source views as introduced in Sec.4.2. To validate the effectiveness of the model, we follow the default experimental settings and construct the triplets as described in Sec.A. The final results are presented in the table below. We outperform vanilla VGGT on both the Acc and Comp metrics, with only the NC metric showing comparatively lower performance. This demonstrates that our method is also applicable to multi-view input approaches such as VGGT.

We would like to thank the reviewer for their insightful feedback and interesting observations. We thank the reviewer for the support of our work, and we address the reviewer’s comments below and will include all the feedback in the revised version of the manuscript.

>>> W1: Evaluation on camera pose estimation.

>>> A1: Thanks for your suggestion. We provide the result on the cave_2 scene on the Sintel dataset, and we promise that further experimental results will be conducted and included in the main paper. As shown in the table below, Test3R significantly improves the performance of DUSt3R on camera pose estimation in dynamic scenes, even though it has never been trained on any dynamic scene dataset.

>>> W2: Ablation study: It would be helpful to include a comparison with (naive or LoRa-based) test-time finetuning approaches that adapt the entire model or only the encoder, without introducing extra tokens.

>>> A2:

Thanks for your suggestion. We conducted experiments on the Office-09 scene on the 7Scenes dataset. We perform fine-tuning of the DUSt3R encoder via two methods: naive fine-tuning and LoRA. The quantitative results are shown in the table below and will be included in the main paper. Specifically, by maximizing cross-pair consistency introduced in Sec.4.2, all three test-time training approaches improve reconstruction quality. However, our method, which uses prompts, significantly outperforms both the naive and LoRa-based fine-tuning approaches.

>>> W3: The proposed method appears to be specifically designed for pairwise methods, whereas current state-of-the-art approaches are predominantly multi-view models, such as VGGT and CUT3R. This focus may limit the broader applicability and impact of the proposed approach.

>>> A3:

Thank you for pointing this out. We would like to clarify that our method remains applicable to multi-image input methods such as VGGT[1]. Specifically, we insert the prompts into the image tokens of each input image, in a manner similar to VGGT’s handling of the register token. During test-time training, it still takes a triplet as input to predict two pointmaps under the same reference view but paired with different source views as introduced in Sec.4.2. To validate the effectiveness of the model, we conducted an evaluation on the Office-07 scene on the 7Scenes dataset. Following the default setting in Sec.5, the number of triplets as test-time training sets is 125, and we optimize the prompt using only one epoch. The final results are shown in the table below. It indicates that our method significantly enhances both Acc. and Comp. of the pointmap predicted by VGGT[1]. This further provides evidence of the "universally applicable" nature of our method. This experiment will be included in the main paper.

[1] VGGT: Visual Geometry Grounded Transformer.

>>> Q1: At test time, are the triplets processed sequentially or in batches? If they are processed in batches, what batch size is used?

>>> A1: It's in batches. Batch size is set to 1 in our experimental setup.

>>> Q2: The reviewer is curious whether the proposed method is compatible with using correspondences (e.g., from an off-the-shelf model), where the training objective is to enforce that points from corresponding pixels are close to each other. This extension could potentially make the approach work with multi-view methods as well.

>>> A2: Yes. Our method is compatible with these training objective. This approach provides a strong complement to our cross-pair consistency training objective. Aligning corresponding pixels enables us to fully leverage the pointmaps of source views, as discussed in Sec.D in the Appendices. Moreover, St4RTrack [1] has demonstrated that this method contributes to improving the model’s reconstruction capability. However, this is not the primary focus of this paper. We consider it as a potential direction for future research, and sincerely appreciate your insightful suggestion.

[1] St4RTrack: Simultaneous 4D Reconstruction and Tracking in the World

We thank the reviewer for the constructive comments. We provide our feedback as follows.

>>> W1: Practical cost of performing optimization at inference time.

>>> A1: Our maximum test‑time training duration is approximately 14 seconds on a single GPU. This remains consistent even with a large number of views.

Why nearly cost-free? Test3R introduces only 14 seconds of extra time overhead, which we consider negligible during the entire process. In fact, the majority of Test3R’s time consumption comes from the pair-wise prediction and global alignment introduced by DUSt3R. This proportion increases as the number of images grows. For example, for a set of 50 images on the 7Scenes dataset, pair-wise prediction takes nearly 250s, and global alignment consumes nearly 70 seconds.

>>> W2: Strategy for triplet selection. Discussion on the performance and which triplets are chosen, how many triplets are used for optimization, and how they are sampled.

>>> A2:

• Triplet sampling strategy. We describe our triplets sampling strategy in Sec.A in the Appendices, and we will relocate this content to the experiment section(Sec.5). Considering a scene with $n$ images, the total number of triplets is $n^3$ for test-time training. For computational efficiency, if the number of triplets exceeds 165, we randomly sample 165 triplets as the test-time training set for each epoch.

Here, we discuss the number of triplets and the sampling strategy on the Office-09 scene on the 7Scenes dataset. This scene consists of five sequential images; therefore, 125 triplets are used in each epoch.

• The number of triplets is used. We report the results under different epoch settings to evaluate the effect of the number of triplets. As shown in the table below, Test3R significantly enhances the reconstruction quality of the scene just using one epoch for training, which is our default setting. With more epochs, the optimization leverages an increasing number of triplets, resulting in an improvement in reconstruction quality.

• Triplets sampling. Given that this scene is captured sequentially, short-baseline triplets are generated by increasing the frequency of source views close to the reference view. Conversely, this results in the wide-baseline experiment. As shown in the table below, the reconstruction results of these three methods are comparable. This demonstrates the robustness of our method, as it is largely insensitive to the selection of triplets.

>>> Q1: A detailed analysis of the test-time computational overhead. How many optimization iterations are performed? What is the total processing time compared to the original DUSt3R?

>>> A1: We report the time consumption of Test3R on the Office scene with a total of 50 images. We follow our default setting and use 165 triplets to optimize Test3R for only one epoch. Therefore, there are 165 optimization iterations performed. In terms of time consumption, this training process only takes 14 seconds. After that, the pair-wise prediction and global alignment introduced by vanilla DUSt3R are performed using 320 seconds.

>>> Q2: How are the image triplets (I1,I2,I3) selected? How does the performance of Test3R vary with different numbers of triplets or different selection strategies?

>>> A2: Sorry for any confusion.

• Triplet sampling strategy. We describe our triplets sampling strategy in Sec.A in the Appendices, and we will relocate this content to the experiment section(Sec.5). Considering a scene with $n$ images, the total number of triplets is $n^3$ for test-time training. For computational efficiency, if the number of triplets exceeds 165, we randomly sample 165 triplets as the test-time training set for each epoch.
• Performance variation. As we mentioned in W2, the reconstruction quality improves as the number of triplets increases, and does not exhibit any significant differences when different baselines are selected.