Connecting to Point Grey chameleon camera (Bug #2102)

It is usually helpful to include a code snippet for the devs to reproduce the problem. However, that company provides its own "free" software framework for it's very expensive proprietary hardware.

You may wish to consider writing your own driver wrapper in the commercial framework, and link its interface into your opencv code with a conditional check for the camera hardware.

Good luck,
J

Yes, they provide their own SDK to work with the camera. However, our requirement is to use DirectShow interface only and not to include any other DLL/SDK with our application. And since PointGrey Chameleon camera supports DirectShow, it should work.

I don't think it is necessary to provide any code snipet to this problem, because it can be easily tested on any code using OpenCV. Just call cvCreateCameraCapture and it crashes immedietaly.

I've experienced this same problem with using the Point Grey DirectShow driver. Since the negative is a valid and meaningful value with uncompressed RGB bitmaps, I think it has to be supported.
This (admittedly trivial) code is below is sufficient to duplicate the error (console mode VC++ 2008, tested with OCV 2.3.1) with a Grasshopper 2.0 mono GigE camera using the DirectShow driver under Win 7 64 bit but running all 32 bit apps. Point Grey support seems to be unaware of the issue, but I just explained it to them. They usually test the driver with MS GraphEdit, which apparently has no problem with the negative height, but the latest version of vlc shows what looks like the same problem.

#include "stdafx.h" 
#include "opencv/cv.h" 
#include "opencv/highgui.h" 
#include "stdlib.h" 

int _tmain(int argc, _TCHAR* argv[])
{
    CvCapture* capture = cvCaptureFromCAM(0);
    IplImage* image = 0;
    cvNamedWindow("Window");

    int count = 1;
    while (true)
    {
        image = cvQueryFrame(capture);
        cvShowImage("Window", image);
        int ch = cvWaitKey(1);

        if(ch == 27) break;
    }

    cvDestroyWindow("Window");
    cvReleaseCapture(&capture);
    return 0;
}

Oh, regarding the color conversion problem, the inverted vertical coordinate may be part of the issue there as well. The Bayer pattern is not usually symmetric relative to a flip (for the usual case of even valued heights), so if you use the inverted CV_BayerGB2RGB->CV_BayerRG2RGB that might help. The Point Grey DS driver also returns an RGB32 (according to GraphEdit), so if something's interpreting that as RGB24, that would explain your warping. It looks like OpenCV should recognize the RGB32 subtype though.

I think I found what causes the "warping".
(current 2.5 code from the repository)

    //MEDIA CONVERSION
    //Get video properties from the stream's mediatype and apply to the grabber (otherwise we don't get an RGB image)
    //zero the media type - lets try this :) - maybe this works?
    AM_MEDIA_TYPE mt;
    ZeroMemory(&mt,sizeof(AM_MEDIA_TYPE));

    mt.majortype     = MEDIATYPE_Video;
    mt.subtype         = MEDIASUBTYPE_RGB24;
    mt.formattype     = FORMAT_VideoInfo;

    //VD->pAmMediaType->subtype = VD->videoType;
    hr = VD->pGrabber->SetMediaType(&mt);