sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: opencv
Issue: DescriptorExtractor.create method fails with 'Specified descriptor extractor type is not supported'
Labels: bug,auto-transferred,affected: 3.4,category: java bindings

Transferred from http://code.opencv.org/issues/4419

```
|| Mark Grubb on 2015-06-17 00:59
|| Priority: Blocker
|| Affected: branch 'master' (3.0-dev)
|| Category: java bindings
|| Tracker: Bug
|| Difficulty: 
|| PR: 
|| Platform: x64 / Windows
```
## DescriptorExtractor.create method fails with 'Specified descriptor extractor type is not supported'

```
private static final DescriptorExtractor descriptorExtractor = DescriptorExtractor.create(DescriptorExtractor.BRIEF);

Caused by: CvException [org.opencv.core.CvException: cv::Exception: c:\builds\master_packslaveaddon-win64-vc12-static\opencv\modules\features2d\misc\java\src\cpp\features2d_manual.hpp:374: error: (-5) Specified descriptor extractor type is not supported. in function cv::javaDescriptorExtractor::create
]
```
## History
##### Philipp Hasper on 2015-06-22 06:21

```
BRIEF has been moved to the contrib repository (https://github.com/Itseez/opencv_contrib) Are you using the pre-built OpenCV or did you build it yourself? In the latter case, you should include the build of contrib as explained in the link
```
##### be rak on 2015-06-22 08:27

```
unfortunately, it won't work even with the contrib repo on board.

none of the xfeature2d classes are available in java atm.

if you take a close look at features2d_manual.hpp, you can see, that it was even tried to pull them in, but then discarded.

i made a quick attempt with conditional blocks like #ifdef HAVE_OPENCV_XFEATURES2D, but that did not work either - the opencv2/xfeatures2d.hpp header is not available, when compiling this.

imho, the whole features2d_manual.hpp factory approach should be removed in favour of ORB.create() , SIFT.create(), etc.
```
##### Mark Grubb on 2015-06-30 19:00

```
Philipp Hasper wrote:
> BRIEF has been moved to the contrib repository (https://github.com/Itseez/opencv_contrib) Are you using the pre-built OpenCV or did you build it yourself? In the latter case, you should include the build of contrib as explained in the link

I am using pre-built.

It appears the build is faulty.
```
Repository: opencv
Issue: Cannot find header files when compiling matlab bindings
Labels: bug,auto-transferred,priority: normal,affected: 3.4,category: matlab bindings

Transferred from http://code.opencv.org/issues/4424

```
|| Anup Parikh on 2015-06-22 03:34
|| Priority: Normal
|| Affected: branch 'master' (3.0-dev)
|| Category: matlab bindings
|| Tracker: Bug
|| Difficulty: 
|| PR: 
|| Platform: x64 / Windows
```
## Cannot find header files when compiling matlab bindings

```
I get this error when trying to compile the latest source from the master branch. I'm using MSVS 2013 pro on windows. I've copied the compiler output below, not sure if anything else is needed. Curiously, absdiff is the first alphabetical file in the matlab module, so I don't know if that means all the rest of the files were also not compiled, or if it's just a coincidence, since the output says this is the only file that failed.

1>------ Build started: Project: opencv_matlab_sources, Configuration: Release x64 ------
2>------ Build started: Project: opencv_matlab, Configuration: Release x64 ------
2>  Building Custom Rule C:/opencv/modules/matlab/CMakeLists.txt
2>  CMake does not need to re-run because C:\opencv\build\modules\matlab\CMakeFiles\generate.stamp is up-to-date.
2>  Compiling Matlab source files. This could take a while...
2>  CMake Error at C:/opencv/modules/matlab/compile.cmake:47 (message):
2>    Failed to compile absdiff: absdiff.cpp
2>  
2>    c:\opencv\modules\matlab\include\opencv2\matlab\mxarray.hpp(502) : warning
2>    C4099: 'matlab::ArgumentParser::Variant' : type name first seen using
2>    'struct' now seen using 'class'
2>  
2>            c:\opencv\modules\matlab\include\opencv2\matlab\mxarray.hpp(488) : see declaration of 'matlab::ArgumentParser::Variant'
2>  
2>    c:\opencv\modules\matlab\include\opencv2\matlab\mxarray.hpp(565) : warning
2>    C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
2>  
2>    c:\opencv\modules\matlab\include\opencv2\matlab\mxarray.hpp(567) : warning
2>    C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
2>  
2>    c:\opencv\modules\matlab\include\opencv2\matlab\mxarray.hpp(570) : warning
2>    C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
2>  
2>    c:\opencv\modules\matlab\include\opencv2\matlab\mxarray.hpp(572) : warning
2>    C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
2>  
2>    C:/opencv/modules/core/include\opencv2/core/cvdef.h(59) : fatal error
2>    C1083: Cannot open include file: 'opencv2/hal/defs.h': No such file or
2>    directory
2>  
2>    
2>  
2>    
2>  
2>  
2>  
2>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(170,5): error MSB6006: "cmd.exe" exited with code 1.
3>------ Build started: Project: opencv_test_matlab, Configuration: Release x64 ------
========== Build: 2 succeeded, 1 failed, 99 up-to-date, 0 skipped ==========
```
## History
Repository: opencv
Issue: Suspicious synchronization in modules/videoio/src/cap_openni.cpp
Labels: bug,auto-transferred,priority: low,category: videoio,affected: 3.4

Transferred from http://code.opencv.org/issues/4425

```
|| Alexandr Konovalov on 2015-06-22 07:09
|| Priority: Low
|| Affected: branch 'master' (3.0-dev)
|| Category: None
|| Tracker: Bug
|| Difficulty: 
|| PR: 
|| Platform: Any / Any
```
## Suspicious synchronization in modules/videoio/src/cap_openni.cpp

```
In modules/videoio/src/cap_openni.cpp I see very suspicious code. As mtx is placed on stack, only effect of mtx.lock()/unlock() is memory fences, not mutual exclusion. So this is either merely confusing a code reader, or a sign of synchronization bug.

class TBBApproximateSynchronizer: public ApproximateSynchronizerBase {
...
    virtual inline void pushDepthMetaData( xn::DepthMetaData& depthMetaData ) {
...
            tbb::mutex mtx;
            mtx.lock();
            if( depthQueue.try_push(depthPtr) == false )
            {
                if( approxSyncGrabber.getIsCircleBuffer() )
                {
                    CV_Assert( depthQueue.try_pop(tmp) );
                    CV_Assert( depthQueue.try_push(depthPtr) );
                }
            }
            mtx.unlock();
        }
}
```
## History
Repository: opencv
Issue: StereoSGBM doesn't work with SADWindowSize greater than 11 instead from Python the disparity map looks fine!
Labels: bug,auto-transferred,category: calib3d,affected: 3.4

Transferred from http://code.opencv.org/issues/4430

```
|| Matteo Sacchi on 2015-06-23 16:58
|| Priority: High
|| Affected: branch 'master' (3.0-dev)
|| Category: None
|| Tracker: Bug
|| Difficulty: 
|| PR: 
|| Platform: x64 / Linux
```
## StereoSGBM doesn't work with SADWindowSize greater than 11 instead from Python the disparity map looks fine!

```
The disparity map computed by StereoSGBM with a SADWindowSize > 11 contains a lot of artifacts. The same operation from Python works.
```
## History
Repository: opencv
Issue: SURF_CUDA does not match SURF API and is out of date
Labels: bug,auto-transferred,category: nonfree,affected: 3.4

Transferred from http://code.opencv.org/issues/4432

```
|| Andrew Hundt on 2015-06-24 01:04
|| Priority: High
|| Affected: branch 'master' (3.0-dev)
|| Category: nonfree
|| Tracker: Bug
|| Difficulty: Easy
|| PR: 
|| Platform: Any / Any
```
## SURF_CUDA does not match SURF API and is out of date

```
API mismatch:

* SURF_CUDA in opencv_contrib 
> * https://github.com/Itseez/opencv_contrib/blob/master/modules/xfeatures2d/include/opencv2/xfeatures2d/cuda.hpp#L86
* SURF in opencv_contrib
> * https://github.com/Itseez/opencv_contrib/blob/master/modules/xfeatures2d/include/opencv2/xfeatures2d/nonfree.hpp#L116


SURF_CUDA using the old is using OpenCV 2.x rather than 3.x API. For example, there is no SURF_CUDA::create function. It appears this fell through the cracks.

I created an opencv_contrib issue as well: https://github.com/Itseez/opencv_contrib/issues/280
```
## History
Repository: opencv
Issue: kalman.cpp
Labels: bug,auto-transferred,priority: normal,category: samples,affected: 2.4

Transferred from http://code.opencv.org/issues/4440

```
|| Volodymyr Ivanchenko on 2015-06-27 00:05
|| Priority: Normal
|| Affected: 2.4.9 (latest release)
|| Category: None
|| Tracker: Bug
|| Difficulty: 
|| PR: 
|| Platform: Any / Any
```
## kalman.cpp

```
You kalman.cpp sample (not module) seems to compare wrong entities. In particular, you compare measurement with prediction while
you have to compare measurement with estimation. In other word, instead of using prediction = KF.statePre use KF.statePost that you
have to update BEFORE drawing lines. In the current code, your comparison isn't indicative of Kalman Filter efficiency and only reflects 
the fact that during the initialization of the filter you set process noise level (1e-5) to be much smaller value than measurement noise (1e-1). 

Your help() function, however, describes the situation correctly: "The real and the estimated points are connected with yellow line segment” 
so your intentions were right but the implementation was wrong.
```
## History
Repository: opencv
Issue: medianBlur() performance drop on ARM between v2.4 and v3.0
Labels: bug,auto-transferred,priority: normal,category: imgproc,affected: 3.4

Transferred from http://code.opencv.org/issues/4446

```
|| Tom Mises on 2015-06-28 01:48
|| Priority: Normal
|| Affected: branch 'master' (3.0-dev)
|| Category: None
|| Tracker: Bug
|| Difficulty: 
|| PR: 
|| Platform: ARM / Mobile/Embedded Linux
```
## medianBlur() performance drop on ARM between v2.4 and v3.0

```
medianBlur() is significantly slower on ARM Cortex-A8 in OpenCV 3.0 than in OpenCV 2.4. The performance drop was at least 50%, I tested this a couple weeks ago and do not remember exactly.

The 2.4 version was from Gumstix repository. The 3.0 was compiled with the following flags: @-DENABLE_VFPV3=ON -DENABLE_NEON=ON -DSOFTFP=ON@.

After reviewing the code, I see the difference is that some NEON intrinsics were added in OpenCV 3.0. I am no expert in NEON, however, based on my research, when using intrinsics without thorough understanding of NEON and thorough testing, it is easy to end up with the code which actually performs worse than the compiler-optimized code. I suspect this is what happened here.

As a point of interest, I needed this for a bitmap and I ended up writing the straightforward function attached below. After compiling with @gcc -Ofast -mfpu=neon@, it is 20 times faster than medianBlur().

<pre>
void median5x5(uint8_t *mask_in, uint8_t *mask_out, uint16_t width, uint16_t height) {
        uint32_t first_idx = 2 * width + 2;
        uint32_t last_idx = width*height - 2 * width - 3;
        for(uint32_t i = first_idx; i < last_idx; i++) {
                uint8_t sum = 0;
                for(int8_t ver_offset = -2; ver_offset < 3; ver_offset++) {
                        for(int8_t hor_offset = -2; hor_offset < 3; hor_offset++) {                                
                                sum += *(mask_in + i + ver_offset*width + hor_offset);
                        }
                }
                *(mask_out + i) = sum > 12;
        }
}
</pre>
```
## History
Repository: opencv
Issue: calcHist should handle parallel operations for small images better
Labels: auto-transferred,priority: normal,feature,category: core

Transferred from http://code.opencv.org/issues/4465

```
|| Damon Maria on 2015-07-06 00:00
|| Priority: Normal
|| Affected: None
|| Category: core
|| Tracker: Feature
|| Difficulty: 
|| PR: 
|| Platform: None / None
```
## calcHist should handle parallel operations for small images better

```
At the moment calcHist always tries to split the image up by rows and perform the operation in parallel under TBB. 

There are a couple of problems:
* If the height of the image is less than the threads TBB is using then OpenCV sends a grainSize of 0 to TBB which is invalid and violates an assertion in TBB
* For small (in height) images on machines with many cores the overhead of TBB can far exceed the benefit of splitting up the operation, and may even cause stalls inside TBB (see #4353)
```
## History
##### Alexander Alekhin on 2015-07-15 10:01

```
Current implementation of calcHist contains TBB only optimization under "#if HAVE_TBB"
Need to verify existed parallel optimization and to check possibility of migration to "parallel_for_"

P.S. Also need to check another code under HAVE_TBB
-   Status changed from New to Open
```
Repository: opencv
Issue: Error building OpenCV 3.0.0 on MacOS X
Labels: bug,auto-transferred,priority: normal,category: build/install,affected: 3.4

Transferred from http://code.opencv.org/issues/4466

```
|| freya chen on 2015-07-06 23:17
|| Priority: Normal
|| Affected: branch 'master' (3.0-dev)
|| Category: None
|| Tracker: Bug
|| Difficulty: 
|| PR: 
|| Platform: x64 / Mac OSX
```
## Error building OpenCV 3.0.0 on MacOS X

```
I keep getting this error when building the latest opencv-3.0.0 using 'make -j8', what should I do? :

[  0%] [  1%] Built target opencv_hal
Built target zlib
[  5%] Built target libjpeg
[  9%] Built target libjasper
[ 15%] Built target libwebp
[ 15%] Built target opencv_cudev
[ 16%] Built target libpng
[ 16%] Building NVCC (Device) object modules/core/CMakeFiles/cuda_compile.dir/src/cuda/cuda_compile_generated_gpu_mat.cu.o
[ 19%] Built target libtiff
[ 24%] Built target IlmImf
In file included from <built-in>:325:
In file included from <command line>:11:
In file included from /usr/local/cuda/include/cuda_runtime.h:104:
/usr/local/cuda/include/common_functions.h:65:10: fatal error: 'string.h' file not found
#include <string.h>
         ^
1 error generated.
CMake Error at cuda_compile_generated_gpu_mat.cu.o.cmake:206 (message):
  Error generating
  /Users/Freya/Documents/opencv-3.0.0/build/modules/core/CMakeFiles/cuda_compile.dir/src/cuda/./cuda_compile_generated_gpu_mat.cu.o


make[2]: *** [modules/core/CMakeFiles/cuda_compile.dir/src/cuda/cuda_compile_generated_gpu_mat.cu.o] Error 1
make[1]: *** [modules/core/CMakeFiles/opencv_core.dir/all] Error 2
make: *** [all] Error 2
```
## History
##### Alexander Alekhin on 2015-07-07 12:05

```
If CUDA optimizations are not critical then you can add to CMake "-D WITH_CUDA=OFF" parameter (and cleanup build directory to build from scratch).
Refer to our MacOS builds (steps 5-6 contain build parameters): http://build.opencv.org/buildbot/builders/master-mac

If you want to use CUDA please check your CUDA installation and try to build CUDA examples.
If all is fine with CUDA setup then please provide more info about CUDA (version) and CMake logs.
```
Repository: opencv
Issue: Ignoring the flags of solvePnP and silently executing EPNP
Labels: bug,auto-transferred,priority: normal,category: calib3d,affected: 3.4

Transferred from http://code.opencv.org/issues/4472

```
|| Philipp Hasper on 2015-07-08 08:42
|| Priority: Normal
|| Affected: branch 'master' (3.0-dev)
|| Category: calibration, 3d
|| Tracker: Bug
|| Difficulty: 
|| PR: 
|| Platform: Any / Any
```
## Ignoring the flags of solvePnP and silently executing EPNP

```
The way how uPnP and DLS have been disabled in [1] is highly counter-intuitive:

Just executing EPNP regardless of the given flag [2] is confusing. If somebody wants to evaluate the OpenCV version of uPnP, let him do that (and not silently executing epnp in the background). Imagine somebody wants to evaluate the available PnP solvers in OpenCV and finds out that it does not matter which one he chooses because the results are all the same.

So we have to
a) remove the upnp and dls flags completely or
b) leave them in and document the unstable behavior with a warning in the online documentation.

The latter option might lead to somebody improving the algorithms

[1]: https://github.com/Itseez/opencv/pull/3828 
[2]: https://github.com/vpisarev/opencv/blob/ca19ae8b5ae53afe3ca0084c55178b8d0796b28b/modules/calib3d/src/solvepnp.cpp#L66
```
## History
Repository: opencv
Issue: MSER slower in 3.0.0 than 2.4.X
Labels: bug,auto-transferred,priority: normal,category: features2d,affected: 3.4

Transferred from http://code.opencv.org/issues/4478

```
|| Huck Wach on 2015-07-09 23:52
|| Priority: Normal
|| Affected: branch 'master' (3.0-dev)
|| Category: None
|| Tracker: Bug
|| Difficulty: 
|| PR: 
|| Platform: x64 / Linux
```
## MSER slower in 3.0.0 than 2.4.X

```
The below simple code can be built with either 2.4.X or 3.0.0 by uncommenting or commenting the #define respectively.  It simply opens an image file (I'll let you provide your own) and runs MSER on it.  On both my Linux box and my Windows box I see that its 3-4X slower in 3.0.0 than 2.4.X.  I have built both versions of OpenCV from source using cmake and stuck with the defaults...I have verified that the build settings are as close as they can be.

<pre>
#include "opencv2/highgui/highgui.hpp"
#include "opencv2\features2d\features2d.hpp"
#include "opencv2\imgproc\imgproc.hpp"
#include <iostream>
#include <chrono>
#include <ctime>

#define USE249
using namespace std;

int main(int argc, char** argv)
{
    std::cout << "OpenCV version: "
            << CV_MAJOR_VERSION << "." 
            << CV_MINOR_VERSION << "."
            << CV_SUBMINOR_VERSION
            << std::endl;
    cv::Mat im = cv::imread("C:/example.jpg", 1);
    if (im.empty())
    {
        cout << "Cannot open image!" << endl;
        return -1;
    }
    cv::Mat gray;
    cv::cvtColor(im, gray, cv::COLOR_BGR2GRAY);
    int mnArea = 40 * 40;
    int mxArea = im.rows*im.cols*0.4;
    std::vector< std::vector< cv::Point > > ptblobs;
    std::vector<cv::Rect> bboxes;
    std::chrono::time_point<std::chrono::system_clock> start, end;

    start = std::chrono::system_clock::now();
#ifndef USE249
    cv::Ptr<cv::MSER> mser = cv::MSER::create(1, mnArea, mxArea, 0.25, 0.2);
    mser->detectRegions(gray, ptblobs, bboxes);
#else
    cv::MserFeatureDetector mser(1, mnArea, mxArea, 0.25, 0.2);
    mser(gray, ptblobs);
#endif
    end = std::chrono::system_clock::now();

    std::chrono::duration<double> elapsed_seconds = end - start;
    std::time_t end_time = std::chrono::system_clock::to_time_t(end);

    std::cout << "finished computation at " << std::ctime(&end_time)
        << "elapsed time: " << elapsed_seconds.count() << "s\n";

    cv::namedWindow("image", cv::WINDOW_NORMAL);
    cv::imshow("image", im);
    cv::waitKey(0);

    return 0;
} 
</pre>
```
## History
Repository: opencv
Issue: Opencv python module "cv" always reporting "Runtime error, module compiled against API version 9 but this version of numpy is 4"
Labels: bug,auto-transferred,priority: normal,category: python bindings,affected: 3.4

Transferred from http://code.opencv.org/issues/4479

```
|| Kun  Huang on 2015-07-10 03:01
|| Priority: Normal
|| Affected: branch 'master' (3.0-dev)
|| Category: None
|| Tracker: Bug
|| Difficulty: 
|| PR: 
|| Platform: x64 / Linux
```
## Opencv python module "cv" always reporting "Runtime error, module compiled against API version 9 but this version of numpy is 4"

```
I have compiled opencv python module with numpy 1.9.0, and when I'm writing code importing cv2, it reports such an error. 
I'm quite sure my numpy version is 9, not 4. I recompiled opencv, it report this error again. 

How can I fix this error ?
```
## History
##### Alexander Alekhin on 2015-07-10 11:02

```
This message is emitted by numpy development package. Looks like OpenCV uses wrong numpy development files or Python uses wrong numpy runtime library.

1) Could you check numpy version used in Python:
<pre>
import numpy
print(numpy.__version__)
print(numpy.__file__)
</pre>

2) Try to check used numpy development files:
<pre>
import cv2
print cv2.getBuildInformation()
</pre>
Find line with numpy and "include" dir.

a) Paths for "numpy.__file__" and include dir should be similar.
b) You can also check "numpy/_numpyconfig.h" file here for lines "NPY_ABI_VERSION"/"NPY_API_VERSION"

-   Priority changed from High to Normal
```
Repository: opencv
Issue: createShapeContextDistanceExtractor()->computeDistance throws exception for certain shaped
Labels: bug,auto-transferred,priority: normal,affected: 3.4,category: shape

Transferred from http://code.opencv.org/issues/4490

```
|| Do Bi on 2015-07-21 13:15
|| Priority: Normal
|| Affected: branch 'master' (3.0-dev)
|| Category: None
|| Tracker: Bug
|| Difficulty: 
|| PR: 
|| Platform: x86 / Windows
```
## createShapeContextDistanceExtractor()->computeDistance throws exception for certain shaped

```
Using these two images

1) http://i.imgur.com/WKaFDl4.png
2) http://i.imgur.com/5ayU6qb.png

I get the following error

@OpenCV Error: Assertion failed (dims <= 2 && data && (unsigned)i0 < (unsigned)size.p[0] && (unsigned)(i1 * DataType<_Tp>::channels) < (unsigned)(size.p[1] * channels()) && ((((sizeof(size_t)<<28)|0x8442211) >> ((DataType<_Tp>::depth) & ((1<< 3) - 1))*4) & 15) == elemSize1()) in cv::Mat::at, file C:\builds\master_PackSlave-win32-vc12-static\opencv\modules\core\include\opencv2/core/mat.inl.hpp, line 894@

when running this code:

@#include "opencv2/imgproc/imgproc.hpp"
#include "opencv2/highgui/highgui.hpp"
#include "opencv2/shape/shape.hpp"
#include <math.h>
#include <iostream>

using namespace cv;
using namespace std;

vector<Point> GetContour(const Mat& img)
{
    cv::threshold(img, img, 128, 255, cv::THRESH_BINARY);
    vector<vector<Point>> conts;
    cv::findContours(img, conts, cv::RETR_LIST, cv::CHAIN_APPROX_SIMPLE);
    if (conts.empty())
        return vector<Point>();
    return conts.front();
}

int main()
{
    auto shape1 = GetContour(cv::imread("D:/shape1.png", cv::IMREAD_GRAYSCALE));
    auto shape2 = GetContour(cv::imread("D:/shape2.png", cv::IMREAD_GRAYSCALE));
    cout << createShapeContextDistanceExtractor()->computeDistance(shape1, shape2) << endl;
}@

in VC2013.

With other shapes or with createHausdorffDistanceExtractor instead of createShapeContextDistanceExtractor it does not crash.
```
## History
Repository: opencv
Issue: Build Failure on Mac OS X (GLX support)
Labels: bug,auto-transferred,priority: normal,category: highgui-gui,affected: 3.4

Transferred from http://code.opencv.org/issues/4495

```
|| Hendi Saleh on 2015-07-22 03:56
|| Priority: Normal
|| Affected: branch 'master' (3.0-dev)
|| Category: highgui-gui
|| Tracker: Bug
|| Difficulty: 
|| PR: 
|| Platform: x64 / Windows
```
## Build Failure on Mac OS X (GLX support)

```
On Mac OS X 10.6.8 configured with OpenGL, build stops at modules/highgui/src/window_QT.cpp:3364 with a not-declared error of a GLX function.

<pre>
<builddir>/opencv/modules/highgui/src/window_QT.cpp: In member function ‘virtual void GlFuncTab_QT::generateBitmapFont(const std::string&, int, int, bool, bool, int, int, int) const’:
<builddir>/opencv/modules/highgui/src/window_QT.cpp:3364: error: ‘glXUseXFont’ was not declared in this scope
<builddir>/opencv/modules/highgui/src/window_QT.cpp:3355: warning: unused variable ‘cvFuncName’
make[2]: *** [modules/highgui/CMakeFiles/opencv_highgui.dir/src/window_QT.cpp.o] Error 1
make[1]: *** [modules/highgui/CMakeFiles/opencv_highgui.dir/all] Error 2
make: *** [all] Error 2
</pre>

This is, to the best of my knowledge, the only usage of a GLX function when building with Mac OS X. It isn't appropriate to use GLX on Mac OS X because Apple uses AGL's aglUseFont for the same purpose.

This error may be related to improper @#ifdef@s: At the top of window_QT.cpp, @#ifdef Q_WS_X11@ is used to guard the inclusion of GL/glx.h. However, at line 3364, a *#ifndef Q_WS_WIN* is used to guard the use of glXUseXFont. This allows a non-Windows machine possessing X11 but lacking GLX (i.e. Mac OS X) to reach the faulty call.
```
## History