4:4:4 10bit single CMOS HD project

Juan M. M. Fiebelkorn · October 25th, 2004, 08:38 AM

the only hardware problem or limitation I can think of is if the video were going thru PCI bus, but even in that case adding 37 MB/s wouldn't clog it so, I give up.

Jason Rodriguez · October 25th, 2004, 09:39 AM

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.

Joshua Starnes · October 25th, 2004, 10:30 AM

<<<-- 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?

Conor Ryan · October 25th, 2004, 12:38 PM

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?

Jason Rodriguez · October 25th, 2004, 12:50 PM

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.

Steve Nordhauser · October 25th, 2004, 01:17 PM

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).

Joshua Starnes · October 25th, 2004, 01:53 PM

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.

Jason Rodriguez · October 25th, 2004, 01:58 PM

Quote:

I've been hearing more optimistic delivery dates than those posted but this board is clearly a problem for them.

Sorry Steve, I wasn't trying to spread FUD about the shipping dates on the EPIX, the February time frame was what their sales rep told me when I called to ask about some features in XCAP.

BTW, it's great to see you back. Hope you had a great trip.

Conor Ryan · October 25th, 2004, 06:38 PM

<<<-- 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.

Jason Rodriguez · October 25th, 2004, 08:30 PM

The GigE solution comes with a framegrabber that hooks up via Gigabit ethernet. So it takes in a cameralink signal and outputs over Gigabit ethernet.

Wayne Morellini · October 26th, 2004, 12:25 AM

Welcome Markus, good to have you here.

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.

Steve Nordhauser · October 26th, 2004, 07:23 AM

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.

Jason Rodriguez · October 26th, 2004, 09:58 AM

Quote:

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.

Eric Gorski · October 26th, 2004, 12:21 PM

what camera and capture setup are you using marcus/conor?

Conor Ryan · October 26th, 2004, 01:38 PM

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.

October 25th, 2004, 01:17 PM	#1866
Steve Nordhauser Silicon Imaging, Inc. Join Date: May 2004 Location: Troy, NY USA Posts: 325	Frame Grabbers 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

October 25th, 2004, 06:38 PM	#1869
Conor Ryan Regular Crew Join Date: Oct 2004 Location: Dublin, Ireland Posts: 67	Re: Frame Grabbers <<<-- 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.

October 26th, 2004, 12:25 AM	#1871
Wayne Morellini Inner Circle Join Date: May 2003 Location: Australia Posts: 2,762	Re: HD Movie Project Welcome Markus, good to have you here. 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.

October 26th, 2004, 07:23 AM	#1872
Steve Nordhauser Silicon Imaging, Inc. Join Date: May 2004 Location: Troy, NY USA Posts: 325	Gigabit 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

October 25th, 2004, 08:38 AM	#1861
Juan M. M. Fiebelkorn Major Player Join Date: Jun 2004 Location: Buenos Aires , Argentina Posts: 444	the only hardware problem or limitation I can think of is if the video were going thru PCI bus, but even in that case adding 37 MB/s wouldn't clog it so, I give up.

October 25th, 2004, 09:39 AM	#1862
Jason Rodriguez Trustee Join Date: Mar 2003 Location: Virginia Beach, VA Posts: 1,095	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.

October 25th, 2004, 10:30 AM	#1863
Joshua Starnes Major Player Join Date: Jun 2004 Location: Houston, TX Posts: 356	<<<-- 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?

October 25th, 2004, 12:38 PM	#1864
Conor Ryan Regular Crew Join Date: Oct 2004 Location: Dublin, Ireland Posts: 67	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?

October 25th, 2004, 12:50 PM	#1865
Jason Rodriguez Trustee Join Date: Mar 2003 Location: Virginia Beach, VA Posts: 1,095	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.

October 25th, 2004, 01:53 PM	#1867
Joshua Starnes Major Player Join Date: Jun 2004 Location: Houston, TX Posts: 356	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.

October 25th, 2004, 08:30 PM	#1870
Jason Rodriguez Trustee Join Date: Mar 2003 Location: Virginia Beach, VA Posts: 1,095	The GigE solution comes with a framegrabber that hooks up via Gigabit ethernet. So it takes in a cameralink signal and outputs over Gigabit ethernet.

October 26th, 2004, 12:21 PM	#1874
Eric Gorski Regular Crew Join Date: Jun 2004 Location: Western Oregon Posts: 138	what camera and capture setup are you using marcus/conor?

October 26th, 2004, 01:38 PM	#1875
Conor Ryan Regular Crew Join Date: Oct 2004 Location: Dublin, Ireland Posts: 67	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.