sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: opencv
Issue: Horn & Lucas Kanade Legacy
Labels: auto-transferred,feature,priority: low,category: legacy,category: contrib

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

```
|| Juan Perez Rua on 2014-07-22 12:36
|| Priority: Low
|| Affected: None
|| Category: legacy, contrib
|| Tracker: Feature
|| Difficulty: 
|| PR: 
|| Platform: None / None
```
## Horn & Lucas Kanade Legacy

```
Hello,

I was just wondering if its really helpful to have Horn and Lucas-Kanade optical flow methods as legacy/obsolete as they are used even in modern fusion-based optical flow methods (like the fusionflow). The point is that these methods though old are still referents in the motion estimation state of the art. I could do some work with the c++ interface if you think it shouldn't be labeled as legacy.

Juan
```
## History
##### Dmitry Retinskiy on 2014-09-17 10:41

```
-   Category set to legacy, contrib
```
Repository: opencv
Issue: Concurrency in cuda module fails with visual studio
Labels: bug,auto-transferred,priority: normal,affected: 3.4,category: gpu/cuda (contrib)

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

```
|| Ernest Galbrun on 2014-07-23 12:12
|| Priority: Normal
|| Affected: branch 'master' (3.0-dev)
|| Category: gpu (cuda)
|| Tracker: Bug
|| Difficulty: 
|| PR: 
|| Platform: x64 / Windows
```
## Concurrency in cuda module fails with visual studio

```
I have had trouble using the cuda functions in a multithreaded environment. After some investigation, it appears that the issue comes from the function-scope static members used in cuda_stream.cpp

As specified here, function-scope static initialization is not thread safe:
http://msdn.microsoft.com/en-us/library/vstudio/s1sb61xd(v=vs.120).aspx

I suggest using a file-scope static variable and an excplicit initialization function since we want to defer the execution of the initialization until we need the variable.

I have implemented the changes but since it deals with core functionality of cuda opencv I would like a direct opinion about that.
```
## History
##### Dmitry Retinskiy on 2014-09-17 07:35

```
Ernest,

thanks for the suggested correction. 
Please put it in the form of pull request (see http://www.code.opencv.org/projects/opencv/wiki/How_to_contribute).
Each pull request is automatically tested and then reviewed before merge.
-   Assignee set to Ernest Galbrun
-   Status changed from New to Open
-   Category set to gpu (cuda)
```
Repository: opencv
Issue: Nvcc error: Only when targeting sm_20 or higher
Labels: bug,auto-transferred,priority: normal,affected: 3.4,category: gpu/cuda (contrib)

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

```
|| hoa Hong on 2014-07-24 05:11
|| Priority: Normal
|| Affected: branch 'master' (3.0-dev)
|| Category: gpu (cuda)
|| Tracker: Bug
|| Difficulty: 
|| PR: 
|| Platform: x86 / Windows
```
## Nvcc error: Only when targeting sm_20 or higher

```
Hi,

I'm building latest opencv 3.0 from source with CUDA SDK 5.5. My graphics card is Gigabyte NVidia GeForce 9800GTX+ with 1.1 computability. When building opencv_core module, i get this error:

"*nvcc : fatal error : nvcc supports '--relocatable-device-code=true (-rdc=true)' , '--device-c (-dc)' and '--device-link (-dlink)' only when targeting sm_20 or higher*"

CMake settings:
CUDA_ARCH_BIN: 1.1 1.2 1.3 2.0 2.2(2.0) 3.0.3.5
CUDA_ARCH_PTX: 3.0

Enviroment and tools:
Visual Studio C++ 2012
Windows 7 

I changed CUDA_ARCH_BIN and CUDA_ARCH_PTX but i seems that doesn't affect.

Is it possible a bug?
```
## History
##### Steven Puttemans on 2014-07-25 07:32

```
Since 3.0 is a development branch OpenCV does not guarantee it will build without problems. I experience similar GPU building problems with 3.0 compute capability, seems this is indeed an unfixed bug!
```
##### hoa Hong on 2014-07-27 15:32

```
Steven Puttemans wrote:
> Since 3.0 is a development branch OpenCV does not guarantee it will build without problems. I experience similar GPU building problems with 3.0 compute capability, seems this is indeed an unfixed bug!

Do you know how to fix it?
```
##### Steven Puttemans on 2014-07-28 07:14

```
Nope :) My GPU experience is limited to using the functions :)
```
##### Vadim Pisarevsky on 2015-04-28 11:42

```
-   Category changed from core to gpu (cuda)
```
Repository: opencv
Issue: XIMEA Image format incorrect after DOWNSAMPLING
Labels: bug,auto-transferred,priority: normal,affected: 2.4,category: videoio(camera)

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

```
|| Jean-Yves Deschenes on 2014-07-31 15:12
|| Priority: Normal
|| Affected: 2.4.9 (latest release)
|| Category: highgui-camera
|| Tracker: Bug
|| Difficulty: Easy
|| PR: 
|| Platform: x64 / Windows
```
## XIMEA Image format incorrect after DOWNSAMPLING

```
If I open a XIMA camera and set the downsampling, the retrieved capture frames will have the wrong dimensions.

<pre>
        // Open the camera:
    cv::VideoCapture cam;
        cv::Mat bufferFrame;
        int columns = 0;

    cam.open(inputName);
        cam.read(bufferFrame); 
        columns = bufferFrame.columns;  //  _Columns value is 2592_

        cam.set(CV_CAP_PROP_XI_DATA_FORMAT, XI_RGB24 );
        cam.set(CV_CAP_PROP_XI_DOWNSAMPLING, ximeaDefaultBinningMode);

        // In the thread loop
    cam.read(bufferFrame);
        columns = bufferFrame.columns;  //  _Columns value is still 2592_
</pre>

Now, that seems to come from the fact that, in cap_ximea.cpp, 

<pre>
        void CvCaptureCAM_XIMEA::resetCvImage()  // Called from CvCaptureCAM_XIMEA::retrieveFrame()
        {
         ...
        if( (int)image.width != width || (int)image.height != height || image.frm != (XI_IMG_FORMAT)format)
        ...
        }
</pre>
the validation checks for the identity of the _image_ dimensions (which are the same, since they were updated by the internal CvCaptureCAM_XIMEA::grabFrame() call), but does not check for the identity of the _frame_ dimensions (which have not been changed, and need to).
An  easy fix probably would be to add a check of the frame.cols and frame.rows in that condition line.
```
## History
##### Dmitry Retinskiy on 2014-09-18 05:49

```
Jean-Yves, thanks for the report.
Could you put your suggested correction in the form of pull request? 
(see http://www.code.opencv.org/projects/opencv/wiki/How_to_contribute for details).
Thanks.
-   Target version deleted (2.4.10)
-   Description changed from If I open a XIMA camera and set the
    downsampling, the retrieved capture frame... to If I open a XIMA
    camera and set the downsampling, the retrieved capture frame... More
-   Assignee set to Jean-Yves Deschenes
-   Status changed from New to Open
```
Repository: opencv
Issue: calcOpticalFlowPyrLK() returns points outside the image
Labels: bug,auto-transferred,priority: normal,category: imgproc,category: video,affected: 2.4

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

```
|| Philipp Hasper on 2014-07-31 17:40
|| Priority: Normal
|| Affected: branch '2.4' (2.4-dev)
|| Category: imgproc, video
|| Tracker: Bug
|| Difficulty: 
|| PR: 
|| Platform: Any / Any
```
## calcOpticalFlowPyrLK() returns points outside the image

```
calcOpticalFlowPyrLK() returns points outside the image and marks them as valid (status[i]==true). So far I only observed points with coordinates slightly bigger than the boundaries but no negative values.
This issue is easily reproducible since it occurs in nearly every call of the function.
Just run the attached code (this is the lkdemo.cpp example with one simple assertion added in line 109):

I could not track down the bug maybe it happens in lkpyramid.cpp, function @LKTrackerInvoker::operator()@, line 428: @nextPts[ptidx] = nextPt + halfWin;@ Here we just add a window width and this may lead to a point outside the image.
```
## History
##### Philipp Hasper on 2014-07-31 18:08

```
I have to correct: I also experienced negative values.
```
##### Dmitry Retinskiy on 2014-09-16 07:03

```
Vadim, please check the problem.
Thanks.
-   Priority changed from High to Normal
-   Assignee set to Vadim Pisarevsky
-   Status changed from New to Open
-   Category set to imgproc, video
```
Repository: opencv
Issue: Reading Image without Meta-Data fails
Labels: auto-transferred,feature,priority: low,affected: 2.4,category: imgcodecs

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

```
|| M B on 2014-08-04 12:29
|| Priority: Normal
|| Affected: 2.4.9 (latest release)
|| Category: highgui-images
|| Tracker: Bug
|| Difficulty: 
|| PR: 
|| Platform: x86 / Windows
```
## Reading Image without Meta-Data fails

```
* Bug concering imread -> imread does not read image without metadata
* fixed by editing image meta data (e.g. setting a title or cameratype)
* testimages: 
not working: https://docs.google.com/file/d/0B5AU_enXY31NQlJ2eVU2WmdwRVk/edit
and working: https://docs.google.com/file/d/0B5AU_enXY31NbWxFSmJnbWhuZ2s/edit
* Asked @Q&A 4 weeks ago without an answer: http://answers.opencv.org/question/35944/imread-without-exif-title-results-in-invalid-mat/


+Long report:+
The error occurs when I try to load an 16bit tiff grayscale image without a meta data set in its details created by a camera software.
It can be viewed with ImageJ without problem.

When I try to load it with imread it results in an empty matrix, which has the wrong type, as well as one wrong dimension.
It should be UINT16, 1x768x768, but the debugger tells me it is UINT8, 1x768x0.

Not working image:
https://docs.google.com/file/d/0B5AU_enXY31NQlJ2eVU2WmdwRVk/edit

If I open the preferences of the image and change the title in details to anything and press ok, I can open it and its read perfectly.

Same image with title changed:
https://docs.google.com/file/d/0B5AU_enXY31NbWxFSmJnbWhuZ2s/edit

I use ImageWatch which tells me that my matrix has no dimensions when I try to load the first sample image.

The images are uncompressed 16bit tiff files, generated by a 12bit camera.
If I open and save the image with ImageJ and set a certain display range (eg 16bit) and save it, the described "trick" will not help anymore.


+My setup:+
Win 8.1 (64bit)
C++ VS2013 (32bit)
OpenCv 2.4.9

+My test code:+
<pre>
#include "stdafx.h"
#include <opencv2/core/core.hpp>
#include <opencv2/highgui/highgui.hpp>

using namespace cv;
using namespace std;


int _tmain(int argc, _TCHAR* argv[])
{
    string path = "C:\\Users\\...\\Pictures\\testimage.tiff";

    Mat A;
    A = cv::imread(path, CV_LOAD_IMAGE_GRAYSCALE);

    namedWindow("A", CV_WINDOW_NORMAL);
    resizeWindow("A", A.cols, A.rows);
    imshow("A", A);

    waitKey(0);
    return 0;
}
</pre>
```
## History
##### Dmitry Retinskiy on 2014-09-18 05:53

```
Alexander, could you check this?
Thanks.
-   Assignee set to Alexander Smorkalov
-   Status changed from New to Open
```
Repository: opencv
Issue: Add support for broadcasting arithmetical and logic operands
Labels: auto-transferred,priority: normal,feature,category: core

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

```
|| Goncalo Lopes on 2014-08-04 13:37
|| Priority: Normal
|| Affected: None
|| Category: core
|| Tracker: Feature
|| Difficulty: 
|| PR: 
|| Platform: None / None
```
## Add support for broadcasting arithmetical and logic operands

```
This allows for easy and efficient vectorization for basic arithmetic and logic, similar to NumPy:
http://docs.scipy.org/doc/numpy/user/basics.broadcasting.html

This is possible when using OpenCV in Python because of the NumPy interface, but it would be very desirable to be able to do this in C++ as well.

Also, it would be nice to be able to do this without resorting to intermediate buffer allocations and the use of cv::repeat (again, identical to NumPy broadcasting).
```
## History
Repository: opencv
Issue: Cascadeclassifier_gpu with cv::gpu::stream support
Labels: auto-transferred,priority: normal,feature,category: objdetect

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

```
|| T Abdullah on 2014-08-06 09:46
|| Priority: Normal
|| Affected: None
|| Category: objdetect
|| Tracker: Feature
|| Difficulty: 
|| PR: 
|| Platform: None / None
```
## Cascadeclassifier_gpu with cv::gpu::stream support

```
Dear all,



I wanted to detect objects from video streams using cascadeclassifier_gpu.detectMultiScale(...) with multiple video streams in parallel. I could execute two parallel threads. The program crashed with more than two threads (See more crash details in [[http://code.opencv.org/issues/3807]] in OpenCV DevZone). I hope to have a solution for it.

I would like to suggest cv::gpu::stream support for cascadeclassifier_gpu. As this support will enable to process multiple video files on GPU in multiple streams.


Regards,
Tariq
```
## History
##### Dmitry Retinskiy on 2014-09-17 10:31

```
-   Category set to objdetect
```
Repository: opencv
Issue: More explicit exception message when OpenGL calls made without an active context
Labels: auto-transferred,priority: normal,feature,category: infrastructure

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

```
|| Musharraf Azeem on 2014-08-06 13:35
|| Priority: Normal
|| Affected: None
|| Category: infrastructure
|| Tracker: Feature
|| Difficulty: 
|| PR: 
|| Platform: None / None
```
## More explicit exception message when OpenGL calls made without an active context

```
Functions from ogl:: are called that require an OpenGL context to be active on the current thread. When they are called without an active context, then a error with the message "Can't load OpenGL extension [ext_name]" is thrown.

The above error could be called whenever CV_GL_GET_PROC_ADDRESS fails to load an extension, which could be for a variety of reasons

In the scenario that OpenGL calls were attempted without an active OpenGL context, then this should explicitly be stated in the error message thrown. This will be especially helpful in debugging a multithreaded application.
```
## History
##### Dmitry Retinskiy on 2014-09-17 10:30

```
Musharraf, are you ready to implement your suggestion?
(see http://www.code.opencv.org/projects/opencv/wiki/How_to_contribute for details)
-   Assignee set to Musharraf Azeem
-   Category set to infrastructure
```
Repository: opencv
Issue: hogdescriptor::detectmultiscale to output feature vectors for detections
Labels: auto-transferred,feature,category: objdetect

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

```
|| Kevin Shi on 2014-08-06 16:41
|| Priority: High
|| Affected: None
|| Category: objdetect
|| Tracker: Feature
|| Difficulty: 
|| PR: 
|| Platform: None / None
```
## hogdescriptor::detectmultiscale to output feature vectors for detections

```
detectMultiScale currently just outputs a vector<Rect> with no additional information. To get the feature vectors for each detection, I have to crop the image to each rect and compute the features again, which is extremely time consuming and slowing down my code by several factors. 

Since these features are already computed in detectMultiScale, it should be possible to pass an additional argument (vector<vector<float> >& features) to detectMultiScale and have the detector write the feature vectors for each detection to this argument.
```
## History
##### Steven Puttemans on 2014-08-07 11:10

```
I like the idea, but it should be implemented in the Algorithm class so that each descriptor detector can benefit from this.
You might be up for the job yourself and try it out? Making a pull request is quite straightforward and increase the chance your feature gets in.
```
##### Dmitry Retinskiy on 2014-09-17 10:27

```
-   Target version changed from 3.0-beta to 3.0
-   Category set to objdetect
```
##### Deanna Hood on 2015-04-19 20:24

```
I'm interested in working on this. I am planning to overload each of the three existing detectMultiScale methods to have a version which provides the additional argument. Please advise if there is a preferred alternative to having 6 versions of the detectMultiScale function call.
```
##### Steven Puttemans on 2015-04-20 14:23

```
Deanna Hood wrote:
> I'm interested in working on this. I am planning to overload each of the three existing detectMultiScale methods to have a version which provides the additional argument. Please advise if there is a preferred alternative to having 6 versions of the detectMultiScale function call.

Since we are forced not to break backwards compatibility I think that overload functions with an extra parameter are the best way to go! If you are up to this in a pull request, then please also update the corresponding documentation so that people are aware of the new functionality.


-   Status changed from New to Open
```
##### Deanna Hood on 2015-05-09 17:11

```
Just updating that I haven't gotten around to this, so that others know it's not assigned
```
Repository: opencv
Issue: Dependency on Python version and default encoding
Labels: bug,auto-transferred,priority: normal,affected: 3.4,category: matlab bindings

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

```
|| Philippe FOUBERT on 2014-08-10 16:40
|| Priority: Normal
|| Affected: branch 'master' (3.0-dev)
|| Category: matlab bindings
|| Tracker: Bug
|| Difficulty: 
|| PR: 
|| Platform: x64 / Windows
```
## Dependency on Python version and default encoding

```
h1. Dependency on Python version

I have Python 2.7.8 (the latest Python 2 release version) and Python 3.4.1 (the latest Python 3 release version) installed on my computer.

The "@modules\matlab\CMakeLists.txt@" file is using the "@${PYTHON_DEFAULT_EXECUTABLE}@" variable (which is initialized with "@${PYTHON2_EXECUTABLE}@" in "@cmake\OpenCVDetectPython.cmake@") to launch the scripts "@gen_matlab.py@" and "@cvmex.py@" which are using the *"@lstrip_blocks@"* parameter which seems *not available in Python 2.7.8* :
> @jtemplate    = Environment(loader=FileSystemLoader(template_dir), trim_blocks=True, lstrip_blocks=True)@

If the "@${PYTHON_DEFAULT_EXECUTABLE}@" variable is replaced by the "@${PYTHON3_EXECUTABLE}@" variable, the error disappears.

h1. Dependency on unicode

I am working on a 64 bits OS. On such an OS, the default encoding used by Python is unicode.
=> in the "@modules\java\generator\rst_parser.py@" script, I have had to add the encoding to the open function:
> @df = open(doc, "rt" , encoding="utf_8")@
a parameter which is not compatible with Python2...

h1. Default Python executable

Since the default Python executable is not only used in the Matlab binding module, i have chosen to write an issue instead of a PR...
```
## History
Repository: opencv
Issue: Expectation maximization covariance not accepted when feeding back previous results in python
Labels: bug,auto-transferred,priority: normal,category: python bindings,affected: 2.4

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

```
|| Santiago Peñate Vera on 2014-08-14 15:00
|| Priority: Normal
|| Affected: 2.4.9 (latest release)
|| Category: python bindings
|| Tracker: Bug
|| Difficulty: 
|| PR: 
|| Platform: x64 / Windows
```
## Expectation maximization covariance not accepted when feeding back previous results in python

```
I want to train a picture, get the means, covariances, etc.. and feed them back into another train of the same picture but a bit displaced.

Apparently there is no possible way to re-feed in the covariances using EM::trainE

See the provided example at the file Test_EM.py
```
## History
Repository: opencv
Issue: DynamicAdaptedFeatureDetector for image sequences
Labels: auto-transferred,priority: normal,feature,category: features2d

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

```
|| Felix Endres on 2014-08-19 13:25
|| Priority: Normal
|| Affected: None
|| Category: features2d
|| Tracker: Feature
|| Difficulty: Medium
|| PR: 
|| Platform: None / None
```
## DynamicAdaptedFeatureDetector for image sequences

```
Hi all,
I propose a modification (or a new variant of) the @DynamicAdaptedFeatureDetector@ and @AdjusterAdapter@.

I use the opencv visual features in a mapping application. 
I noticed that the number of keypoints is crucial for the performance of the motion estimates.
If there are too few keypoints, too few matches are found. If there are too many, the detection,
extraction and matching time is high and more ambiguities arise during matching.

I once tried to use the above classes to control the amount of keypoints, but found them to create 
a big performance penalty. I recently found the reasons: 
* The change rate of the thresholds is only 10% in each iteration
* The found threshold is not stored for the next call to detect(...)

This results in many iterations that are repeated for each image in the stream.
I rewrote the mentioned classes to overcome these issues and added further small improvements.
Also, I patched ORB to expose the threshold used for the FAST keypoints, such that it is adjustable.

If someone would guide me and discuss the changes with me, I would be happy to contribute them back.

Felix
```
## History
##### Steven Puttemans on 2014-08-20 09:31

```
First of all thanks for the changes! In order to speed up the process of adapting everything and making the changes in source code it would be nice if you created a pull request.
Do keep in mind that extra functionality goes to the 3.0 dev branch and should have documentation and performance tests added, in which you can be helped when the pull request is up.

Could you try creating one? Guidelines can be found here: http://code.opencv.org/projects/opencv/wiki/How_to_contribute
-   Status changed from New to Open
```
##### Steven Puttemans on 2014-08-20 09:32

```
-   Target version set to 3.0
-   Difficulty set to Medium
```
##### Philipp Hasper on 2014-10-06 10:39

```
+1 Nice contribution!
```
##### Felix Endres on 2014-11-28 11:04

```
This is a bit embarrassing, but I cannot find the original AdjusterAdapter and DynamicAdaptedFeatureDetector in the OpenCV repositories in the master branch. The file modules/features2d/dynamic.cpp is more or less empty. After a while I found out that they should have moved to opencv_contrib (according to the commit message of 31df47b6eaeb753a77f4d0cc3f4225c5c40682f6: "moved nonfree and a part of features2d to opencv_contrib/xfeatures2d"). However, there I cannot find anything. Do you have any pointers? The proposed code is actually independent of that, but if the orignal "dynamic" parts are still there, it definitely belongs to the same module/file.
Otherwise, where should I place it?
```
Repository: opencv
Issue: Removed FilterEngine from public API
Labels: auto-transferred,priority: normal,feature,category: imgproc,category: video

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

```
|| Philippe FOUBERT on 2014-08-23 10:22
|| Priority: Normal
|| Affected: None
|| Category: imgproc, video
|| Tracker: Feature
|| Difficulty: Easy
|| PR: 
|| Platform: None / None
```
## Removed FilterEngine from public API

```
I think the removal of *FilterEngine* from the public API is not a good idea.

If we need to perform the same filter cyclically, it is very usefull (*real-time efficiency*) to be able to allocate and initialize the filter only once.

For example:
> @cv::Ptr<cv::FilterEngine> pFilter;
> // At init:
> pFilter = createBoxFilter(CV_32F, CV_32F, cv::Size(15, 15), cv::Point(-1, -1), true, cv::BORDER_DEFAULT);
> // Cyclically:
> pFilter->apply(src, dst);
> @

instead of calling cyclically:
> @cv::boxFilter(src, dst, CV_32F, cv::Size(15, 15), cv::Point(-1, -1), true, cv::BORDER_DEFAULT);
> @
```
## History