For people having trouble with with the Capture class, WinVDIG, and Quicktime 7 in the Windows environment, just wanted to mention the JMyron library which can be found on this website under Reference -> Libraries -> Contributions. I just switched my apps to use it instead of Capture and here's my experience:

- Latest version of JMyron is way faster than Capture+WinVDIG. I experienced really obvious improvements in the framerates I could get while displaying a live webcam image.

- I uninstalled both Quicktime and WinVDIG and it still works (contrary to what it says in JMyron's FAQ but un-contrary to what it says in the News section-- the latest versions of of JMyron in fact do not require Quicktime or WinVDIG).

- For Windows JMyron comes with a couple DLL's which need to be in place; you can drop them either in Windows/System32 or in your exported app's directory.

- Under Windows I guess it works with all cameras whose drivers support the WDM interface; worked with mine anyway.

- Compared to Capture, it's probably not as easy to select among multiple connected cameras, and it's not possible to capture input from multiple cameras simultaneously. But if you only have one camera connected, it picks it up automatically.

- You can't tell the camera what framerate to capture at and under Windows with my camera I got unpredictable results if I asked for a capture resolution other than 320x240 or 640x480. But I never had good luck setting those things with Capture either (adjusting frame rate never seemed to do much for me, and non-standard capture resolutions stretched rather than cropped the image). You can however display the webcam feed at any framerate you want, since this is done within draw().

- A slight annoyance, the JMyron image object doesn't share the same interface as the PImage object, like Capture does. So for example you can't use Processing's copy() command to put just a cropped portion of the video frame on screen or into another PImage. You can only examine the pixels[] individually (which is appropriate for some applications and significantly faster than doing the same thing on a Capture object; but not the fastest possible method for other applications); or you can use JMyron's imageCopy() command to copy the entire video frame into the pixels array of a new PImage buffer (which needs to be the same size as the video frame), and then use the copy() command to copy just a portion from that temporary buffer, or the image() command to display the whole temporary buffer someplace on screen. It slows things down a bit but even when you're constantly copying to that buffer it's still faster than using Capture. Maybe in the next version the authors can make the imageCopy() method more flexible so you don't need to create a temporary full-frame PImage buffer.

Well, just my $.02 since making this change has solved some problems for me that it seems like other people are struggling with lately

Dan

P.S. This whole discussion assumes using JMyron for the same functions as the Capture class offers; JMyron also offers (and I think was designed primarily to do) a bunch of methods for motion tracking which I haven't tried since they're not needed by my application.

I can absolutely second the praise. I'm getting very nice performance via DirectX on Windows in particular, running off a DV cam.

But your "minor annoyance" to me is really painful. I want to be able to output the difference image as a texture or img object for further processing, and you can't: imageCopy() only works with the captured image, and not with differenceImage(). I can't think of a way to do that easily; it seems like it'd be better to just get imageCopy() to work on the differenceImage() array, too. Any thoughts?