4:4:4 10bit single CMOS HD project

[Obin Olson]

That is what a Script Super is for right?

[Wayne Morellini]

Yes multiple files, or at least an index, for scenes is a good idea. Maybe a slider, thumb wheel (in the case) to skip back through the scenes.

Jason. About the funny bayer pattern, I think the funny pattern comes from combining the skipped pixel with an adjacent pixel into complimentary colour (but I haven't read the 1920 pdf properly yet). So yes all bayer filters would have to be rewritten for it. Altasens should have some softrware filter solution allready (It plagues me as to why the TV industry did not do 540p*960 (or even 810p), which divides into 1080p*1920 evenly compared to 720p, it also would have made the transition to HD much quicker).


<<<-- Originally posted by Jason Rodriguez :
BTW, a motherboard that holds 8GB of RAM is HUGE-I'm not going to be carrying that around on my shoulder. -->>>

Sorry, I didn't realise you were after ENG style. I thought you were after stationary cinema shots that could be done with a big case. Two other suggestions, I think eventually (within a year) we are going to see a smaller version of that Nvidia 8GB capacity board, I mentioned some time back, in a small cube case. There used to be PCI card based ram disks, I imagine there might be soimebody out there with a PCI 64 version that takes upto 32GB in PC memory sticks.

[Wayne Morellini]

<<<-- Originally posted by Rob Scott :
a 64-bit CPU and a 64-bit OS -- but 64-bit Windows is not available yet (again, unless I'm mistaken). -->>>

As far as I know the 64-bit PCI is independent of the bits of the processors or OS, or where you talking about something else?

Thanks

Wayne.

[Rob Lohman]

Wayne: I think Rob S. was talking about 4 - 8 GB of memory which
might need a 64 bit OS? I'm not sure what 32 bit XP supports.

[Jason Rodriguez]

Rob was saying that right now it's hard to address 8GB of RAM unless you're using 64-bit Windows, or Windows 2003 Server, 64-bit Linux, etc. If you try to go with Windows 2003 Server, be prepared to spend as much on the operating system as you will on the computer!

Also 8GB of RAM is very expensive, it's probably much better to just purchase those small SCSI drives I was talking about from Seagate. They run at 10K RPM, that's very fast, and they only use around 5W to seek.

[Magnus Andersen]

Hello All.

Steve, do you have any more frame grabs from the SI-1920HD that you could share?

Best, Magnus Andersén.

[Wayne Morellini]

<<<-- Originally posted by Rob Lohman : Wayne: I think Rob S. was talking about 4 - 8 GB of memory which
might need a 64 bit OS? I'm not sure what 32 bit XP supports. -->>>

OK, I understand, yes you should be able to use 8GB, in a round about way, but you will have to check with how XP works to see if it supports this. See, if you can have virtual memory areas of 4GB each then you could have two of them paged into memory (for everybody that is not familiar with this, that means the memory acts as sort of disk cache).

Also with the ramdisk cards (you can use small board and rightangle card extenders to reduce size) they would be addressed as a disk and can have the maxium capacity.

The suggestion for the 8GB, in this case, is so you can shoot slow motion frames as fast, and reliably, as you want, faster than 4 drives. This is a specialist solution, not the normal solution for the rest of us. (personally I would just rent something like the high speed phantom (mentioned on the other thread) for a day on a feature film (nature doco/s you would be better owning your own I think))).

[Juan M. M. Fiebelkorn]

Has anybody thought about using Linux instead of Windows for the camera??
I guess it would eat less resources and be more controllable on every stage.......

[Rob Lohman]

Yes Juan, that has been discussed. I believe Obin's programmer
might be doing it under that OS. Rob S. and myself choose
Windows because we are both programmers under that platform
and it we should be able to more easily support things like GigE
since there are no drivers (the specific ones for the camera's!)
for Linux etc.

Basically in the end I personally don't feel Windows will be taking
a lot of resources away from the camera application which is
running with high thread priorities. The most important elements
for now are the bus speed, CPU speed and harddisk(s) speed(s).

Keep in mind that the processing application to turn all the captured
files into some other format and do a de-bayer etc. will be
completely open source and hopefully cross platform so you can
run that on windows / mac / linux in the end.

[Juan M. M. Fiebelkorn]

Yes, I know :)
It was I just thought everybody was developing only for windows,just that.
Thank you..

[Jason Rodriguez]

Also Juan, I'm not sure about Linux support for all the configurations that we're going to be using on our stuff. For instance, without good drivers, we may be in for a life of kernal panics with the incompatabilities that could be present with these custom motherboards/chipsets.

[Steve Nordhauser]

Rob L on GigE:
Actually, there are SDKs available for both Linux and Windoze. Same with the Epix frame grabbers (whose SDK you all have grown to love).

Magnus:
http://www.siliconimaging.com/Sample...th%2012bit.zip
http://www.siliconimaging.com/Sample...+%20filter.jpg

RAM:
I'm not sure at all of the value of putting a lot of RAM into your real-time systems. Post processing machines sure. For real-time, you have to be running out of cache for most of the processing and row buffering so all you really need is some FIFO-type external buffers to average the load. The bottom line in real time processing is either you are keeping up, or you are not. I guess with a really big RAM and "almost fast enough" processing you are gaining some recording time before you drop frames.

USB 2.0 speeds:
Before you rely on any interface for off-loading gigabytes (100's of gigabytes?) of data, be sure to benchmark it. I was told that windows drivers for gigE transfers are at about 200-250Mbps. I haven't seen much continuous transfer on USB 2.0 above about 320Mbps although I haven't looked at drives. I don't know about firewire. We may be licensing a software product that can transfer over gigE at 800Mbps.

SCSI:
If you are doing SCSI drives, I would put the drives in a separate box (better cooling as the fast drives get hot) and a SCSI controller on each computer. If you have two drive RAIDs, you can swap them and keep right on going. Certainly, if you record on the RAID as fast as you can access it and record 45 minutes, it won't take less than that to off-load it. The fastest way is to have it right on the bus going to a bigger array on the same PCI bus.

[Rob Lohman]

Steve: I stand corrected on the GigE. I thought those drivers
where only developed for the Windows platform. My bad.

As we stand now we try to keep everything realtime. Recording
to memory or buffering in large amounts might be interesting.
We'll have to wait and see.

[Jason Rodriguez]

SCSI:
If you are doing SCSI drives, I would put the drives in a separate box (better cooling as the fast drives get hot)

I'm assuming though that these new 2.5" SCSI drives won't be as hot as their 3.5" brethren. Am I incorrect in thinking this?

[Steve Nordhauser]

Jason on SCSI:
OK, I'm clueless about the new drives. I'm basing this on fast drives spin fast and generate more heat and when you pack drives they don't cool well. Just a bundle of generalizations that can probably be avoided with proper design.

How do SCSI drives compete with SATA for cost, density and speed? The only benchmark I have heard from a a good source is that 15KRPM SCSI drives can do 50MB/sec across the entire surface.