Add new CMake option to disable GUI

[anmatako]

The dependencies to Qt and the GUI build are now conditional on the new GUI_ENABLED option.

[anmatako]

@ahojnnes Seems to me that with the current colmap setup, OpenGL and Qt are intertwined so when disabling the GUI and skipping Qt we cannot really use OpenGL as well. Is this understanding accurate?

I can see a case of problematic behavior with my changes when we build without GUI support and without CUDA as well. This is the case where kUseOpenGL becomes true and the underlying Qt classes are stubbed out so things would fail.

What would be the best way to handle that? It seems to only affect feature extraction and matching that can use GPU either from CUDA or OpenGL. My idea would be to simply check the use_gpu option and ensure it's always false when both GUI_ENABLED and CUDA_ENABLED are undefined. This would force Sift to use cpu for extraction and matching which would not cause any kind of failure.

[whuaegeanse]

@anmatako
At least two Qt related codes need to be changed. The first is the code related to SiftGPU. The second place is the code related to IncrementalMapperOptions.

[anmatako]

@anmatako
At least two Qt related codes need to be changed. The first is the code related to SiftGPU. The second place is the code related to IncrementalMapperOptions.

@whuaegeanse The mapper options you linked are forward declarations and when the GUI is disabled the "ui" folder is excluded form the sources so they are never actually used. So, I don't think there's a need to add any special handling for them.

However, I do plan to make some additional changes to better handle the feature matching and extraction when both GUI and CUDA are disabled.

[anmatako]

Latest update now handles the case of both CUDA and OpenGL missing when attempting to use Sift GPU. In this case there is an error and EXIT_FAILURE with a message to disable the use_gpu option.

[whuaegeanse]

@anmatako @ahojnnes Consider using SIFTGPU's original opengl-related code, which has nothing to do with Qt. In this way, we can use opengl to accelerate feature extraction and feature matching without relying on Qt.I have done relevant experiments and the results are very good, and I am happy to submit relevant code for SIFTGPU that does not rely on Qt.

[anmatako]

@anmatako @ahojnnes Consider using SIFTGPU's original opengl-related code, which has nothing to do with Qt. In this way, we can use opengl to accelerate feature extraction and feature matching without relying on Qt.I have done relevant experiments and the results are very good, and I am happy to submit relevant code for SIFTGPU that does not rely on Qt.

@whuaegeanse I don't think the problem in this case is the implementation of Sift GPU that colmap is using. If I understand correctly, colmap uses the default implementation you are linking and it does indeed depend on OpenGL and builds with it. The problem as I see it is with colmap's use of OpenGL that only happens through Qt and thus is tied to the GUI. So, when I'm disabling the GUI I am also (as a side-effect) removing the ability to use OpenGL as well.

There should be a way to decouple OpenGL from Qt in colmap, but such a change goes beyond the scope of this PR. My intent here is much simpler and along the lines of:
"I don't want the colmap GUI and I accept that this also means that OpenGL will be unavailable as well".

Of course the behavior of disabling the GUI needs to be properly documented, so I'm open to suggestions as to where would be the best place to add such a note.

@ahojnnes please correct me if my understanding of this issue is incorrect.

[whuaegeanse]

@anmatako You are right, after disabling Qt, feature extraction and feature matching that rely on opengl will not be available.
But disabling Qt should not affect the use of feature extraction and feature matching, because the original version of SIFTGPU has nothing to do with related interface libraries such as Qt. Therefore, we should provide an OpenGLContextManager that does not rely on Qt.

[anmatako]

@whuaegeanse I agree with you that it should be possible to implement a context manager that does not rely on Qt, but that should be a separate issue and PR.