In a modern chipset, the video shouldn't be traveling throught the PCI bus.

For instance, with the 855GME, the video is on the northbridge which is directly connected to the RAM. So we're talking for DDR333 @ 2.7GB/s, that's a whole lot more than 37MB/s!

Again, I'm wondering what Obin is using, since he was having tearing problems before, and using any double-buffered system and OpenGL/DirectX, there shouldn't be any tearing problems, or they should be extremely minimal.

<<<-- Originally posted by Rob Lohman : Jason: I fully agree. Audio needs to be sorted out fast and on a
pretty long recording as well to see if it drifts and if so how bad. -->>>

There are external, but pricey, devices that can accomplish this-word clocks. As far as just testing to see what the drift is - even once you find out, I don't think there will be much you can do about it as long as picture and sound are on seperate devices.

What I mean is, you can't just slap a crystal synch motor on this camera. A device to keep video and seperate audio in synch is such a specialized piece of equipment, I don't think it will be possible to build an adhoc replacement for it.

You could, I suppose, feed audio and video into the computer and have it keep synch for you. That probably would not be difficult, except that it would eat into your processing speed for video preview.

You also could set up a seperate computer that did nothing but keep synch between video and audio. It wouldn't need as much as the recording computer because it wouldn't have to record video. On the other hand, that will limit your mobility even more, increase the number of crew you will need, and possibly cost as much as buying a word clock.

Once, or maybe I should say if (that would be up to Rob S., or Obin's guy I supposed) the software reached an advanced enough iteration it should be able to take incoming video and audio, keep it in synch, and capture it to a quicktime/avi file in synch like a firestore. That will solve the synch problem right there (even if your also capturing to a seperate backup like DAT or DV or HDD or whatever). But I don't think we'll be able to do that right out of the gate. What do you think, Rob?

May I ask, given that the CMOS cameras (for example, one of the SI range) use an electronic shutter with a set clock-speed, how synch can become an issue. Surely if the timing of the images is electronically controlled, and, say, if you record to DAT or hard disk, then image and sound will remain in synch (once you align the clap/red-bleep).

As for the Motherboard problem, the FB8M I suggested is the only one I could find that was small and had a PCI-X slot for those fancy-dan framegrabbers. Does anybody have links to any other ones?

If film cameras have been doing sync-sound with crystal motors for the last 30 years (at least), and now we have a CMOS camera that has a clock synthesizer on it that can go down to the X.xxxMhz (3 decimal places) in accuracy, I think it's a little strange if you can't keep sync, at least for 10-15 minutes at a time, with an external DAT.

Hi all. I was gone for a week at the Vision show in Stuttgart. In answer to your frame grabber questions, there are many 64 bit/66MHz frame grabbers out there. Add Leutron to the list. The issues are: cost, features, cost, OS compatibility, cost, SDK tools, cost, camera support. Did I mention cost?

We can bundle the Epix FGs for $500 with our cameras including $200 worth of cables and power supply. The 64 bit should bundle for $1K. My apologies to all for their problems shipping their 64 bit product. I've been hearing more optimistic delivery dates than those posted but this board is clearly a problem for them. The reasons (besides cost, which I think I've covered) we like them are: Good GUI (for machine vision) and an SDK for both Windoze and Linux. Good external triggering. Responsive customer support. Excellent color tools.

We have worked with many of the others. Some are specialized, like Datacube with lots of FPGA and RAM for $4K+. Or built in SCSI RAID controllers like IO Industries ($$$).

Others are just competent FGs, like Eurosys and Matrox. Not really cheap, but they seem to work well...... and get delivered. I can't bundle any of the others right now so expect to spend $1200-$2K including cables and power supply plus tools (some of the SDKs are not cheap) but I will ship a camera to any FG company that wants to support our cameras.

The alternative is to go gigabit since our interface supports data packing (2 12 bit pixels in 3 bytes) over the gigE interface. It also has a large enough buffer to implement the every other frame and average the burst bandwidth. (1920x1080x30fps x 12 bits = 750Mbps, under the 800Mbps for the interface). There are SDKs for both OSes.

Anyone out there waiting for the 64 bit FG and not wanting to wait anymore for Epix, I'll do a credit for them (based on the amount paid, not our full price since I'm discounting to this group).

__________________
Silicon Imaging, Inc.
We see the Light!
http://www.siliconimaging.com

If film cameras have been doing sync-sound with crystal motors for the last 30 years (at least), and now we have a CMOS camera that has a clock synthesizer on it that can go down to the X.xxxMhz (3 decimal places) in accuracy, I think it's a little strange if you can't keep sync, at least for 10-15 minutes at a time, with an external DAT.

It's very easy for DAT to drift away from clock speed unless there are some specific devices, like a word clock or something similar sending a synch signal from camera to recorder. It doesn't happen as much with HDDs or solid-state devices, but it can happen quite easily with DAT - one of the reasons sound recorders are happy to be moving away from DAT recorders.

<<<-- Originally posted by Steve Nordhauser : The alternative is to go gigabit since our interface supports data packing (2 12 bit pixels in 3 bytes) over the gigE interface. It also has a large enough buffer to implement the every other frame and average the burst bandwidth. (1920x1080x30fps x 12 bits = 750Mbps, under the 800Mbps for the interface). There are SDKs for both OSes. -->>>

Hi, I asked this of your sales people already, but can you give an indication of the price of the 1920HD GigE package (I assume that includes Camera, C-link cable, CL-GigE box, SDK, but will gladly accept correction)? I was kind of baffled by the response I got, in that the GigE version was more expensive despite not coming with a FG card. I naturally assume I have misunderstood, so better to ask again. Thanks.

As for sound, perhaps a simple solution would be to front- and end-clap long takes for two synchronisation points. You can then adjust any shift more easily in post, with a little simple editing. That is, if there is any.

Steve, I think the problem with the Gige, is that, as I unbderstand it, it costs as much as a frame grabber to implement, it is not a hundred or two hundred doller solution. So the piont in buying it can become less attractive.

Some clarity on our gigabit solution. Right now we are using an external interface box (about 3"x4"x2") that converts our camera link camera into gigabit ethernet. That output is true ethernet - can go through switches and hubs and can be received by any gigabit card. For maximum performance, you need an Intel Pro1000 compatible card since we have custom drivers for it that will run continuous 800Mbps data. The serial port used to control the camera over the camera link side of things is virtual at the computer end - the data goes back to the camera over ethernet and is converted into true camera link (with hardware serial communications) at the interface box.

Right now the cost is more than our 32 bit frame grabber bundle but will decrease when we integrate the interface directly into the camera (underway). I will discuss prices off-line with anyone needing the specifics.

ASA 25

Until Markus tells us the sensor and configuration, it is all conjecture, but there are tremendous differences in sensor sensitivity. A good deal is related to the pixel size. Our SI-1300 has a 5.2 micron square pixel or 27 sq microns of sensing area. The SI-3300 has a 3.2 micron pixel or 10.24 square microns of sensing area. The SI-1300 is *Much* more sensitive. It is worse than it sounds because the capacitor and active circuitry for a pixel are fixed in size, so they take up a larger proportion of the possible sensing area in smaller pixels which reduces the fill factor - the amount of the pixel area available for photon sensing.

If the camera uses a global shutter, more transistors are needed for shuttering, which also reduces the fill factor This is why the IBIS-5 is much less sensitive than the Micron 1.3Mpix, even though it has larger pixels 6.7 micron).

The ideal sensor for this group would have large pixels, a good global shutter with minimal leakage and a Bayer filter. With this magic combination you get good sensitivity, no rolling shutter skew, limited DOF and single chip costs.

__________________
Silicon Imaging, Inc.
We see the Light!
http://www.siliconimaging.com

The ideal sensor for this group would have large pixels, a good global shutter with minimal leakage and a Bayer filter. With this magic combination you get good sensitivity, no rolling shutter skew, limited DOF and single chip costs.

Oh well, you can't have everything :)

At least the ProCamHD 3560 sensor is definitely a great step in that direction.

At the moment, I'm not. I was on the verge of buying an XL2 when I stumbled on this board. Since I have some time, I'm exploring the possibility of buying a set-up like this instead, since I'm primarily interested in full production.