sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: opencv
Issue: namedWindow approach in combination with waitKey
Labels: auto-transferred,priority: normal,feature,category: highgui-gui

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

```
|| Steven Puttemans on 2013-08-13 12:40
|| Priority: Normal
|| Affected: None
|| Category: highgui-gui
|| Tracker: Feature
|| Difficulty: 
|| PR: 
|| Platform: None / None
```
## namedWindow approach in combination with waitKey

```
For the moment, if you want your system to be able to wait for a keystroke, the waitKey() functionality can be used. However this requires you to have an active and open namedWindow. How hard would it be to remove this dependency? Many time I want to use the waitKey functionality, without opening a window, just by displaying results in the command line. I guess others will have experienced the same.

About the namedWindow, I think it is kind of weird that the namedWindow cannot be used like an object. Each function calling to this namedWindow, needs the exact name of the window again, which makes it kind of useless to predefine a namedWindow. Might it be possible to make an object from this, on which you can call a destroy for example?
```
## History
##### Sergei Nosov on 2013-08-14 13:27

```
Hi, Steven!

Your suggestions are sound, but I don't think the issues really have high exposure.

1) you can always use smth like getchar to wait for a keystroke from user. It doesn't have the 'expiration time' parameter though, but to implement the expiration logic you must have smth like an event loop, which, for my money, doesn't worth it most of the time. Such kind of loop is started when you create named windows, so waitKey was made to work with it. You could start the loop without any windows, just to support waitKey, but again - I personally don't think it's a good design decision.
2) I believe this API is a legacy from the 'only C' days of OpenCV. It looks kind of awkward today and have potential drawbacks, but since highgui module is mostly meant for debugging, I believe it's good enough to have the work done.

That's just my opinion, I hope it makes some sense to you, too.
-   Assignee set to Alexander Smorkalov
-   Status changed from New to Open
```
##### Steven Puttemans on 2013-08-14 19:48

```
I can find myself in your opinion and yes there are probably other ways around this. 
Thanks for your input! 

Just a remark about the legacy style. I think if we want people to be pushed towards the newer C++ interface, even if it is for debugging, their should be a uniform use of objects and their functionality. That is why I think this suggestion is still valid :)
```
Repository: opencv
Issue: support for INT-Mat for remapBilinear OR adding note to documentation
Labels: auto-transferred,priority: normal,feature,category: imgproc,category: video

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

```
|| Thomas Zeugner on 2013-08-14 10:52
|| Priority: Normal
|| Affected: None
|| Category: imgproc, video
|| Tracker: Feature
|| Difficulty: Easy
|| PR: 
|| Platform: None / None
```
## support for INT-Mat for remapBilinear OR adding note to documentation

```
Hallo there,

the function "remapBilinear" (modules/imgproc/src/imgwarp.cpp : 2465) does not support INT as element for Mat-Type so the call of warpPerspective fails with a crash.
Maybe it is only the "linear_tab[]" (modules/imgproc/src/imgwarp.cpp : 3098) Array that has to be fixed??

Example code:

<pre>
    #include "opencv/cv.h"
    #include "opencv/highgui.h"

    int main( int argc, char** argv )
    {
        src = Mat::eye(480 , 640 , CV_32S);
        cv::Mat dest;

        Mat transMat = (Mat_<double>(3,3) << 0.83665, -0.0946, 35.96591, 0.00622, 0.49884, 92.2776, 0, -0.00029, 0.94627);

        cv::Size size( src.cols, src.rows);
        warpPerspective (src, dest, transMat, size, WARP_INVERSE_MAP | INTER_LINEAR  ); //-  OR: INTER_CUBIC | INTER_LINEAR

        imshow( "dest", dest );
        waitKey(0);
    }
</pre>
If it is not possible to add this functionality then PLEASE add a note to the documentation of (warpPerspective, remap, warpAffine, resize, ...) . otherwise this is pretty confusing ;-)

Thank you very much!

Note: I work with a thermographic camera that returns one channel values as mK, so I have a value range of about 0 to 2 000 000 per pixel. Of cause, I could convert this values to float but I'm worried about the performance.
```
## History
##### Sergei Nosov on 2013-08-14 14:53

```
Hi, Thomas!

I'm afraid there'll be some issues with your solution. But you're welcome to try it out, and submit a pull request with the fix and corresponding tests to https://github.com/Itseez/opencv . Alternatively, you can submit a PR on docs.

P.S. I would suggest to try converting to float (or double, if you'll encounter accuracy problems) and measuring. I guess it won't be much (if any) slower.
```
##### Sergei Nosov on 2013-08-14 15:03

```
-   Status changed from New to Open
```
##### Vadim Pisarevsky on 2015-05-13 16:01

```
looks like it's long overdue with the reply. On most platforms, even low-power ARM's, there is now hardware support for single-precision floating-point and for this operation (warpAffine/warpPerspective/remap) floating-point is needed anyway, so the suggestion is to convert data to floating-point - performance will be better. Integers till 2**24 ~ 10**7 can be represented exactly in float's.

-   Tracker changed from Bug to Feature
```
Repository: opencv
Issue: BFMatcher Indexing not suited for large scale
Labels: bug,auto-transferred,priority: low,affected: 2.4,category: features2d

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

```
|| Dominik Van Opdenbosch on 2013-08-14 12:09
|| Priority: Low
|| Affected: 2.4.0 - 2.4.6
|| Category: features2d
|| Tracker: Bug
|| Difficulty: Easy
|| PR: 
|| Platform: x64 / Linux
```
## BFMatcher Indexing not suited for large scale

```
The way the indexing is done in the Brute Force Matcher Implementation is not suited for large scale scenarios. 
The indexing is limited by the use of 32bit signed integer instead of (unsigned) 64 bit integer where available (long int): 

modules/features2d/src/matchers.cpp 
CV_Assert( (int64)imgCount*IMGIDX_ONE < INT_MAX )
```
## History
##### Sergei Nosov on 2013-08-14 15:00

```
Hi, Dominik! 

I'm not sure it's clear what you actually want to say. Could you, please, be more specific?
-   Target version set to 2.4.7
-   Status changed from New to Incomplete
```
##### Mathieu Barnachon on 2013-08-22 03:29

```
Did you mean: replace INT_MAX by INT64_MAX?
But update variable must be a int64 also.
Is it suitable for OpenCV to use 64 bits variables (for multi-plateform compatibility I mean)?
```
##### Alexander Smorkalov on 2013-11-28 05:02

```
-   Affected version changed from 2.4.6 (latest release) to 2.4.0 -
    2.4.6
-   Target version changed from 2.4.7 to 2.4.8
```
##### Alexander Smorkalov on 2013-12-30 10:38

```
-   Target version changed from 2.4.8 to 2.4.9
```
##### Alexander Smorkalov on 2014-04-30 19:05

```
-   Target version changed from 2.4.9 to 2.4.10
```
Repository: opencv
Issue: libc++ build no longer works due to use of stdlib in gpulegacy
Labels: bug,auto-transferred,priority: normal,affected: 3.4,category: gpu/cuda (contrib)

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

```
|| Miroslav Kobetski on 2013-08-21 12:56
|| Priority: Normal
|| Affected: branch 'master' (2.9)
|| Category: gpu (cuda)
|| Tracker: Bug
|| Difficulty: 
|| PR: 
|| Platform: x64 / Mac OSX
```
## libc++ build no longer works due to use of stdlib in gpulegacy

```
Compiling opencv master (2.9) doesn't work with clang and libc++ on Mac. (didn't set the std=c++11 flag  as that gives rise to a new set of errors).
gpulegacy fails during link time, and gpu cannot be compiled without gpulegacy (due to modules/gpuwarping/src/pyramids.cpp:235:12: error: use of undeclared identifier 'numLayers')

Culprits (found so far): iostream and vector in NCVBroxOpticalFlow and NCV cause link errors:

 "std::ios_base::Init::Init()", referenced from:
 __static_initialization_and_destruction_0(int, int) in cuda_compile_generated_NCV.cu.o
 __static_initialization_and_destruction_0(int, int) in cuda_compile_generated_NCVBroxOpticalFlow.cu.o
 "std::ios_base::Init::~Init()", referenced from:
  ___tcf_0 in cuda_compile_generated_NCV.cu.o
  ___tcf_0 in cuda_compile_generated_NCVBroxOpticalFlow.cu.o
 "std::__throw_length_error(char const*)", referenced from:
```
## History
##### Alexander Shishkov on 2013-08-27 08:37

```
-   Assignee set to Anatoly Baksheev
-   Category set to gpu (cuda)
```
##### Alexander Shishkov on 2013-08-27 08:38

```
Hello Miroslav! Thx for reporting!

Maybe you know some solution for this problem?
```
##### Alexander Shishkov on 2013-08-28 19:52

```
-   Status changed from New to Open
```
##### Miroslav Kobetski on 2013-11-07 10:25

```
Sorry for the late answer, just noticed that this is still open. As an update: The original problem with gpulegacy was due to an incorrect naming in the function params. The input was "nLayers", but it expected "numLayers". This particular issue seems fixed in the latest master. 

I will try to get around to looking at the rest of this problem in a week or two, and can then post an update if I can reproduce it and if I have a solution
```
Repository: opencv
Issue: Add a way to detect circles grid with unknown size
Labels: auto-transferred,priority: normal,feature,category: calib3d

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

```
|| Nikolay Tasev on 2013-08-26 11:00
|| Priority: Normal
|| Affected: None
|| Category: calibration, 3d
|| Tracker: Feature
|| Difficulty: Medium
|| PR: 
|| Platform: None / None
```
## Add a way to detect circles grid with unknown size

```
There should be a way to use findCirclesGrid() without knowing the pattern size.
This will be useful to detect or at least give a proposition for the user what is
the size of an unknown grid from a single frame. After the size is determined, the 
calibration can proceed as before on multiple frames.
I have looked in the latest source code for the symmetrical circle grid. The 
implementation first detects the grid and then checks if it matches the pattern
size. If it doesn't just rejects it. So for an unknown size this restriction 
should be removed and the detected grid should be returned.
```
## History
##### Steven Puttemans on 2013-08-26 11:12

```
Feel free to submit a pull request with the proposed adaptations. This is the quickest way to see your request integrated into the OpenCV source code. More information on how to do so, take a look at : http://code.opencv.org/projects/opencv/wiki/How_to_contribute
```
##### Alexander Shishkov on 2013-08-27 08:47

```
Ilya, could you comment this issue?
-   Difficulty changed from Easy to Medium
-   Assignee set to Ilya Lysenkov
```
##### Alexander Shishkov on 2013-08-28 19:54

```
-   Status changed from New to Open
```
##### Ilya Lysenkov on 2013-09-02 07:09

```
I agree that such a feature could be useful but the pattern size is used a lot internally in the detection algorithms. Yes, we have the final check of the pattern size but former detection will not work out of the box in case of unknown pattern size. So this is not so easy to implement with current algorithms.
```
Repository: opencv
Issue: Allow opencv_traincascade to load Haar wavelets from a file
Labels: auto-transferred,priority: normal,feature,category: objdetect

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

```
|| Ramiro Pereira de Magalhães on 2013-08-26 23:09
|| Priority: Normal
|| Affected: None
|| Category: objdetect
|| Tracker: Feature
|| Difficulty: 
|| PR: 
|| Platform: None / None
```
## Allow opencv_traincascade to load Haar wavelets from a file

```
Currently the opencv_traincascade application generates the Haar wavelets it will use for trainning. I think this application should be able to load the Haar wavelets configuration (amount and format of the rectangles and weights) from a file formated in a yet to be defined way.

The current Haar wavelet generation process could be extracted to another tool that generates a file with the default wavelets for use with the opencv_traincascade.

Thoughs?
```
## History
##### Alexander Shishkov on 2013-08-27 08:49

```
Hello Ramiro,

thanks for submitting this issue. Unfortunately we have limited resources at the moment. So if there is a chance if you have time to implement these features that would be highly appreciated! (Please see http://www.code.opencv.org/projects/opencv/wiki/How_to_contribute for details).

Thank you in advance!

-   Assignee set to Marina Kolpakova
```
##### Alexander Shishkov on 2013-08-27 08:49

```
Marina, could you please comment this issue?
```
##### Ramiro Pereira de Magalhães on 2013-08-27 18:44

```
I'm currently adapting the OpenCV code to do something like for an experiment I'm working on and I might be able to share it with the community. I'm just wondering if you have more specific guidelines or requirements about this proposed feature that I should consider.
```
##### Steven Puttemans on 2013-08-28 06:46

```
In addition to this, I still think it should be pretty nice if we could create an interface to automatically load other feature types into the traincascade algorithm. However I have no idea on how difficult this will actually be, but I am up for help if needed.
```
##### Alexander Shishkov on 2013-08-28 19:54

```
-   Status changed from New to Open
```
##### Vadim Pisarevsky on 2015-05-28 16:57

```
sounds like a feature request
-   Tracker changed from Bug to Feature
```
Repository: opencv
Issue: Update FLANN Library
Labels: auto-transferred,feature,priority: low,category: flann

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

```
|| Dominik Van Opdenbosch on 2013-09-05 08:44
|| Priority: Low
|| Affected: None
|| Category: flann
|| Tracker: Feature
|| Difficulty: Easy
|| PR: 
|| Platform: None / None
```
## Update FLANN Library

```
There are several issues with the FLANN Library which have been fixed in the flann master branch but not pulled 
to the OpenCV Code. 

https://github.com/mariusmuja/flann/commit/b72d526463e892bfc4eb30bf0c640a3cb5b9bd69#src/cpp/flann/algorithms/lsh_index.h
```
## History
##### Anna Kogan on 2013-09-05 08:50

```
Hello Dominik,

Thank you for reporting the problem. If you could make a pull request with those fixes, it would be very appreciated!
-   Assignee deleted (Marius Muja)
-   Status changed from New to Open
```
##### Alexander Smorkalov on 2013-09-09 10:01

```
-   Target version set to 2.4.7
-   Assignee set to Roman Donchenko
```
##### Prasan Samtani on 2013-09-09 17:09

```
I can take a look at this if nobody else is doing so.

It appears that the flann repo on github is significantly different from the module in opencv, is there a reason behind this?
```
##### Guanta Alecho on 2013-09-18 14:02

```
Prasan Samtani wrote:
> I can take a look at this if nobody else is doing so.

Cool, this would be great! I'd appreciate an updated version!

> 
> It appears that the flann repo on github is significantly different from the module in opencv, is there a reason behind this?

Afaik it's just very outdated.
```
##### Prasan Samtani on 2013-09-19 14:44

```
Alright, I'll try and do so this weekend.
```
##### Alexander Smorkalov on 2013-11-27 10:51

```
@Roman Donchenko, please have a look. I believe, that this fix has been already cherry-picked to OpenCV.
-   Affected version changed from branch 'master' (2.9) to 2.4.0 - 2.4.6
```
##### Alexander Smorkalov on 2013-11-28 05:02

```
-   Target version changed from 2.4.7 to 2.4.8
```
##### Roman Donchenko on 2013-11-29 08:07

```
No, that one wasn't.

Honestly, our copy of FLANN is pretty much unmaintained; there are even plans to ditch it by 3.0. If you (well, anyone reading this) want to cherry-pick some critical fixes, send us a pull request and we could merge it, but a wholesale update is unlikely to happen.
-   Priority changed from Normal to Low
```
##### Alexander Smorkalov on 2013-11-29 10:58

```
-   Target version changed from 2.4.8 to Next Hackathon
```
##### Maksim Shabunin on 2015-07-21 09:08

```
-   Affected version changed from 2.4.0 - 2.4.6 to branch 'master'
    (3.0-dev)
```
##### Maksim Shabunin on 2015-07-21 09:08

```
-   Tracker changed from Patch to Feature
```
Repository: opencv
Issue: cv2.EM.getMeans() does not work
Labels: bug,auto-transferred,priority: normal,category: python bindings,affected: 2.4

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

```
|| Devendra Goyal on 2013-09-10 19:38
|| Priority: Normal
|| Affected: 2.4.0 - 2.4.5
|| Category: python bindings
|| Tracker: Bug
|| Difficulty: 
|| PR: 
|| Platform: x86 / Mac OSX
```
## cv2.EM.getMeans() does not work

```
trying to access the means after applying EM on a GMM:
using code detailed here: http://docs.opencv.org/2.3/modules/ml/doc/expectation_maximization.html
but I get this error...I am using opencv 2.4.5
<pre>
AttributeError: 'cv2.EM' object has no attribute 'getMeans'
</pre>
How do I access the means and covariances using Python?!
```
## History
##### Alexander Smorkalov on 2013-09-11 06:02

```
Hello

You use documentation from older OpenCV version then you use. The docs for 2.4.5 is here: http://docs.opencv.org/2.4.5/modules/ml/doc/expectation_maximization.html#cvem-getmeans. it looks like wrapper for this class was removed after code refactoring. 
Vadim, please comment the issue.
-   Priority changed from Blocker to Normal
-   Assignee set to Vadim Pisarevsky
-   Category set to python bindings
```
##### Anna Kogan on 2013-10-03 07:56

```
-   Description changed from trying to access the means after applying
    EM on a GMM: using code detailed he... to trying to access the means
    after applying EM on a GMM: using code detailed he... More
-   Status changed from New to Open
```
Repository: opencv
Issue: OpenCV with_Openexr build errors
Labels: bug,auto-transferred,priority: normal,affected: 2.4,category: imgcodecs

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

```
|| git gat on 2013-09-11 08:34
|| Priority: Normal
|| Affected: 2.4.6 (latest release)
|| Category: highgui-images
|| Tracker: Bug
|| Difficulty: 
|| PR: 
|| Platform: x64 / Windows
```
## OpenCV with_Openexr build errors

```
Hi,

I get many build errors when compiling the latest OpenCV with openexr. 
when I don't use with_openexr all is good!
Here is the error: 
<pre>
Error   156  error: "restrict" has already been declared in the current scope   \3rdparty\openexr\Imath\ImathMatrix.h   2530
Error   158  error: "restrict" has already been declared in the current scope   \3rdparty\openexr\Imath\ImathMatrix.h   2531
Error   155  error: expected a ";"  \3rdparty\openexr\Imath\ImathMatrix.h   2529
Error   157  error: expected a ";"  \3rdparty\openexr\Imath\ImathMatrix.h   2530
Error   159  error: expected a ";"  \3rdparty\openexr\Imath\ImathMatrix.h   2531
Error   160  error: identifier "ap" is undefined    \3rdparty\openexr\Imath\ImathMatrix.h   2535
Error   162  error: identifier "bp" is undefined    \3rdparty\openexr\Imath\ImathMatrix.h   2540
Error   161  error: identifier "cp" is undefined    \3rdparty\openexr\Imath\ImathMatrix.h   2540
</pre>

I use Windows 7, VS 2008.
```
## History
##### Alexander Smorkalov on 2013-09-11 10:22

```
Hello git gat,

Could you provide some code sample to reproduce build issue?
-   Assignee set to Alexander Smorkalov
-   Category set to highgui-images
```
##### Alexander Smorkalov on 2013-09-12 10:52

```
-   Target version set to Next Hackathon
```
##### Anna Kogan on 2013-10-03 07:58

```
-   Affected version changed from branch '2.4' to 2.4.6 (latest release)
-   Description changed from Hi, I get many build errors when compiling
    the latest OpenCV with openexr.... to Hi, I get many build errors
    when compiling the latest OpenCV with openexr.... More
-   Status changed from New to Open
```
##### Alexander Smorkalov on 2013-10-31 08:46

```
I cannot reproduce build issue with Visual Studio 2008 and Visual Studio 2012. If you look at 3rdparty/openexr/Imath/ImathPlatform.h IMATH_RESTRICT macro is defined empty for MSVC. It means that you use some other compiler like Intel C++ compiler or you have some other version of OpenEXR lib in include path and compiler uses mix of headers from different locations. Unfortunately, I do not have ICC and cannot check compilation with it. I close the ticket.
-   Status changed from Open to Cancelled
```
##### Tim Zuercher on 2014-07-27 11:05

```
I was experiencing this same issue using the ICC compiler. Reassigning the IMATH_RESTRICT macro from "restrict" to empty fixes the issue.

There are also a overwhelming number of warnings for  signed/unsigned integer comparisons.
-   Status changed from Cancelled to Incomplete
```
Repository: opencv
Issue: MSER detecting non-extremal regions
Labels: bug,auto-transferred,priority: normal,affected: 2.4,category: features2d

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

```
|| Petra Bosilj on 2013-09-19 10:02
|| Priority: Normal
|| Affected: pre 2.4 (deprecated)
|| Category: features2d
|| Tracker: Bug
|| Difficulty: Hard
|| PR: 
|| Platform: Any / Any
```
## MSER detecting non-extremal regions

```
I found that the MSER detector in v.2.3.1 is giving some regions which are not extremal -- there are border pixels of same intensity as some of the pixels inside the regions. I checked the code for the current version and it did not seem to be changed at all, and I did not find any bug report about this so I think the issue is still present.

I gave a detailed explanation, with parameters and the image I used, and some debug output here: http://answers.opencv.org/question/20926/mser-detection-error-detected-region-not-extremal/
```
## History
##### Anna Kogan on 2013-10-03 08:14

```
Hello Petra,

Thank you for reporting the issue. Did you try using new versions of the library? Is the bug reproduced there?
If you could figure out how to solve the problem, a "contribution":http://www.code.opencv.org/projects/opencv/wiki/How_to_contribute would be very appreciated!
-   Status changed from New to Open
```
##### Petra Bosilj on 2013-10-08 14:48

```
Hello,

sorry, did not try with the new version. But what I did was browse through the code in the new version, and code for MSER implementation does not seem to have any changes when compared to the old version.

I'm glad to report the bug and details about it, but unfortunately (and especially since all OpenCV code is optimized for speed and so hard to read), I do not think that I'll have time to try and understand and debug the code.
```
Repository: opencv
Issue: projectPoints and 3d points behind camera.
Labels: auto-transferred,priority: normal,feature,category: calib3d

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

```
|| Rafael Saracchini on 2013-09-23 11:42
|| Priority: Normal
|| Affected: None
|| Category: calibration, 3d
|| Tracker: Feature
|| Difficulty: 
|| PR: 
|| Platform: None / None
```
## projectPoints and 3d points behind camera.

```
When making some tests with the procedure "projectPoints", I noticed that it does not make distinction whether a point is behind the camera or not. This feature is very useful, for example, to draw a small 3D cloud onto the scene or to verify the extrinsic camera matrix of a calibration procedure is really valid. I believe that it could be done accepting a 4XN input and returning a 3XN output (that is, accept homogeneous coordinates as input and output) so that it does not break compatibility the original function calls.

All the best.

Rafael Saracchini
```
## History
##### Vladislav Vinogradov on 2013-09-24 08:06

```
Hello Rafael Saracchini!

Thank you for your proposal! 
Unfortunately we have a limited human resources and we would be very appreciated if you have time to implement this feature by yourself and provide a patch to community.
Please see http://www.code.opencv.org/projects/opencv/wiki/How_to_contribute for details.
-   Assignee set to Rafael Saracchini
```
##### Vladislav Vinogradov on 2013-09-26 08:44

```
-   Category set to calibration, 3d
```
##### Anna Kogan on 2013-10-03 08:59

```
-   Status changed from New to Open
```