sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: opencv
Issue: FIX_INTRINSICS for a single camera in StereoCalibrate
Labels: auto-transferred,priority: normal,feature,category: calib3d

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

```
|| Patrick Beeson on 2010-04-07 20:34
|| Priority: Normal
|| Affected: None
|| Category: calibration, 3d
|| Tracker: Feature
|| Difficulty: None
|| PR: None
|| Platform: None / None
```
## FIX_INTRINSICS for a single camera in StereoCalibrate

```
I wanted to write a ROS node that will find edges or other common features in a scene (I'm using the checkerboard) to allow 3D range devices like 3D lidars or stereo cameras, to be registered with a color camera in order to produce colored blobs.  I have done this manually in the past, but I want an automated solution.

The problem is that in order to do this correctly, you need to be able to freeze the internal parameters of one camera, while letting the others drift.  This is because some devices have hardcoded internal parameters that they use in making the pointclouds.  These are often quite different from what comes out of StereoCalibrate.  So, I'd like to fix these intrinsic parameters, but let the intrinsic parameters of the second camera be optimized to "absorb" any error that exists from the first camera's intrinsic parameters.

(Hopefully that made sense).

One can do this with the MATLAB stereo_calib toolbox, and it works great for registering a color camera with a SwissRanger lidar (the extrinsic parameters and the 2D color camera intrinsic parameters are optimized while the SwissRanger intrinsic parameters remain fixed).

Unfortunately, there is no way to do this in OpenCV due to the rigidness of StereoCalibrate.
```
## History
##### Alexander Shishkov on 2012-02-12 21:43

```
-   Description changed from I wanted to write a ROS node that will find
    edges or other common features in... to I wanted to write a ROS node
    that will find edges or other common features in... More
```
##### Andrey Kamaev on 2012-04-04 20:23

```
-   Category changed from imgproc, video to calibration, 3d
```
Repository: opencv
Issue: Shape Descriptors for Maximally Stable Extremal Regions
Labels: auto-transferred,priority: normal,feature,category: imgproc,category: video

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

```
|| René Meusel on 2010-05-11 10:01
|| Priority: Normal
|| Affected: None
|| Category: imgproc, video
|| Tracker: Feature
|| Difficulty: None
|| PR: None
|| Platform: None / None
```
## Shape Descriptors for Maximally Stable Extremal Regions

```
Existing feature descriptors like SURF or SIFT that are already available in OpenCV don't work for all scenarios because they mainly operate on textures and their surroundings. MSER which works on shapes is already available in OpenCV, however, comparing those features is done with SURF or SIFT which operate on the textureing in the center of the shape as well.

The paper by Forssén and Lowe (http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.72.3296&rep=rep1&type=pdf) proposes a solution that might work more reliably for comparing shape descriptors.
```
## History
##### Alexander Shishkov on 2012-02-12 21:39

```
-   Description changed from Existing feature descriptors like SURF or
    SIFT that are already available in ... to Existing feature
    descriptors like SURF or SIFT that are already available in ... More
```
Repository: opencv
Issue: serialization
Labels: auto-transferred,feature,category: python bindings,priority: low

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

```
|| James Bowman on 2010-06-11 00:47
|| Priority: High
|| Affected: None
|| Category: python bindings
|| Tracker: Feature
|| Difficulty: Medium
|| PR: 
|| Platform: None / None
```
## serialization

```
It would be very nice if Python OpenCV objects were pickleable.

To do this, can the load/store methods of cpp objects accept strings?
```
## History
##### Alexander Shishkov on 2012-02-12 21:33

```
-   Description changed from It would be very nice if Python [[OpenCV]]
    objects were pickleable. To do th... to It would be very nice if
    Python OpenCV objects were pickleable. To do this, ... More
```
##### Andrey Kamaev on 2012-04-05 08:49

```
-   Category changed from imgproc, video to python bindings
```
##### Vadim Pisarevsky on 2012-05-29 16:00

```
-   Target version set to 3.0
```
##### Stefan R on 2012-11-28 10:22

```
+1
```
##### Maksim Shabunin on 2015-04-28 13:50

```
-   Difficulty set to Medium
-   Target version changed from 3.0 to 3.1
```
Repository: opencv
Issue: Mat Type Coherence: always returning CV_64FC1 Mat
Labels: auto-transferred,feature,category: imgproc,category: video,priority: low

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

```
|| Vito Macchia on 2010-07-09 12:48
|| Priority: Low
|| Affected: None
|| Category: imgproc, video
|| Tracker: Feature
|| Difficulty: None
|| PR: None
|| Platform: None / None
```
## Mat Type Coherence: always returning CV_64FC1 Mat

```
When porting my code from C to C++, I noticed that some C++ functions like:

cv::findHomography() or  cv::getAffineTransform() 

always return a CV_64FC1 cv::Mat, even when passing float (CV_32FCx) data.

Furthermore the cv::findHomography() and cv:convertPointsHomogeneous() only take CV_32 data (Mats).

So when writing code one has to take always care of the type and perform conversions such as:

        H=findHomography(ptsA,ptsB,CV_RANSAC,0.05); //returns a CV_64FC1!!!
        H.convertTo(H,CV_32FC1,1,0);

In order to perform other algebraic operations without getting a type mismatch error.

This did not happen with corresponding C functions, that where much more flexible (you could pass both double and float CvMat) and coherent (32->32 and 64->64).

I would like to do all my computations with double precision numbers (CV_64) but I cannot because some of these functions do not manage double, but only float data (so why do they return double in many cases??).

Could you please make this function type independent, or at least overload them in a way that also CV_64 data may be taken as input and the type returned is coherent with the input type? Also having back the same flexibility of cvConvertPointHomogeneous would not be bad.

Thanks

Vito

Ubuntu Linux 9.10, OpenCV 2.1, g++ 4.4.1
```
## History
##### Alexander Shishkov on 2012-02-12 21:31

```
-   Description changed from When porting my code from C to C++, I
    noticed that some C++ functions like: ... to When porting my code
    from C to C++, I noticed that some C++ functions like: ... More
```
##### Vadim Pisarevsky on 2012-04-24 14:32

```
let's lower priority of the task and postpone it till the next release
-   Target version set to 3.0
-   Priority changed from High to Low
-   Assignee set to Vadim Pisarevsky
```
Repository: opencv
Issue: Cocoa highgui implementation resets exit status
Labels: bug,auto-transferred,priority: low,category: highgui-gui

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

```
|| Michael Koval on 2010-11-07 01:29
|| Priority: Low
|| Affected: None
|| Category: highgui-gui
|| Tracker: Bug
|| Difficulty: None
|| PR: None
|| Platform: None / None
```
## Cocoa highgui implementation resets exit status

```
If a highgui window is active at the time of the program's exit the return value of main() or parameter of exit() is ignored and treated as zero. As a minimal example, compile and execute the following program:

// Begin Example
#include <opencv/cv.h>
#include <opencv/highgui.h>

int main(int argc, char **argv) {
        cv::Mat img = cv::imread(argvr1, 1);
        cv::imshow("Image", img);
        cv::waitKey(0);
        return 1;
}
// End Example

Despite returning "1" from main(), Bash reports (i.e. echo $?) the return code as "0". I have confirmed this in OpenCV 2.0 using the Cocoa implementation of highgui, but have not checked other configurations.
```
## History
##### Alexander Shishkov on 2012-02-12 21:24

```
-   Description changed from If a highgui window is active at the time
    of the program's exit the return va... to If a highgui window is
    active at the time of the program's exit the return va... More
```
##### Alexander Shishkov on 2012-03-21 22:03

```
-   Target version deleted ()
```
##### Alexander Shishkov on 2012-03-25 20:38

```
-   Priority changed from Normal to Low
```
##### Alexander Shishkov on 2012-04-05 12:48

```
-   Target version deleted ()
```
##### Andrey Kamaev on 2012-08-16 15:11

```
-   Category changed from highgui-images to highgui-gui
```
Repository: opencv
Issue: Maybe there is a logical bug in function icvCalcOpticalFlowLK_8u32fR
Labels: auto-transferred,feature,category: imgproc,category: video,priority: low

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

```
|| BAI YUN on 2010-12-31 03:26
|| Priority: Low
|| Affected: None
|| Category: imgproc, video
|| Tracker: Feature
|| Difficulty: None
|| PR: None
|| Platform: None / None
```
## Maybe there is a logical bug in function icvCalcOpticalFlowLK_8u32fR

```
I had read the code of function @icvCalcOpticalFlowLK_8u32fR@, find that, it is not perfect even contain some mistakes:

# The caculation of gaussian convolution is done not really in the define window;
# Alloc and free mem frequently;
# A mistake in the fellow code segment:

<pre><code class="cpp">
for( j = 0; j < imageWidth; j++ )
{
    int addr = address;

    A1B2 = 0;
    A2 = 0;
    B1 = 0;
    C1 = 0;
    C2 = 0;

    for( i = -USpace; i <= BSpace; i++ )
    {
        //! Maybe "addr + j" should be changed to "addr + j + i * imgWidth"? whatever "addr + j" is not correct.
        A2 += WII[addr + j].xx * KerY[i];
        A1B2 += WII[addr + j].xy * KerY[i];
        B1 += WII[addr + j].yy * KerY[i];
        C2 += WII[addr + j].xt * KerY[i];
        C1 += WII[addr + j].yt * KerY[i];
        //!

        addr += BufferWidth;
        addr -= ((addr >= BufferSize) ? 0xffffffff : 0) & BufferSize;
    } 
}
</code></pre>
```
## History
##### Vadim Pisarevsky on 2012-04-24 15:20

```
Since non-dense variant of LK is now considered obsolete (moved to legacy module), I lower priority of the bug
-   Priority changed from High to Low
```
##### Andrey Kamaev on 2012-04-24 15:41

```
-   Description changed from I had read the code of function
    icvCalcOpticalFlowLK_8u32fR, find that, it is... to I had read the
    code of function @icvCalcOpticalFlowLK_8u32fR@, find that, it ...
    More
```
Repository: opencv
Issue: DCT for odd length
Labels: auto-transferred,priority: normal,feature,category: core

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

```
|| Leonid Bilevich on 2011-02-15 02:09
|| Priority: Normal
|| Affected: None
|| Category: core
|| Tracker: Feature
|| Difficulty: None
|| PR: None
|| Platform: None / None
```
## DCT for odd length

```
The DCT of the odd-length sequence is not implemented. The DCT of the even-length sequence is implemented by the method of Narasimha-Peterson r1.
There exists a very simple extension of r1 to the case of odd N (this extension is described in r2). I suggest to use this extension in order to realize DCT for odd N.

I realized the suggested code in Matlab.

References:
r1 M. J. Narasimha and A. M. Peterson, "On the computation of the discrete cosine transform," IEEE Trans. Commun., vol. 26, no. 6, pp. 934–936, June 1978.
r2 J. Makhoul, "A fast cosine transform in one and two dimensions," IEEE Trans. Acoust. Speech Signal Process., vol. 28, no. 1, 27-34, February 1980.
```
## History
##### Vadim Pisarevsky on 2011-02-16 11:41

```
Thanks for the reference. It will be put to OpenCV. However, because the current limitation is described in the reference manual, and for many real applications the array of an odd size can be padded with extra elements, I change the ticket type and priority.
```
##### Vadim Pisarevsky on 2012-04-24 15:21

```
lowering priority of the feature request
-   Priority changed from High to Normal
```
Repository: opencv
Issue: Add support for weighted datasets in clustering
Labels: auto-transferred,priority: normal,feature,category: core

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

```
|| Simon Pearson on 2011-02-27 19:53
|| Priority: Normal
|| Affected: None
|| Category: core
|| Tracker: Feature
|| Difficulty: None
|| PR: None
|| Platform: None / None
```
## Add support for weighted datasets in clustering

```
Many datasets include lots of repeated points. Such datasets can be represented more compactly by removing duplicate points and storing the number of each point as a "weight".  It would be good if OpenCV clustering and partitioning algorithms supported such datasets.

Note: I will be attempting to rework the clustering code to support this as part of a project I'm working on and will submit it for inclusion if I am successful.
```
## History
##### Alexander Shishkov on 2012-02-12 21:15

```
-   Description changed from Many datasets include lots of repeated
    points. Such datasets can be represent... to Many datasets include
    lots of repeated points. Such datasets can be represent... More
```
Repository: opencv
Issue: Add API to enumerate cameras
Labels: auto-transferred,priority: normal,feature,category: videoio(camera),future

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

```
|| Rune Espeseth on 2011-03-08 10:27
|| Priority: Normal
|| Affected: None
|| Category: highgui-camera
|| Tracker: Feature
|| Difficulty: 
|| PR: 
|| Platform: None / None
```
## Add API to enumerate cameras

```
OpenCV should have an API to enumerate cameras. Without it, writing programs that support non-fixed hardware is not possible.

The point of this API is to retrieve information about the cameras attached to the system:
- NumberOf
- Name of each camera (can be used for user-selection in a GUI)
- Resolution of each camera
- other properties.

It will then be possible to write programs (f.i. surveillance software) that support 1 to any number of cameras instead of requiring a given number of cameras.
```
## History
##### Alexander Shishkov on 2012-02-12 21:12

```
-   Description changed from [[OpenCV]] should have an API to enumerate
    cameras. Without it, writing progr... to OpenCV should have an API
    to enumerate cameras. Without it, writing programs ... More
```
##### Alexander Reshetnikov on 2012-04-25 14:27

```
-   Priority changed from High to Normal
-   Assignee set to Vadim Pisarevsky
```
##### Andrey Kamaev on 2012-08-16 15:23

```
-   Category changed from highgui-images to highgui-camera
```
##### Neil Jansen on 2015-02-03 04:59

```
Hi, I know this issue has been open for a while, but is there any chance that it could be fixed easily?  It would be very helpful for those of us using machine vision with more than 1 camera.  I am even willing to place a cash bounty on this bug if necessary (tried to do it at bountysource.com, but they don't support the ChiliProject bug tracking platform that OpenCV uses...).  Thanks!
```
##### Steven Puttemans on 2015-02-03 09:29

```
Depending on which camera type you are using this already exists. The recently adapted PvAPI interface of Allied Vision Technology cameras does exactly this. No idea if other do it or not.
```
Repository: opencv
Issue: RANSAC parameters for estimateRigidTransform
Labels: auto-transferred,priority: normal,feature,category: imgproc,category: video

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

```
|| Do Bi on 2011-03-08 20:26
|| Priority: Normal
|| Affected: None
|| Category: imgproc, video
|| Tracker: Feature
|| Difficulty: None
|| PR: None
|| Platform: None / None
```
## RANSAC parameters for estimateRigidTransform

```
Hi,

I think, it would be cool, if RANSAC_MAX_ITERS, RANSAC_SIZE0 and RANSAC_GOOD_RATIO in cvEstimateRigidTransform were parameters and not hard coded, and if this flexibility would also be usable in cv::estimateRigidTransform.

Regards,
Dobias
```
## History
Repository: opencv
Issue: Statistical Shape Model
Labels: auto-transferred,priority: normal,feature,category: objdetect

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

```
|| Hamed Habibi Aghdam on 2011-03-27 13:17
|| Priority: Normal
|| Affected: None
|| Category: objdetect
|| Tracker: Feature
|| Difficulty: None
|| PR: None
|| Platform: None / None
```
## Statistical Shape Model

```
Statistical Shape Model such as Active Shape Model (ASM) and Active Appearance Model (AAM) plays important role in shape analysis problems.  Specially, Active Appearance Model with Inverse Composition fitting method shows promising results in many applications. From my point of view, openCV team can add these features in the future releases. Following are two ASM/AAM libraries based on openCV.(They need some improvements)

http://www.google.com/url?sa=t&source=web&cd=2&ved=0CCEQFjAB&url=http%3A%2F%2Fcode.google.com%2Fp%2Faam-library%2F&ei=YTaPTdDPA8udOs-t6aAC&usg=AFQjCNGBABkiGClVjsHhE8CjomLKl2Lxeg

http://www.google.com/url?sa=t&source=web&cd=1&ved=0CBsQFjAA&url=http%3A%2F%2Fcode.google.com%2Fp%2Faam-opencv%2F&ei=YTaPTdDPA8udOs-t6aAC&usg=AFQjCNHBbqQloYPg8fYR0yrzyCFCZCkEzw
```
## History
Repository: opencv
Issue: SURF Buffer Reuse
Labels: auto-transferred,priority: normal,feature,category: nonfree

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

```
|| Nick Kitten on 2011-04-20 14:35
|| Priority: Normal
|| Affected: None
|| Category: nonfree
|| Tracker: Feature
|| Difficulty: None
|| PR: None
|| Platform: None / None
```
## SURF Buffer Reuse

```
The CPU SURF implementation could really use an option to recycle buffers / filters between consecutive calls, at least when input images all have the same type and size (a very common case).  The GPU implementation already includes this optimization, and allowing constant reallocation of memory limits the usefulness of this version for real-time applications.
```
## History
##### Andrey Kamaev on 2012-08-21 15:05

```
-   Category changed from features2d to nonfree
```
Repository: opencv
Issue: Usage of DescriptorExtractor for custom (=own) code: Design flaw?
Labels: auto-transferred,priority: normal,feature,category: features2d

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

```
|| Stefan R on 2011-06-08 11:32
|| Priority: Normal
|| Affected: None
|| Category: features2d
|| Tracker: Feature
|| Difficulty: None
|| PR: None
|| Platform: None / None
```
## Usage of DescriptorExtractor for custom (=own) code: Design flaw?

```
Hi all, Hi Vadim,

I use the cv::FeatureDetector and cv::DescriptorExtractor interfaces to wrap some of our own existing feature detection and descriptor functions in a uniform way. So I can test different features by plugging in different implementations like this:
<pre>
<code class="cpp">
cv::FeatureDetector* detector = ...some implementation or NULL if not required...
cv::DescriptorExtractor * extractor = ...some implementation or NULL if not required...

vector<KeyPoint> keypoints;
if( detector != NULL )
    detector->detect(frameSmallGray, keypoints, mask);

cv::Mat descriptors;
if( extractor != NULL )
   extractor->compute(frameSmallGray, keypoints, descriptors);
</code></pre>

Due to the internal structure of some in some cases the actual feature detection part can not be separated from the descriptor extraction part. In other words, such an implementation can only implement the DescriptorExtractor interface. However - and that's IMHO a potential design flaw - the DescriptorExtractor base class never calls the virtual computeImpl() function of the actual implementation when the given keypoint vector is empty:

<pre>
<code class="cpp">
void DescriptorExtractor::compute( const Mat& image, vector<KeyPoint>& keypoints, Mat& descriptors ) const
{    
    if( image.empty() || keypoints.empty() )
    {
        descriptors.release();
        return;
    }


    KeyPointsFilter::runByImageBorder( keypoints, image.size(), 0 );
    KeyPointsFilter::runByKeypointSize( keypoints, std::numeric_limits<float>::epsilon() );

    computeImpl( image, keypoints, descriptors );
}
</code></pre>

As a workaround one can do the following, but that's rather unelegant:
<pre>
<code class="cpp">
cv::Mat descriptors;
vector<KeyPoint> keypoints;
if( keypoints.size() == 0 )
    keypoints.push_back( [[KeyPoint]]() );

extractor->compute(frameSmallGray, keypoints, descriptors);
</code></pre>

I am not sure, maybe I am abusing these interfaces. If there is any particular better way to use these, please tell me.

Thanks,
Stefan
```
## History
##### Alexander Shishkov on 2012-02-12 21:03

```
-   Description changed from Hi all, Hi Vadim, I use the
    cv::FeatureDetector and cv::DescriptorExtractor ... to Hi all, Hi
    Vadim, I use the cv::FeatureDetector and cv::DescriptorExtractor ...
    More
```
##### Alexander Shishkov on 2012-02-12 21:03

```
-   Description changed from Hi all, Hi Vadim, I use the
    cv::FeatureDetector and cv::DescriptorExtractor ... to Hi all, Hi
    Vadim, I use the cv::FeatureDetector and cv::DescriptorExtractor ...
    More
```
##### Alexander Shishkov on 2012-03-21 20:47

```
-   Tracker changed from Bug to Feature
```
Repository: opencv
Issue: A method to discover what keypoints are removed when descriptors are computed.
Labels: auto-transferred,feature,priority: low,category: features2d

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

```
|| Hordur Johannsson on 2011-06-18 13:44
|| Priority: Normal
|| Affected: None
|| Category: features2d
|| Tracker: Feature
|| Difficulty: None
|| PR: None
|| Platform: None / None
```
## A method to discover what keypoints are removed when descriptors are computed.

```
When calling DescriptorExtractor::compute it will remove the keypoints for which a descriptor cannot be computed. This can
be inconvenient if you need to associate the Descriptors to some
auxillary structure.

For example, if you have detected keypoints and computed disparity of the points at some later stage. If the keypoints are removed then the original structure needs to be searched to find the disparity. 

If ordering is preserved then the search might not be too hard to do. 

Possible solutions would be:

* Template the Keypoint allowing for custom keypoints, e.g. storing all extra information or a reference to the original structure.

* Have the remove optional and instead return a vector of bools specifying which descriptors are valid. Or a list of the id's to original vector.
```
## History
##### Alexander Shishkov on 2012-02-12 21:01

```
-   Description changed from When calling
    [[DescriptorExtractor]]::compute it will remove the keypoints fo...
    to When calling DescriptorExtractor::compute it will remove the
    keypoints for wh... More
```