ofVideoGrabber draws single color if created outside testApp

This is a little hard to describe, but under certain conditions, ofVideoGrabber::draw() seems to draw only one color, as if it’s repeating one pixel. The color changes as I wave my hand over the camera.

The examples WORK (moveGrabberExample and openCVExample), but when I create an instance of ofVideoGrabber and use it in my own class, I get the behavior described above.

For example. Lets say I have a class called myKeeper, that has the same methods as testApp and the same code as in moveGrabberExample. I have an instance of myKeeper called keeper in testApp, and for every method in testApp, I call the corresponding myKeeper method – i.e. in testApp::setup() I call keeper.setup(), etc. In this scenario, myKeeper’s code is just like testApp’s in movieGrabberExample. This level of indirection seems to create the problem.

Some important details: I’m running Ubuntu Linux 8.04. I have an nvidia graphics card. This exact same code works fine on a macbook running windows. Marti (the friend who was helping me debug) said he saw this before on a different windows machine with an nvidia card, however, the code didn’t work on two other linux boxes, neither of which, to my knowledge, had an nvidia card, so this may be a linux only issue.

As I write/think about this, I’m wondering if it has something to do with stack vs. heap allocated memory. I will try this tomorrow, but in the example above, I’m wondering if I create keeper via new (myKeepr* keeper = new myKeeper(); ) instead of just instantiating it (myKeeper keeper; ), I’ll have more luck.

I’ll post my results and sample code tomorrow, but I’m hoping this sounds familiar to someone.



a) is the width and height of video grabber what you expect (ie, width = requested width, height = requested height).

b) if you grab the pixels of the grabber (getpixels) do they all read as the same value (ie, do the pixels come out the same as the visual appearance of what you draw).

c) if you trace this part of videograbber for unicap with printouts

if (bDoWeNeedToResize == true){  
bIsFrameNew = ucGrabber.getFrameUC(&auxPixels);  
int inputW = ucGrabber.getUC_Width();  
int inputH = ucGrabber.getUC_Height();  
float scaleW =	(float)inputW / (float)width;  
float scaleH =	(float)inputH / (float)height;  

do you wind up here in either the working or non-working case?

my suspicion in the non-working case is that you do wind up here with getUC_Width() returning something very small ??

I don’t know why you’d get it in one place and not another but that seems like maybe unallocated variables (which’d be right to suspect stack/heap issues). I’ve just traced through ofVideoGrabber and I think we are ok there, so it might be helpful if you can report back about a/b/c above and we can try to trace it out.

anyone else seen that before?


Thanks for the response – looks like you were up late! I’ll get a chance to try your suggestions after work this evening. I’m still hoping someone sees this and is like “I know!” – maybe one of those linux geniuses arturo or grimus. Anyway, I’ll post my findings later.

A quick update - I haven’t gotten to my Linux box yet, but I did some debugging on a Mac I have here at work (OS X 10.5, Xcode 3.0). I re-wrote the example I describe above and the application would compile but would crash as soon as I ran it. I was declaring keeper as a global variable in testApp.cpp. When I made keeper a member of testApp and declared it in the testApp definition in testApp.h, it worked. I’ll try this on my linux machine this evening, but “sloppy coding” might be the only culprit. Time for an emocon - :oops:


A’ight - It appears that I was right in my previous post. In my simple example, when I declare keeper as a class variable instead of a global, things work fine, even on Linux. The strange thing is that the code worked on Windows, completely crashed on OS X, had the weird “single color” behavior on Linux, and compiled on all platforms. I guess the lesson is, too much information can be confusing and don’t write sloppy code :-). Thanks for the help, Zach.