When I try to load the camera in OpenCV I get an error:
HIGHGUI ERROR: V4L/V4L2: VIDIOC_CROPCAP
The image is eventually fetched but in 'BGR3' format and is cropped (compared to raspistill output). Moreover when I try to change resolution I get the same error and the resolution stays at 640x480 all the time.
I just started looking at the V4L2 drivers for use with OpenCV and hit the same wall that you have, pondruska, with respect to the message and resolution.
I pulled cap_v4l.cpp source of highgui from OpenCV 2.4.9 and stepped through the execution. The VIDIOC_CROPCAP error is just on a check to ascertain whether or not the camera supports that ioctl; the error simply indicates that the device does not support it and that it skipped setting the crop type. It doesn't affect the image capturing, however, it does attempt to run on every call to icvSetVideoSize, which ultimately is the base for calls to VideoCapture::set for changing the CV_CAP_PROP_FRAME_HEIGHT or WIDTH, which is why that error always appears in conjunction with attempts at changing the resolution.
The problem with the fixed 640x480 resolution was the following ioctl call that sets the capture width and height. On the first run, which is called from VideoCapture's constructor on camera initialization, uses some defaults to call icvSetVideoSize, which initializes the camera to 640x480. Future calls, however, through VideoCapture::set, result in the ioctl failing, with a return code of 16, EBUSY (device is busy). I couldn't find any means of getting a resolution change to pass after initialization, it always returns EBUSY.
My fix to get this to operate for my robots was to hack a new constructor into VideoCapture that allowed me to specify an initial resolution, and then to use that instead of the defaults. It allowed us to change the resolution on camera initialization within OpenCV, which is better than the alternatives of being stuck with the older userland/robidouille camera code. This works for all resolutions from minimum up to 720P. I am capturing still images at 1280x720, without the framerate cap, using BGR3, at 28.3 FPS. 1024x720 is coming in at 34.12 FPS.
Now, I'm not an OpenCV user or a vision guy. I've just been trying to build up a new system for use with our robots that would increase framerate, and this does accomplish that marvelously. My problem now is in trying to exceed a height of 720. I'm only concerned with still images, but every attempt I've made withing OpenCV to exceed a height of 720 results in a frame rate drop to 8 and a corrupted output image that renders all black.
I realize that OpenCV is a smaller audience for this camera and driver, and that the problem here is likely contained within OpenCV itself; I was just wondering if anyone had any inclinations as to why I might be limited to a height of 720. Naturally raspistill performs beautifully at far exceeding resolutions.
Additionally, if anyone has any idea about what might have changed within OpenCV from 2.4.6, where we were able to change the resolution on the fly, to the current post-patch (2.4.8) version that returns EBUSY on each call following camera initialization, I would be most interested to find what may be causing this to fail.