Summary
This paper introduces "OpenStereo," a tool that aims to streamline the evaluation of stereo matching models by integrating existing datasets and codebases. It also presents "StereoBase," a model designed to perform optimally within this framework. The goal is to provide a standardized comparison of different stereo-matching methods.
Strengths
(1) I appreciate the authors' efforts to integrate existing stereo-matching resources into a cohesive framework, which could facilitate benchmarking and enhance reproducibility within the community.
(2) The detailed experimental setup and comprehensive evaluation are commendable. They provide a clear snapshot of how various established methods perform under a unified protocol. And I believe this paper could serve as a valuable reference for researchers interested in an overview of the stereo-matching landscape.
Weaknesses
(1) The StereoBase, though effective, largely mirrors existing approaches with minimal innovation. Since the paper does not propose new datasets or benchmarks, it mainly refines and combines existing strategies, which might limit its appeal to a readership looking for breakthrough innovations in stereo matching, Therefore, the results are not impressive to me.
(2) The paper presents the StereoBase model as a high-performance solution within the OpenStereo framework, which integrates various existing stereo-matching methods. However, as shown in Table 3 of the manuscript, the computational demands associated with this model are considerable, which could limit its deployment in real-world, resource-constrained environments. To be more specific:
- The group-wise correlation (Gwc) and concatenation volumes used in StereoBase show a drastic increase in computational requirements as the channel depth increases. For instance, the Gwc48 configuration demands 1191.07 Gflops and has 15.73M parameters, which is computationally intensive.
- Similarly, the combined volume configurations like G32-C48 push the computational requirements even further to 3239.17 Gflops with 39.37M parameters. This level of computational complexity is impractical for deployment on embedded systems or mobile devices where power efficiency and processing capabilities are limited.
(3) The paper's comprehensive experiments do not extensively cover the generalization of the proposed model across various real-world scenarios, which might involve dynamic lighting conditions, non-static scenes, or occlusions that are not adequately represented in the benchmark datasets. Since the EPE of the scene flow dataset is already under 1 pixel, improving it from 0.41 to 0.34 may seem like a big improvement since it is too easy to be overfitting for the high overlap of the training and testing scenes. Since the author focuses on `practical` ability, it should stress more on the generation performance in ill-conditioned areas which is more aligned with true practicality. Hence I hope the author shows more specific results in such settings.
There are more datasets with more realistic and higher-quality data such as the booster dataset (https://cvlab-unibo.github.io/booster-web/). FAT dataset (https://research.nvidia.com/publication/2018-06_falling-things-synthetic-dataset-3d-object-detection-and-pose-estimation), distdepth dataset (https://distdepth.github.io/), etc, just to name a few, that is probably more suitable than KITTI and SceneFlow to study stereo (dense disparity maps, more occluded pixels, occlusion masks are given etc). I encourage the authors to not tie your hands tight on these most popular benchmarks. I am not convinced using KITTI and SceneFlow/ ETH3D/Middlebury as the main datasets to study stereo is enough.
Questions
1. The generalization capabilities of StereoBase across different domains and environments are crucial for its application in real-world scenarios. Can the authors extend their experiments to include more diverse datasets that feature challenging conditions such as poor lighting, weather effects, and dynamic obstacles as I believe contained in the drivingStereo dataset?