Open 3ddiddE opened 2 years ago
The reasoning is to handle this case in graceful manner without crashing the program. I assume you don't mean gtest but glog's checking mechanism.
Thanks for the reply and excuse me, yes I meant glog!
Keep on reading, only if you have the time please!
I do not really understand the difference between checking (with glog) if options are within a particular range and gracefully checking if an image is registered before triangulating the image. Also, other than a returned 0 value there is no indication that the image is not registered yet. So in my point of view I would understand when an exception would be thrown, but since error logging is done via glog, I would have assumed that this would also be an error to be logged by glog.
So in short: I don't get why this case is explicitly handled differently in comparison to bad lower/upper values for options.
In src/sfm/incremental_triangulator.cc the function IncrementalTriangulator::TriangulateImage has a gtest check for the options. However, although the description of the functions says that
this check is not done by using gtest but instead just returning 0 if the image is not registered cf.
I just wondered why that might be the case here? I was reading the source to understand what is going on and how/why observation tracks are used and was confused that this is even tested in the incremental triangulator.
Is there any particular reasoning behind not using gtest here?