Question: For a 3D scanning project I need to capture a video/snapshots of an object and a projector image that is projected on the object. The projector works (only) with a framerate of 60Hz, the camera supports rates in {3.75,7.5,15,30,60} Hz. I have to work in Matlab, and since it's an IEEE 1394 camera, I can only use the [CMU 1394 Camera driver](http://www.cs.cmu.edu/~iwan/1394/) since other drivers are not supported by matlab. 

Now, my problem is, that the framerates of the camera (driver) seem to have a tiny non-zero phase-offset that adds up over time such that the captured image gets darker and darker until it reaches some minimum and becomes brighter and brighter again and so on. This is annoying. There are sample applications for 3D scanners that are able to work with different drivers. There, the problem does not exist, so I am pretty sure that it's the driver's fault. 

Fortunately, the driver is open source, so putting a little offset somewhere in it and trying to solve the problem by trying out different times, could work. There is, however, one additional idea I had: The camera supports triggering. Is there any way that I can trigger it using the output of the projector? If that would work, that would be much easier and more elegant than fiddling around with that driver. The projector uses VGA. Do you know of any possibility to capture the signal and use it as a trigger? If possible without lot's of additional hardware.

Answer: 
(1) You mention 60 Hz for both **frame and capture rates** so the following should not be an issue, and it's obvious enough, but I mention it "just in case" as such things can trip you up. 

I'd have expected that if your frame capture lasted exactly "one frame" that brightness variation would not be a major issue. If capture time is less than frame time then location of your capture window affects result. If capture time is > frame time you get a whole image and then part of another. Both arrangements can (will) affect image quality. 

(2) **Frame sync signal:** 

Camera synchronisation to the VGA signal **should** be easy. 

The VGA signal set includes a Vsync (Vertical Synchronisation) signal that allows the start of the frame to be detected.

This is on pin 14 on a PC (DB15) video connector and on pin 12 on a Macintosh video connector. 

![enter image description here](https://i.stack.imgur.com/5xgLD.jpg)

The above diagram is from [Javier Valcarce's Personal Website - VGA Video Signal Format and Timing](http://www.javiervalcarce.eu/wiki/VGA_Video_Signal_Format_and_Timing_Specifications)

To add to the fun the polarity of the sync signal varies with resolution,but that's liable to not worry you once you work out which of he two possibilities applies in your case. 

Assuming that you can synchronise the camera triggering to this signal (**seems** likely to be simple enough). Worst case you may have to add a fixed delay to move the picture phase into the correct location for you operation.

---

**VGA timing:**

![enter image description here](https://i.stack.imgur.com/ypr6r.jpg)

Polarity is inverted for some resolutions.

From [VGA video signal generation](http://www.scribd.com/doc/4559939/VGA-Video-Signal-Generation)
If you want to try triggering off it VGA has its horizontal sync on pin 13, formally referenced to the sync ground on pin 10. (As Russel points out in comments, VSYNC on 14 is what should be used)

There's a slight chance you might find you need some means to provide a phase delay to trigger the camera at the right relative time, though you might be able to do something by adjusting the width of the sync pulse to an extreme in video low level settings depending on what the monitor(projector) can tolerate. A simple outboard circuit (a 555 and pot?) would be crude but likely workable.

If a pure software solution is workable that could seem cleaner, but I don't know if that is supported. 60Hz is easily within the realm of software control - jitter is always a concern in non-hard-realtime setups, especially with packetized IO buses - but it might stay within your tolerance. This would require that there be a software triggering mechanism in the driver that you can exploit. 

Finally I wouldn't necessarily say that matlab restricts you to using a particular camera driver and thus assortment of cameras, because matlab seems to have a workable interface to user libraries written in other languages like C, and from there it should be possible to obtain data from just about anything you can find documentation for how to talk to either directly or via an existing OS driver interface not supported by matlab.