sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: opencv
Issue: Contrib: fcw_detect and fcw_train have wrong dependencies
Labels: bug,auto-transferred,priority: normal,category: build/install,affected: 3.4

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

```
|| Philipp Hasper on 2014-08-25 12:32
|| Priority: Normal
|| Affected: branch 'master' (3.0-dev)
|| Category: build/install
|| Tracker: Bug
|| Difficulty: 
|| PR: 
|| Platform: Any / Any
```
## Contrib: fcw_detect and fcw_train have wrong dependencies

```
There seems to be an error in the CMake chain: the opencv_fcw_detect and opencv_fcw_train projects which are generated when we integrate the contrib module have dependencies to
> opencv_core.lib
> opencv_imgcodecs.lib
> opencv_videoio.lib
> opencv_highgui.lib

even if the approach using opencv_world300.lib was selected and thus the libraries mentioned above are not created.

The result is a linker error.
```
## History
##### Dmitry Retinskiy on 2014-09-16 11:27

```
Roman, could you check this?
Thanks.
-   Assignee set to Roman Donchenko
-   Status changed from New to Open
-   Category set to build/install
```
Repository: opencv
Issue: MINGW 64bit detection is wrong for the most popular mingw distribution
Labels: bug,auto-transferred,priority: normal,category: build/install,affected: 3.4

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

```
|| Yaron Keren on 2014-08-27 16:58
|| Priority: Normal
|| Affected: branch 'master' (3.0-dev)
|| Category: build/install
|| Tracker: Bug
|| Difficulty: 
|| PR: 
|| Platform: x86 / Windows
```
## MINGW 64bit detection is wrong for the most popular mingw distribution

```
OpenCVConfig.cmake:89 says

  if(CMAKE_OPENCV_GCC_TARGET_MACHINE MATCHES "64")
    set(MINGW64 1)
    set(OpenCV_ARCH x64)
  else()
    set(OpenCV_ARCH x86)
  endif()

which is wrong for the most popular mingw distribution, mingw-w64 whose machinedump is "i686-w64-mingw32" even on 32 bit targets. This logic will always identify it as 64 bit.

Moreover, this logic is incompatible with OpenCVDetectCXXCompiler.cmake:96 which is supposed to do the same function:

    if(CMAKE_OPENCV_GCC_TARGET_MACHINE MATCHES "amd64|x86_64|AMD64")
      set(MINGW64 1)
    endif()

this logic will never happen.
```
## History
##### Dmitry Retinskiy on 2014-09-16 11:17

```
Roman, could you check this?
Thanks.
-   Assignee set to Roman Donchenko
-   Status changed from New to Open
-   Category set to build/install
```
Repository: opencv
Issue: Keypoint detection not deterministic (java opencv)
Labels: bug,auto-transferred,priority: normal,affected: 2.4,category: features2d

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

```
|| Moe Doe on 2014-09-12 08:12
|| Priority: Normal
|| Affected: 2.4.9 (latest release)
|| Category: features2d
|| Tracker: Bug
|| Difficulty: 
|| PR: 
|| Platform: x64 / Windows
```
## Keypoint detection not deterministic (java opencv)

```
As described in these stackoverflow post (http://stackoverflow.com/questions/25752497/keypoint-matching-just-works-two-times-java-opencv), a simple surf detection gives me different results if i run the detection several times in one application lifetime. 
If I restart the application it starts again detecting two times correct and afterwards it results in different keypoints...
```
## History
##### Dmitry Retinskiy on 2014-09-16 07:16

```
Maria, could you check the problem?
Thanks.
-   Assignee set to Maria Dimashova
-   Status changed from New to Open
-   Category set to features2d
```
Repository: opencv
Issue: VideoCapture::read(Mat) ignores CV_CAP_PROP_CONVERT_RGB flag for H264 YUV4:2:0 file 
Labels: auto-transferred,feature,priority: low,category: videoio,affected: 2.4,incomplete

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

```
|| Vit Shiryaev on 2014-09-18 22:31
|| Priority: Normal
|| Affected: 2.4.9 (latest release)
|| Category: highgui-video
|| Tracker: Bug
|| Difficulty: 
|| PR: 
|| Platform: x64 / Windows
```
## VideoCapture::read(Mat) ignores CV_CAP_PROP_CONVERT_RGB flag for H264 YUV4:2:0 file 

```
When I am trying to get gray-scale frame component from H264 YVU 4:2:0 video ( Y-component from YVU 4:2:0 ) a lot of time is wasting for useless default YUV->RGB conversion while VideoCapture::read(Mat) perfoms. And for some reasone

@VideoCapture::cap.set(CV_CAP_PROP_CONVERT_RGB, false)@ 

gives no effect (from openCV-docs "CV_CAP_PROP_CONVERT_RGB Boolean flags indicating whether images should be converted to RGB."), as I can see from splitting:

@Mat ch[3]; split(frame,ch); imshow("it must be U-channel", ch[1]);@

frames are still in RGB, not YUV, i.e. VideoCapture::read(Mat) *ignores* CV_CAP_PROP_CONVERT_RGB flag and yuv420_bgr24_MMXEXT from opencv_ffmpeg249.dll still takes much time as I can see from AMD CodeXL profiler.
```
## History
Repository: opencv
Issue: Intel® RealSense™ SDK (former Intel® Perceptual Computing SDK) support
Labels: bug,auto-transferred,priority: normal,category: build/install,affected: 2.4

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

```
|| Eric Guleksen on 2014-09-25 03:04
|| Priority: Normal
|| Affected: 2.4.9 (latest release)
|| Category: build/install
|| Tracker: Bug
|| Difficulty: Medium
|| PR: 
|| Platform: Any / Any
```
## Intel® RealSense™ SDK (former Intel® Perceptual Computing SDK) support

```
Prior versions of OpenCV supported the former Intel Perceptual Computing SDK natively after switching flags in the CMake file while rebuilding OpenCV. Due to a naming change and reorganization of the SDK, OpenCV support no longer is functional. 

Specific Errors when attempting to build OpenCV with this new SDK:
    The Environment variable PCSDK_DIR is no longer set by the SDK, it has been renamed to RSSDK_DIR, so all files which look for this environment variable will no longer function
    Specifically, the pxcsmartptr.h, and pxcscheduler.h files are missing. Different implementation is needed to ensure successful build.
```
## History
##### Vladislav Vinogradov on 2014-09-30 10:46

```
Hello Eric,

Thanks for your report.

Could you fix the issue on your side and submit a pull request (http://code.opencv.org/projects/opencv/wiki/How_to_contribute)?
Your contribution will be highly appreciated!
-   Assignee set to Eric Guleksen
-   Status changed from New to Open
-   Category set to build/install
```
Repository: opencv
Issue: calcHist() should raise error for incompatible nimages and dims
Labels: bug,auto-transferred,category: imgproc,priority: low,affected: 2.4

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

```
|| Baris Demiroz on 2014-09-25 14:19
|| Priority: Low
|| Affected: 2.4.9 (latest release)
|| Category: imgproc, video
|| Tracker: Bug
|| Difficulty: 
|| PR: 
|| Platform: Any / Any
```
## calcHist() should raise error for incompatible nimages and dims

```
When @dims=1@ is passed to @calcHist()@ doesn't take @nimages@ parameter into account, and processes as if @nimages=1@. However, this is not directly or intuitively visible from the documentation. Documentation should be more clear about this behavior and/or @calcHist()@ should raise an error via @CV_Assert()@ for incompatible parameters. The first impression of the function signature is that it is going to aggregate the histograms of all the given images.

PS. I found the whole @calcHist()@ usage obscure, it is very hard to understand and use unlike most of the OpenCV.
```
## History
##### Vladislav Vinogradov on 2014-09-30 12:00

```
Hello Baris,

Could you add a sample code to reproduce the issue?
-   Operating System changed from Windows to Any
-   HW Platform changed from x64 to Any
-   Assignee set to Baris Demiroz
-   Status changed from New to Incomplete
-   Category set to imgproc, video
```
Repository: opencv
Issue: Android VideoCapture output format is not clarified and is missing native YUV NV21
Labels: auto-transferred,priority: normal,feature,category: videoio(camera)

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

```
|| Ayberk Özgür on 2014-09-26 14:48
|| Priority: Normal
|| Affected: None
|| Category: highgui-camera
|| Tracker: Feature
|| Difficulty: Easy
|| PR: https://github.com/Itseez/opencv/pull/3280
|| Platform: None / None
```
## Android VideoCapture output format is not clarified and is missing native YUV NV21

```
In cap_android.cpp, the @CvCapture_Android::retrieveFrame( int outputType )@ function takes the raw YUV NV21 (yuv420sp) frame and converts it to one of greyscale, RGB or RGBA to be output to the outside world (see https://github.com/Itseez/opencv/blob/master/modules/videoio/src/cap_android.cpp#L428). This is tied to the @channel@ parameter of @VideoCapture::retrieve(cv::Mat,int)@ which can take one of @CV_CAP_ANDROID_GREY_FRAME@, @CV_CAP_ANDROID_COLOR_FRAME_BGR@, @CV_CAP_ANDROID_COLOR_FRAME_RGB@, @CV_CAP_ANDROID_COLOR_FRAME_BGRA@ or @CV_CAP_ANDROID_COLOR_FRAME_RGBA@. This has two problems:

1) Passing the output type to @VideoCapture@ as @channel@ is very unintuitive. It should at least be passed as a @CV_CAP_@ parameter to the @CvCapture_Android@ object itself through @VideoCapture@, something like @CV_CAP_PROP_ANDROID_OUTPUT_TYPE@. If there's a good reason for passing it as a channel, then it should be properly documented.

2) YUV NV21 type output is missing. There are good reasons for having it as a possible output type, e.g avoiding color space conversions in CPU altogether when only drawing it on screen via a GL shader. YUV NV21 output support could easily be added in ~15 lines of code since it is the default color space of the raw camera image and it is the only space that is guaranteed to be supported by all Android hardware.
```
## History
##### Ilya Lavrenov on 2014-09-27 08:24

```
-   Assignee set to Alexander Smorkalov
```
##### Ayberk Özgür on 2014-09-29 13:12

```
PR opened for this: https://github.com/Itseez/opencv/pull/3280
-   % Done changed from 0 to 100
```
##### Alexander Smorkalov on 2014-09-30 09:47

```
-   Pull request set to https://github.com/Itseez/opencv/pull/3280
```
##### Philip L on 2015-05-24 12:27

```
-   % Done changed from 100 to 0
-   Status changed from New to Open
```
Repository: opencv
Issue: MOG2_Applay test scenario does not look realistic.
Labels: bug,auto-transferred,priority: normal,affected: 3.4,category: ocl

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

```
|| Konstantin Rodyushkin on 2014-09-29 06:40
|| Priority: Normal
|| Affected: branch 'master' (3.0-dev)
|| Category: ocl
|| Tracker: Bug
|| Difficulty: Easy
|| PR: 
|| Platform: Any / Any
```
## MOG2_Applay test scenario does not look realistic.

```
MOG2_applay test resets BG/FG statistics every 5 frames that is not realistic. In real scenario FG/BG statistic is collected a long period of time and reset rare in unexpected cases. As result BackgroundSubstructionMOG2.applay performance data gathered by the test is not for real usage case. That makes it unusable.
It is needed to significantly increase processed frames number before statistic is reset.
```
## History
##### Konstantin Rodyushkin on 2014-09-29 07:03

```
Also, the recreation MOG object and statistic reset is rare operations but it is included int measurement scope. So this test is for "Create MOG + Applay" operation but not for Applay
```
##### Ilya Lavrenov on 2014-09-30 14:42

```
-   Assignee changed from Vadim Pisarevsky to Alexander Karsakov
-   Category changed from imgproc, video to ocl
```
Repository: opencv
Issue: Highgui_Video.prop_fps test fails on Ubuntu 14.04 with FFMPEG
Labels: bug,auto-transferred,priority: normal,category: videoio,affected: 3.4

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

```
|| Alexander Smorkalov on 2014-09-30 09:37
|| Priority: Normal
|| Affected: branch 'master' (3.0-dev)
|| Category: highgui-video
|| Tracker: Bug
|| Difficulty: 
|| PR: 
|| Platform: x64 / Linux
```
## Highgui_Video.prop_fps test fails on Ubuntu 14.04 with FFMPEG

```
FFmpeg reports -nan fps value on Ubuntu 14.04 with default version of FFmpeg.
The same test works ok with older FFmpeg from Ubuntu 12.04.
```
## History
Repository: opencv
Issue: Normalization of 16UC histogram
Labels: auto-transferred,priority: normal,feature,category: imgproc,category: video

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

```
|| Alex Stax on 2014-10-03 07:40
|| Priority: Normal
|| Affected: None
|| Category: imgproc, video
|| Tracker: Feature
|| Difficulty: 
|| PR: 
|| Platform: None / None
```
## Normalization of 16UC histogram

```
Currently there is only 8UC histogram normalization functionality.

Could you please add an 16UC implementation?

Thank you
```
## History
##### Steven Puttemans on 2014-10-03 08:15

```
Hello Alex,

Keep in mind that this is an open source library which highly depends on contributions of its user group.
Are you maybe up in adapting the 8 bit code to 16 bit and see how far it gets you?
If you succeed you could supply a PR with the functionality.

This will be the fastest way to get it into the library.

Steven
-   Assignee set to Alex Stax
-   Status changed from New to Open
```
##### Vadim Pisarevsky on 2015-05-25 11:21

```
-   Category set to imgproc, video
```
Repository: opencv
Issue: HDR Imaging - assert failure during merge_mertens
Labels: bug,auto-transferred,priority: normal,affected: 3.4,category: photo

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

```
|| Jo Z on 2014-10-05 08:58
|| Priority: Normal
|| Affected: branch 'master' (3.0-dev)
|| Category: photo
|| Tracker: Bug
|| Difficulty: 
|| PR: 
|| Platform: x86 / Windows
```
## HDR Imaging - assert failure during merge_mertens

```
According to the HDR-Tutorial: http://docs.opencv.org/trunk/doc/tutorials/photo/hdr_imaging/hdr_imaging.html#hdrimaging
Merge_Mertens does not work.

+Example Code:+

cv::Mat fusion;
cv::Ptr<cv::MergeMertens> merge_mertens = cv::createMergeMertens();
merge_mertens->process(images, fusion);

+Execution results always in the following error:+

OpenCV Error: Assertion failed (y == 0 || (data && dims >= 1 && (unsigned)y < (u nsigned)size.p[0])) in cv::Mat::ptr, file C:\builds\master_PackSlave-win64-vc11- static\opencv\modules\core\include\opencv2/core/mat.inl.hpp, line 750

+The bug happens in this line of code (example: 7 images in the vector, crash at image 4):+

for(int lvl = 0; lvl < maxlevel; lvl++) {
    Mat up;
    pyrUp(img_pyr[lvl + 1], up, img_pyr[lvl].size());
    img_pyr[lvl] -= up;
 }

Images are not huge so memory consumption should not be a problem.
```
## History
##### Steven Puttemans on 2014-10-06 08:30

```
Hello!

Before processing that vector of images, could you try doing something dumb and loop over each vector position and imshow the images.
Your error seems due to the fact that there is no data where it expects data to be.

Regards,

Steven
-   Assignee changed from Leonid Beynenson to Jo Z
-   Status changed from New to Open
```
##### Maksim Shabunin on 2015-04-27 09:11

```
-   Target version changed from 3.0-alpha to 3.0
```
##### Vadim Pisarevsky on 2015-05-14 16:42

```
there is regression test on MergeMertens, which passes on different platforms. Without particular sample code and data we could not reproduce the problem and can not fix it.
-   Status changed from Open to Incomplete
```
Repository: opencv
Issue: automated ruby bindings for opencv
Labels: auto-transferred,feature,category: build/install,effort: ∞

**Blocked** by #11666

---

Transferred from http://code.opencv.org/issues/3949

```
|| Alexander  Duda on 2014-10-11 12:23
|| Priority: Normal
|| Affected: None
|| Category: None
|| Tracker: Feature
|| Difficulty: Easy
|| PR: 
|| Platform: None / None
```
## automated ruby bindings for opencv

```
I am wondering if there is an interest in having automated ruby bindings for OpenCV as a OpenCV module.

At the moment I am maintaining ropencv (http://www.ropencv.aduda.eu) which is a ruby gem using the python parser to automatically generate a C layer for all OpenCV C++ methods and a ruby ffi integration script which mimics the C++ interface. The binding is around for over a year and compatible to OpenCV >= 2.4.4. If there is an interest I can integrate it into OpenCV and make a pull request.
```
## History
##### Steven Puttemans on 2014-10-11 13:40

```
Hello! If you are up to making a PR, adding decent documentation and maybe some ruby examples on how to use the bindings, then I am sure people will like the effort!
However, keep in mind that you will have to adapt the bindings to the 3.0 code base, since extra modules are only allowed in master branch and at the opencv_contrib repository.
-   Status changed from New to Open
```
##### Alexander  Duda on 2014-10-13 13:06

```
What would be the preferred way of adding the module "ruby" (master branch or opencv_contrib)?
```
##### Steven Puttemans on 2014-10-13 14:07

```
Definately the contrib module. No new functionality will be accepted inside the current master branch unless opencv developers decide to integrate it from the contrib repository when a stable and well research modules has been achieved.
```
##### Alexander  Duda on 2014-10-18 12:43

```
pull request: https://github.com/Itseez/opencv_contrib/pull/116
```
Repository: opencv
Issue: VideoWriter_GPU is broken since NVIDIA driver 344.11
Labels: bug,auto-transferred,priority: normal,affected: 2.4,category: gpu/cuda (contrib)

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

```
|| Sergey Ravdin on 2014-10-14 08:50
|| Priority: Normal
|| Affected: 2.4.9 (latest release)
|| Category: gpu (cuda)
|| Tracker: Bug
|| Difficulty: 
|| PR: 
|| Platform: x64 / Windows
```
## VideoWriter_GPU is broken since NVIDIA driver 344.11

```
New drivers from NVIDIA for Windows completely dropped support for NVCUVENC for NVENC. This means that current implementation of VideoWriter_GPU is useless and produces access violation errors in NVCreateHWEncoder() in video_writer.cpp in VideoWriter_GPU constructor.
Earlier versions of driver lacked nvcuvenc.dll, but VideoWriter_GPU still worked if that dll is placed into system. Now it doesn't.
```
## History
Repository: opencv
Issue: Issues with shared library naming when using mangled paths
Labels: bug,auto-transferred,priority: normal,category: build/install,affected: 3.4

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

```
|| Gautier Minster on 2014-10-21 10:33
|| Priority: Normal
|| Affected: branch 'master' (3.0-dev)
|| Category: build/install
|| Tracker: Bug
|| Difficulty: 
|| PR: 
|| Platform: Any / Linux
```
## Issues with shared library naming when using mangled paths

```
Hello,

When compiling OpenCV using mangled paths, using versions such as @3.0.0-dev@ or @3.0.0-alpha@, two problems arise:
1. The resulting pkg-config file (eg. @opencv-3.0.0-dev.pc@) refers to the shared libraries using the following format: <pre>libopencv_core.so.3.0.0-dev</pre>
This file does not exist however, the shared libraries are named without the "-dev": <pre>libopencv_core.so.3.0.0</pre>
This of course prevents pkg-config from working.

2. The namelinks of the shared libraries are set: on my system, with a working version of OpenCV 2.4.9, a symlink <pre>libopencv_core.so -> libopencv_core.so.2.4</pre> existed.
Upon installing OpenCV 3.0.0-dev, this symlink was replaced by <pre>libopencv_core.so -> libopencv_core.so.3.0</pre>, breaking OpenCV 2.4.9's pkg-config configuration.

Attached is a patch which:
- fixes the output name of the shared objects when using mangled paths, by adding the OPENCV_VERSION_STATUS to them
- adds the NAMELINK_SKIP flag to the CMake install of shared libraries when using mangled paths, so that already installed namelinks do not get overwritten

Do these 2 changes seem acceptable?

Kind regards,

-- 
Gautier
```
## History
##### Steven Puttemans on 2014-10-21 12:30

```
Personnally I would not change the use of the namelinks. Now it is fairly easy to build different OpenCV fixes, add a single `pkg-config opencv --libs` to your compiler settings and then just apply a `sudo make install` into the build folder you want to be running. This way you never have to adapt your OpenCV software projects to try out different installations.
```
##### Gautier Minster on 2014-10-23 06:17

```
You would not use mangled paths at all then, and simply install the specific build of OpenCV you want to use at this point? (since when using mangled paths, the pkg-config OpenCV configuration file has a mangled name too)

(note: i deleted the assignee, not sure if that was a mistake on my part or if it was auto-assigned at issue creation)
-   Assignee deleted (Roman Donchenko)
```
Repository: opencv
Issue: Add eclipse PATH setup details to the Java tutorial
Labels: bug,auto-transferred,priority: low,category: documentation,affected: 2.4

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

```
|| Phil W on 2014-10-26 12:43
|| Priority: Low
|| Affected: branch '2.4' (2.4-dev)
|| Category: documentation
|| Tracker: Bug
|| Difficulty: Easy
|| PR: 
|| Platform: Any / Windows
```
## Add eclipse PATH setup details to the Java tutorial

```
The Eclipse Setup [1] documentation seems to lack the info to setup the PATH variable needed to use certain functionality.

Suggestion:
Add "C:\path\to\opencv\dlls" to the Windows PATH variable or use the Environment tab in Eclipse as shown on the screenshot.

1: http://docs.opencv.org/trunk/doc/tutorials/introduction/java_eclipse/java_eclipse.html
```
## History
Repository: opencv
Issue: solvePnP: is not handling all degenerated cases
Labels: bug,auto-transferred,priority: normal,category: calib3d,affected: 2.4

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

```
|| Alexander  Duda on 2014-10-29 10:47
|| Priority: Normal
|| Affected: 2.4.9 (latest release)
|| Category: calibration, 3d
|| Tracker: Bug
|| Difficulty: 
|| PR: 
|| Platform: Any / Any
```
## solvePnP: is not handling all degenerated cases

```
Depending on the point configuration and the selected method solvePnP returns wrong solutions
(deviation > 1-e3)

1000 Tests with four fixed scene points (A;B,C,D) and random camera positions

   case 1 right angle between ABC; all scene points are coplanar:
   SOLVEPNP_ITERATIVE  - 0    wrong solutions
   SOLVEPNP_P3P        - 445  wrong solutions
   SOLVEPNP_EPNP       - 0    wrong solutions
   SOLVEPNP_DLS        - 4    wrong solutions
   SOLVEPNP_UPNP       - 1000 wrong solutions

   case 2 right angle between ABC (D is not coplanar to ABC);
   SOLVEPNP_ITERATIVE  - 634  wrong solutions
   SOLVEPNP_P3P        - 397  wrong solutions
   SOLVEPNP_EPNP       - 884  wrong solutions
   SOLVEPNP_DLS        - 0    wrong solutions
   SOLVEPNP_UPNP       - 1000 wrong solutions

   case 3 (general configuration)
   SOLVEPNP_ITERATIVE  - 701  wrong solutions
   SOLVEPNP_P3P        - 0    wrong solutions
   SOLVEPNP_EPNP       - 613  wrong solutions
   SOLVEPNP_DLS        - 0    wrong solutions
   SOLVEPNP_UPNP       - 1000 wrong solutions

   case 4 (general configuration + 2 additional points)
   SOLVEPNP_ITERATIVE  - 0    wrong solutions
   SOLVEPNP_P3P        - 
   SOLVEPNP_EPNP       - 0    wrong solutions
   SOLVEPNP_DLS        - 0    wrong solutions
   SOLVEPNP_UPNP       - 6    wrong solutions

The main problem might be a lack of documentation because P3P is only handling the main case and should only be used in combination with RANSAC and environments having only a few right angles.
```
## History