--- In
psychtoolbox@yahoogroups.com, a0256@... wrote:
>
> Hello,
>
Hi Adria,
type devices = Screen('VideoCaptureDevices').
This will list all detected video capture devices, and the 'deviceIndex' field contains the number that you need to pass as 'deviceid' parameter to PsychVideoDelayLoop('Open', windowPtr [,deviceId] [,ROI] [,inColor]).
You will see that your camera's show up multiple times, e.g., my iSight looks like this:
>> devices(1)
ans =
DeviceIndex: 30001
ClassIndex: 3
InputIndex: 1
ClassName: 'USB Video Class Video'
InputName: 'Built-in iSight'
>> devices(2)
ans =
DeviceIndex: 30000
ClassIndex: 3
InputIndex: 1
ClassName: 'USB Video Class Video'
InputName: 'Built-in iSight'
>> devices(3)
ans =
DeviceIndex: 0
ClassIndex: 3
InputIndex: 1
ClassName: 'USB Video Class Video'
InputName: 'Built-in iSight'
The deviceindex encodes either specific devices or specific classes of devices. An index of 0 will always map to the "default device", an index of 30000 to the first device of class 3 -- the first connected USB Video class device. 30001 would specifically mean the 1st USB video class device, in this case the first connected iSight. So the different numbers allow ptb a certain amount of "independent thinking" in choice of device.
> I am using PTB-3 for the first time to create a vision/proprioception experiment. My task involves viewing yourself making a small hand movement with various time delays.
>
> Currently I have my code working using PsychVideoDelayLoop with the internal iSight camera on my iMac (running OS X 10.6.5). However, for more flexibility I would like to use a USB webcam type camera (PS3 eye, which currently works fine with Quicktime Pro) instead of the iSight camera.
>
> I am having a little trouble figuring out how to assign a DeviceID to this camera in the following line of code...
>
That said, be careful with variable delays, i.e., if you depend on millisecond/frame accurate delays use an independent way to verify once if the delays you specify are actually the delays you get. PsychVideoDelayloop was originally written and tested with professional Firewire cameras in mind (== "IIDC 1.1 compliant machine vision cameras connected to a IEEE1394 compliant bus system"), not for webcams, iSights or other cheap consumer equipment like, e.g., DV camcorders. Also it was optimized for use with Linux, as only Linux has an easy way to tune the video refresh interval of the connected display to the capture interval of a connected camera.
The algorithm works on any cam in principle, but it relies on the fact that the timestamps and general behaviour of the connected camera are predictable and precise. This is generally true for pro equipment in combination with Linux. I don't remember if i've verified the precision of the same camera with OS/X, but i'm sure i didn't verify the low-level timestamping algorithm of the operating system on OS/X, but only on Linux.
Consumer cams like the iSight don't have a very precise timing and they generally have a very high internal latency, like > 50 msecs. The iSight specifically can do ugly things like change the true framerate of capture depending on lighting conditions in uncontrollable ways. The PS/3 Eye is pretty good for a USB webcam. We've used it for studies ourselves, however not for ones which required frame-accurate latency control, so i don't know how well it does there.
Anyway, i think the timestamps from iSight et al. look ok, but we don't know when they are taken, e.g., if they correspond to start of sensor exposure, or start of frame readout, or end of some processing step in the os. With the firewire cam you have control over such things. The camera i tested with was a Basler A602 camera, if i remember correctly, at a price of about 1200 euros.
best,
-mario