sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: opencv
Issue: cvFindExtrinsicCameraParams2 produces inaccurate results when given 2D objectPoints
Labels: bug,auto-transferred,priority: normal,category: calib3d

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

```
|| dima kogan on 2012-07-04 18:47
|| Priority: Normal
|| Affected: None
|| Category: calibration, 3d
|| Tracker: Bug
|| Difficulty: None
|| PR: None
|| Platform: None / None
```
## cvFindExtrinsicCameraParams2 produces inaccurate results when given 2D objectPoints

```
If I call cvFindExtrinsicCameraParams2() and pass it 2D objectPoints, I
expect the routine to assume a planar object with z==0. Instead, z = 1 is
used; this is done with this line in the implementation of
cvFindExtrinsicCameraParams2():

  cvConvertPointsHomogeneous( objectPoints, matM );

It makes no sense to convert the objectPoints matrix to homogeneous
coordinates, as this data lives in a completely different coordinate
system from the camera observing the object.

Looking a bit closer, it appears that the documentation of this function
claims to support ONLY 3D data for this matrix. Thus maybe the fix is to
simply enforce 3D input, which would make this issue moot. This would
handle bug #1875 as well.

Thanks
```
## History
##### Andrey Kamaev on 2012-07-09 11:43

```
-   Category set to calibration, 3d
```
Repository: opencv
Issue: Saving and Loading the index starting with a DescriptorMatcher object
Labels: bug,auto-transferred,priority: normal,category: flann

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

```
|| Craig Shaffer on 2012-07-11 20:22
|| Priority: Normal
|| Affected: None
|| Category: flann
|| Tracker: Bug
|| Difficulty: None
|| PR: None
|| Platform: None / None
```
## Saving and Loading the index starting with a DescriptorMatcher object

```
Using the code in "matching_to_many_images.cpp"

descriptorMatcher = DescriptorMatcher::create( matcherType );
//Build the index
descriptorMatcher->add( trainDescriptors );
descriptorMatcher->train();

//Now I want to save the index.  Unless I am missing something it cannot be done with this approach.
descriptorMatcher->write(descriptorSettings) would be the obvious choice but it doesn't actually store the index.  

Since there is no way to access the flannIndex object (it is protected with no "get" function) I'm stuck.

I believe this is causing about 90% of the confusion posted on various sites under the phrase "opencv flann save index"

I hope you can suggest a change / work around that keeps descriptormatcher as that's a really nice interface.

Also why does "void FlannBasedMatcher::read" 
release the index? flannIndex.release() this seems odd.

/Craig
```
## History
##### Maria Dimashova on 2012-07-12 07:20

```
-   Priority changed from Blocker to Normal
```
##### Maria Dimashova on 2012-07-12 13:06

```
-   Assignee changed from Marius Muja to Maria Dimashova
```
Repository: opencv
Issue: possible problems of orb and freak
Labels: bug,auto-transferred,priority: normal,category: features2d

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

```
|| Maria Dimashova on 2012-07-16 18:27
|| Priority: Normal
|| Affected: None
|| Category: features2d
|| Tracker: Bug
|| Difficulty: None
|| PR: None
|| Platform: None / None
```
## possible problems of orb and freak

```
Please, look at the commented tests in features2d/test/test_rotation_and_scale_invariance.cpp.
ORB shows low scale invariance (especially descriptor), FREAK shows low rotation and scale invariance (maybe I use it wrong).
We have to check that there are no bugs in the algorithms.
```
## History
##### Vadim Pisarevsky on 2012-10-05 10:05

```
-   Target version deleted ()
-   Assignee deleted (Vadim Pisarevsky)
```
##### Kirill Kornyakov on 2012-10-24 08:38

```
-   Target version set to Next Hackathon
```
Repository: opencv
Issue: REQUEST: stereosgbm -> change cost array type from short to unsigned short
Labels: auto-transferred,feature,priority: low,category: calib3d

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

```
|| Stefan Hahn on 2012-07-18 05:16
|| Priority: Low
|| Affected: None
|| Category: calibration, 3d
|| Tracker: Feature
|| Difficulty: None
|| PR: None
|| Platform: None / None
```
## REQUEST: stereosgbm -> change cost array type from short to unsigned short

```
typedef unsigned short CostType;
On Line 59 in current source would give some more leeway for the accumulator array before clipping.
Tested only with own code.
```
## History
##### Marina Kolpakova on 2012-07-24 17:16

```
-   Category set to calibration, 3d
```
Repository: opencv
Issue: Add norm type to FlannBasedMatcher constructor
Labels: bug,auto-transferred,priority: normal,category: features2d

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

```
|| Maria Dimashova on 2012-07-24 12:57
|| Priority: Normal
|| Affected: None
|| Category: features2d
|| Tracker: Bug
|| Difficulty: None
|| PR: None
|| Platform: None / None
```
## Add norm type to FlannBasedMatcher constructor

```
Add a norm type support to the FlannBasedMatcher. This was not done yet for historical reasons.
```
## History
Repository: opencv
Issue: Incorrect window size and drawing functions for small windows.
Labels: bug,auto-transferred,priority: normal,category: highgui-gui

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

```
|| Chris Miller on 2012-07-25 18:50
|| Priority: Normal
|| Affected: None
|| Category: highgui-gui
|| Tracker: Bug
|| Difficulty: None
|| PR: None
|| Platform: None / None
```
## Incorrect window size and drawing functions for small windows.

```
Building in Windows x64 VS2010.  Issue is possibly related to 

http://code.opencv.org/issues/2189

but also affects the perceived cursor position.  

<pre><code class="cpp">
void drawCircle( int event, int x, int y, int ignoreMe, void* mat_)
{
    if(event == CV_EVENT_LBUTTONDOWN){
        Mat img = *((Mat*) mat_);
        circle(img, Point(x,y), 3, Scalar(255,255,255), -1);
        imshow("Window Test", img);
    }
}

int main( int argc, const char** argv )
{
    Mat smallImg = Mat::zeros(90,90,CV_32F);
    imshow("Window Test", smallImg);
    setMouseCallback("Window Test",drawCircle,&smallImg);

        while (cvWaitKey(4) == -1) {}

    return 0;
}
</code></pre>

As in the OSX bug, this produces a window that is too wide for the image.  If you try and draw circles at the cursor position they are placed incorrectly and the error increases as you move to the right.

My screenshooter doesn't capture the cursor but in the attached image I attempted to create 3 circles by clicking on the extreme left, the middle, and the extreme right of the black image.

!bug.png!
```
## History
##### Daniil Osokin on 2012-08-01 06:20

```
Which version of OpenCV do you use?
-   Assignee changed from Vadim Pisarevsky to Chris Miller
```
##### Daniil Osokin on 2012-08-06 06:39

```
-   Assignee deleted (Chris Miller)
```
##### Andrey Kamaev on 2012-08-15 12:13

```
-   Description changed from Building in Windows x64 VS2010. Issue is
    possibly related to http://code.o... to Building in Windows x64
    VS2010. Issue is possibly related to http://code.o... More
```
##### Andrey Kamaev on 2012-08-16 15:41

```
-   Category changed from highgui-images to highgui-gui
```
Repository: opencv
Issue: More operations of CCS-packed DFT spectra is advisable
Labels: auto-transferred,feature,priority: low,category: core

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

```
|| Alexander Mordvintsev on 2012-08-01 08:45
|| Priority: Low
|| Affected: None
|| Category: core
|| Tracker: Feature
|| Difficulty: None
|| PR: None
|| Platform: None / None
```
## More operations of CCS-packed DFT spectra is advisable

```
Currently we have @mulSpectrums@, which can also take a conjugation of its second argument. Functions for spectrum division and conjugation might be useful for implementing some algorithms. "MOSSE tracker":http://www.cs.colostate.edu/~bolme/publications/Bolme2010Tracking.pdf is an example.
```
## History
##### Will Lucas on 2012-08-11 03:57

```
I created two such methods (division and magnitude) for doing phase correlation a while back. However, as of right now the functions are statically scoped in @phasecorr.cpp@ available "here":http://code.opencv.org/projects/opencv/repository/revisions/master/entry/modules/imgproc/src/phasecorr.cpp.

It may be possible to make these stand alone for more general purpose use.

-Will
```
Repository: opencv
Issue: Feature request: max()
Labels: auto-transferred,feature,priority: low,category: core

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

```
|| Hilton Bristow on 2012-08-03 23:23
|| Priority: Low
|| Affected: None
|| Category: core
|| Tracker: Feature
|| Difficulty: None
|| PR: None
|| Platform: None / None
```
## Feature request: max()

```
Hello,
I would like to request a new variant of the max() or reduce() feature with the following syntax:
void max(InputArray src, OutputArray vdst, const int dim=-1, OutputArray idst=noArray())

where:
src  = the source matrix of dimensionality N
vdst = the destination matrix of dimensionality (N-1)
dim  = the dimension over which to perform the max reduction (d < N) (optional)
idst = the index within dimension d which contained the maximum value

I find this operation useful on many occasions and it reflects the Matlab functionality

H
```
## History
Repository: opencv
Issue: P algorithm implementation
Labels: auto-transferred,feature,category: imgproc,category: video,priority: low

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

```
|| Damien DEOM on 2012-08-04 11:51
|| Priority: Low
|| Affected: None
|| Category: imgproc, video
|| Tracker: Feature
|| Difficulty: None
|| PR: None
|| Platform: None / None
```
## P algorithm implementation

```
It would be very nice to have the P algorithm implemented, wich is a huge amelioration of the watershed algotithm

Se documentation here:
http://cmm.ensmp.fr/~beucher/publi/P-Algorithm_SB_BM.pdf

Regards
```
## History
##### Damien DEOM on 2012-08-04 12:10

```
another useful link:

http://cmm.ensmp.fr/~beucher/wtshed.html
```
##### Andrey Kamaev on 2012-08-15 13:01

```
-   Category set to imgproc, video
```
##### Vadim Pisarevsky on 2012-10-03 13:17

```
-   Priority changed from Normal to Low
```
Repository: opencv
Issue: Add inter-camera synchronization
Labels: auto-transferred,priority: normal,feature,category: videoio(camera)

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

```
|| Pavel Gurevich on 2012-08-15 16:10
|| Priority: Normal
|| Affected: None
|| Category: highgui-camera
|| Tracker: Feature
|| Difficulty: None
|| PR: None
|| Platform: None / None
```
## Add inter-camera synchronization

```
When dealing with stereo vision, inter-camera synchronization is of uttermost importance when objects in the frame move. Currently, OpenCV neglects the ability to synchronize even if underlying system (DirectShow or video4linux) supports it.

Please, add ability to synchronize capturing devices.

Thanks!
```
## History
##### Andrey Kamaev on 2012-08-15 18:45

```
-   Category set to highgui-images
```
##### Andrey Kamaev on 2012-08-16 15:43

```
-   Category changed from highgui-images to highgui-camera
```
##### Vadim Pisarevsky on 2012-09-24 11:21

```
a patch to do it would be very welcome.
```
Repository: opencv
Issue: Automatic documentation of code samples
Labels: auto-transferred,feature,priority: low,category: documentation

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

```
|| Gary Bradski on 2012-08-22 00:04
|| Priority: Low
|| Affected: None
|| Category: documentation
|| Tracker: Feature
|| Difficulty: 
|| PR: 
|| Platform: None / None
```
## Automatic documentation of code samples

```
We now have an increasing number of code samples under .../samples in C, C++ and Python

We need to 
# come up with a standard information header or "help" out put that can be put into each past sample and all future samples that tells
> * what that sample does
> * how to call that sample
# write a python script that can extract the headers and turn it into a documentation page that users can search through to find out what is in each samples directory
```
## History
##### Andrey Kamaev on 2012-10-31 14:08

```
-   Target version changed from 2.4.3 to 3.0
```
##### Maksim Shabunin on 2015-04-27 15:09

```
-   Target version changed from 3.0 to 3.1
-   Priority changed from Normal to Low
-   Assignee changed from Vadim Pisarevsky to Maksim Shabunin
```
Repository: opencv
Issue: operations on arrays: more cv::Mat return signatures
Labels: auto-transferred,priority: normal,feature,category: core

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

```
|| Hilton Bristow on 2012-08-25 22:06
|| Priority: Normal
|| Affected: None
|| Category: core
|| Tracker: Feature
|| Difficulty: None
|| PR: None
|| Platform: None / None
```
## operations on arrays: more cv::Mat return signatures

```
I would like to request more Mat/MatExpr return signatures for elementwise operations on arrays, including:

Mat exp(const Mat& src);
Mat pow(const Mat& src, float exp);
Mat sqrt(const Mat& src);
Mat square(const Mat& src);
Mat log(const Mat& src);

That will make for more readable code when doing the following type of operations:
L = I - exp( diag(D) * log(W) );

Obviously this will trigger a lot of unnecessary memory allocations, so non-const (in-place) versions or versions that return MatExpr would be appreciated as well/instead.
```
## History
##### Stefan R on 2012-10-25 15:07

```
I can contribute the following:
<pre>
cv::Mat mul(const cv::Mat& a, const cv::Mat& b)
{
    cv::Mat tmp;
    cv::multiply(a, b, tmp);
    return tmp;
}

cv::Mat pow(const cv::Mat& src, double power)
{
    cv::Mat tmp;
    if( power == 2.0 ){
        cv::multiply(src, src, tmp);
    } else {
        cv::pow(src, power, tmp);
    }   
    return tmp;
}

cv::Mat sqrt(const cv::Mat& src)
{
    cv::Mat tmp;
    cv::sqrt(src, tmp);
    return tmp;
}
</pre>
```
##### Vadim Pisarevsky on 2012-10-26 18:49

```
let's postpone it; the proposed "naive" implementation is very inefficient. Need to think how to do it properly.
-   Target version changed from 2.4.3 to 3.0
```
##### Leszek Swirski on 2013-03-29 11:55

```
Could it be an idea to embrace Eigen for such things? These are exactly the sorts of things that Eigen is good at doing efficiently.
```
Repository: opencv
Issue: dense spectral clustering
Labels: auto-transferred,priority: normal,feature,category: core

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

```
|| Hilton Bristow on 2012-08-26 05:44
|| Priority: Normal
|| Affected: None
|| Category: core
|| Tracker: Feature
|| Difficulty: 
|| PR: 
|| Platform: None / None
```
## dense spectral clustering

```
I would like to submit a function for spectral clustering. The function uses dense matrices and dense eigen-decomposition, so it is not suitable for very large clustering problems.

The method is based upon well known works of spectral clustering, and implements two graph laplacian normalization methods:
- Shi and Malik, "Normalized Cuts and Image Segmentation", PAMI 2000
- Ng, Jordan and Weiss, "On Spectral Clustering: Analysis and an Algorithm", NIPS 2002

All functionality is templated, so wrapping it in Input/Output Arrays should be trivial. Please let me know if you need anything further, such as unit tests, etc
```
## History
##### Alexandre Benoit on 2014-01-20 19:52

```
Hi,

i currently take a look at the proposed code.

At this point, it works and this is really interesting to make it available to the community since spectral clustering is a very efficient unsupervised clustering method.

However, the code needs some refactoring that would aim to :
_avoid to force end user to use cv::Mat_<T> objects. It would be easier to use the classical cv::Mat objects.
_enhance the proposed adjacency matrix computation. It currently relies on a the epsilon neighborhood graph. Other methods can be added : fully connected graph (with continuous similarity values) and knn neighbors graph.

I can work on it. However, i wonder where this code should be added ?
opencv_ml ? But the knn neighborhood graph method is very convenient to be used with the cv::DescriptorMatcher object that is in the feature2d module (we can choose the knn matching method, etc.).

Then, what should be done ?

Any recommendation ?
```
Repository: opencv
Issue: standardised Distance interface
Labels: auto-transferred,priority: normal,feature,category: core

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

```
|| Hilton Bristow on 2012-08-26 06:53
|| Priority: Normal
|| Affected: None
|| Category: core
|| Tracker: Feature
|| Difficulty: None
|| PR: None
|| Platform: None / None
```
## standardised Distance interface

```
I would like to propose a standardized interface for distance functions in OpenCV. I have outlined one such interface in the attached file. I have implemented a simple Euclidean distance function as an example, but if you like the interface I can implement Mahalanobis, Manhattan, Cosine, Correlation, etc.

Aspects of the interface that I deem important:
* standardized. If functions require a DistanceFunction functor, then we can pass any subclass and expect it to work.
* speed. Obvious.
* can maintain state. Say you want a euclidean distance that is only based upon the k-nearest neighbours and zero elsewhere. As long as the distance function is aware of the neighbourliness, this detail can remain transparent to the actual calling function.
* generalize to any dimensionality. Computer vision is no longer about just images. We should not restrict users to find the euclidean distance between 2D points.

For example, finding the pairwise distance between a set of datapoints (pdist() in matlab) is as simple as:
<pre>
int M, K; // M datapoints, K dimensions
Mat_<float> data(M, K);
Mat_<float> pairwise(M, M);
randn(data, 1, 1);
EuclideanDistance<float> distance(K);

for (int i = 0; i < M; ++i) {
    for (int j = 0; j < M; ++j) {
        pairwise(i,j) = distance(data[i], data[j]);
    }
}
</pre>

This would go a long way to producing more general algorithms such as K-dimensional kmeans(), or keypoint matching using complex distance metrics.
```
## History
##### Kirill Kornyakov on 2012-09-24 12:13

```
-   Category set to core
```
##### Alexander Smorkalov on 2012-10-03 08:42

```
-   Assignee set to Vadim Pisarevsky
```
Repository: opencv
Issue: implicitly casting away cv::Mat constness
Labels: auto-transferred,feature,priority: low,category: core

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

```
|| Evan Krause on 2012-08-27 16:53
|| Priority: Low
|| Affected: None
|| Category: core
|| Tracker: Feature
|| Difficulty: None
|| PR: 
|| Platform: None / None
```
## implicitly casting away cv::Mat constness

```
While porting some code from using the old IplImage to using cv::Mat, I noticed that it's all too easy to accidentally cast away the constness of cv::Mat. A simple example:

const cv::Mat mat_const(3,1,CV_32FC1,data); 
cv::Mat mat_non_const = mat_const;
//modifying mat_non_const also modifies mat_const !!!

It seems that this is a huge problem that opens the door to all kinds of bugs. Is there some alternative way for dealing with and ensuring constness (or at least making it hard and more explicit to cast it away)?
```
## History
##### Vadim Pisarevsky on 2012-09-19 13:05

```
I doubt we can solve it easily. It's not a bug, it's just the way how C++ works. I do not see a solution other than to introduce a separate const_Mat class, but this is big effort to make it properly.
Let's mark it as low-priority feature for 2.5. May be, in a few months from now we will see how to do it or maybe someone proposes a patch.
-   Target version set to 3.0
-   Priority changed from Normal to Low
-   Assignee set to Vadim Pisarevsky
-   Category set to core
-   Tracker changed from Bug to Feature
```
##### Adi Shavit on 2013-04-25 21:01

```
You could actually define the non-const assignment operator only for non-const cv::Mat, and a const assignment operator for const cv::Mat.
Then when attempting to copy from a const cv::Mat you'd get a compilation error if the target is non-const, at which point you could either define it as const or use clone().
```
Repository: opencv
Issue: Add new create() method for Feature2D
Labels: auto-transferred,priority: normal,feature,category: features2d

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

```
|| Maria Dimashova on 2012-09-05 09:58
|| Priority: Normal
|| Affected: None
|| Category: features2d
|| Tracker: Feature
|| Difficulty: None
|| PR: None
|| Platform: None / None
```
## Add new create() method for Feature2D

```
with arguments Ptr<FeatureDetector> and Ptr<DescriptorExtractor>.
```
## History
##### Alexander Shishkov on 2012-09-07 13:32

```
-   Target version deleted (3.0)
-   Assignee deleted (Maria Dimashova)
```
Repository: opencv
Issue: Support UnBayer color conversion for Single (float) Images
Labels: auto-transferred,feature,category: imgproc,category: video,priority: low

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

```
|| Gilad Kapelushnik on 2012-09-10 15:19
|| Priority: Low
|| Affected: None
|| Category: imgproc, video
|| Tracker: Feature
|| Difficulty: None
|| PR: None
|| Platform: None / None
```
## Support UnBayer color conversion for Single (float) Images

```
As of 2.4.2, Unbayer is only supported for 8bit and 16bit integers.
Please add support for Single (float) based images.
```
## History
##### Kirill Kornyakov on 2012-09-24 12:25

```
Could you please explain why do you need this functionality? It would be useful to have:
# Use case description
# Input/output data attached
# Code sample which is supposed to work after this feature is added

Unfortunately I personally don't understand why one may need this function, so please elaborate on your problem. And think about implementing it by yourself :)
-   Priority changed from Normal to Low
-   Assignee set to Gilad Kapelushnik
-   Category set to imgproc, video
```
##### Gilad Kapelushnik on 2012-09-25 17:21

```
I know that in most cases the first operation that is done is unbayer the data that is received from the camera.
In my case I apply two operations before unbayer.

The first is 'Dark Frame' correction - subtracting a dark frame from the image. Lets assume the data received from the camera is 12bit image coded in 16bit data. Subtracting the dark frame from the received image would produce an int16 image, no problem here.

The second is 'Flat field correction' - This is done to remove some unwanted artifacts caused by the lens (and sensor micro-lenses). Since there is a division operation here the output image is float. It is possible to have the flat filed correction produce int16 images but that is in the cost of chopping off some data and converting the data from float to int16 for the whole image. We can argue how much that 'copped' data affects quality but that is another story.

After these 2 procedures I do unbayer. It is better applying these procedures before unbayer as it is faster and the errors or unwanted artifacts aren't smoothed by the unbayer procedure.

I hope I was able to explain this properly.

If you think I would get better results doing things differently I would be happy to know.

Cheers,

Gilad.
```