<<<-- Originally posted by Rob Scott : I believe that Joshua is planning to build a Windows PC just for the camera itself, and then transfer the files to the Mac, running the Convert app (which will hopefully be cross-platform by that time). -->>>

That was my plan, yep.

Smallest Fanelss ITX PSU (near PC-card sized)
 

Two updates:

Smallest ITX PSU, and very thin version, 3Ghz P4 support, and 95% efficency. There is a thin stick like model too.

http://www.digit-life.com/news.html?107750

Toms hardware tests new 1394b drivers (the old Windows Service 2 drivers run at around 100Mb/s) and gives real world performance and discussion against Gigabit Ethernet. (but, it talks about bus clashes, in our application there is only the camera and the computer on the network so the capture should be able to be programmed to aviode all these clashes.)

http://www.tomshardware.com/howto/20...rewire-06.html

Auto url embeedder script.
 

Rob,

On other sites, simular to this, I have seen urls automatically converted into embedded links when posted, without having to use . They seem to just look for www or http (which is most of them). Could we please have something like that?

Thanks

Wayne.

Gigabit
 

Some interesting news on the gigabit side. I just came back from a seminar on our gigabit interface. Some good stuff:

1 - 800Mb/sec continuous on a dedicated wire is definite. Some customers are above 900Mb/sec. CPU utilization is almost zero.

2- Using a crappy Bayer algorithm and the SI-3300, 1920x1080, 12 bit, 24fps was transmitted, received and *displayed* in real time. 20-30% CPU utilization. If we implement the every other frame dropping at the camera level, this might be nice for the Altasens too. It would seem this leaves headroom for some basic compression.

3 - The dedicated driver is required for these speeds but only works with Intel Pro1000 interfaces. There is a filter driver that runs on top of a generic network card driver that will do 600-800Mb/sec continuous with somewhat more CPU overhead. With this driver you can have other stuff on the network (not a dedicated port) as long as it is quiet during video.

4 - Data packing is done in hardware - two pixels of 12 bit data take 3 bytes, not 4.

This is mostly interesting because I think it is easier to find an embedded motherboard with GigE than to try to package a motherboard with a PCI frame grabber.

right!!!
Thanks for the news.

Thanks Steve

I've got a question. Increasing MHZ, will that mean that integration time will be reduced despite the FPS used (leading to lots of lighting)?

The rolling shutter shutter problem. I think the problem is that it is in the wrong direction compared to the film shutter (causing the slant on horizontal movement). If we rotated a 4:3 camera 90 degrees and used the right anamaorphic convertor lense to covert to either 16:9 or 2.35:1, we would get a shutter effect simular to film and more freindly to horizontal movement.

I know the screen size in pixels is no longer right, and there is a capture speed hit because all horizontal lines (now vertical) have to be entirely read, but good as a specialist solution.

Thanks

Wayne.

I forgot to ask, for the 20-30% cpu utilisation, what processor and MB were they using?

I'm impressed by the figures you gave, they are everything I hoped for.

Thanks

Wayne.

GigE CPU utilization:
2.8GHz P4 with HT. You don't need too much memory (512MB??)

Thanks, my question on increasing SI-3300 Mhz, is it correct?

Wayne,
The SI-3300 has been tested to about 60MHz (1920x1080 @24fps). It *might* go to 75MHz (30fps) max. Keep in mind that you can get more color smear as you increase the clock rate beyond what the analog components can handle (shift register, amps, gain stage, A/D).

You could rotate the camera. The frame rates aren't quite symetrical, but you can still do a window. For example on the 3300, 1280x720 can run at 49fps but 720x1280 runs at 42fps (60MHz).

Steve, when will you have a product that is Gigabit? like the 3300?

Gigabit ethernet:
We already have two box solutions for the SI-1280F, SI-3170, SI-1300, SI-3300 (beta). The group has a 1920HD but hasn't started with it yet. A single box solutin is about 12 weeks away.

Thats good, look forward to hearing about it then.

I was asking about where ever it was right to say that increasing Mhz reduces integration time, whatever fps is used. But it doesn't matter any longer, thanks for your help anyway.

For everybody that wants to know more about sensor specs I have discovered this page:

http://www.ccd.com/ccdu.html

Silicon Imaging also has some basic tutorial pages on their site.

GPU programming.

In case anybody is still interested in learning more about GPU programming I found this article at gamasutra:

http://www.gamasutra.com/features/20...mccool_pfv.htm

The reference to the toolkit are:

Steve,

I'm still trying to figure out this rolling shutter with the higher-clocked Mhz issue.

If I'm understanding it correctly, you can run the chip at a higher Mhz, (like its max) to reduce rolling shutter artifacts, but use as long an integration time as you want for variable frame-rates and actual shutter speeds? In other words, can you run the chip at the Mhz that would be for 60fps, but only shoot at 24fps with a 1/48th second shutter (that shutter is slower than the 60fps the chip is running at, hence I'm wondering if this is possible)? Or does the chip need to be run at a Mhz that will enable a multiple of the frame-rate, and long enough to accomidate the shutter speed (so no faster than 48fps for a 1/48th of a second shutter speed).

I'm wondering if the problem becomes once you clock the chip too high, you can't get the shutter speed down (but you have reduced rolling artifacts), and you get what I call the "Saving Private Ryan" effect of a really jerky, shuttery camera image from too fast a shutter that doesn't allow enough motion blur (albeit with reduced rolling shutter artifacting).